All of lore.kernel.org
 help / color / mirror / Atom feed
From: Laszlo Ersek <lersek@redhat.com>
To: Anthony PERARD <anthony.perard@citrix.com>,
	Igor Druzhinin <igor.druzhinin@citrix.com>
Cc: jordan.l.justen@intel.com, edk2-devel@lists.01.org,
	xen-devel@lists.xenproject.org, julien.grall@arm.com,
	ard.biesheuvel@linaro.org
Subject: Re: [PATCH RESEND 1/3] OvmfPkg/XenSupport: remove usage of prefetchable PCI host bridge aperture
Date: Wed, 20 Mar 2019 12:15:34 +0100	[thread overview]
Message-ID: <c97f13ad-b9c0-6716-7c34-9d2e226297a6__26326.5275558055$1553080591$gmane$org@redhat.com> (raw)
In-Reply-To: <20190319140319.GJ11621@perard.uk.xensource.com>

On 03/19/19 15:03, Anthony PERARD wrote:
> On Thu, Mar 14, 2019 at 07:45:56PM +0000, Igor Druzhinin wrote:
>> On 14/03/2019 17:41, Anthony PERARD wrote:
>>> Hi,
>>>
>>> On Wed, Mar 06, 2019 at 12:40:54PM +0000, Igor Druzhinin wrote:
>>>> This aperture doesn't exist in OVMF and trying to use it causes
>>>
>>> I'm trying to understand what you mean by writing "doesn't exist in
>>> OVMF". Are prefetchable BAR not handled by ScanForRootBridges() ?
>>> Or is it the emulation of the config space that isn't correct?
>>> Maybe QEMU should lies about a BAR been prefetchable?
>>
>> The problem here is: hvmloader places BARs initially disregarding
>> prefetchable bit in an arbitrary order because essentially there is only
>> 1 aperture for the host bridge in emulated system under Xen (and KVM as
>> well). In PcatPciRootBridgeParseBars() we construct apertures for high
>> level OVMF code by reading the BAR placement information after
>> hvmloader. It often appears that there are prefetchable and
>> non-prefetchable BARs coexist with each other and make prefetchable and
>> non-prefetchable apertures overlap. This eventually triggers an
>> assertion in high level OVMF code because that shouldn't happen.
> 
> Thanks for the explanation. Could you add it to the patch description?
> 
>> OVMF for KVM is not using prefetchable BAR at all - see
>> PciHostBridgeGetRootBridges() in which it passes mNonExistAperture dummy
>> object to high level code. I think it's wrong to construct a
>> prefetchable aperture for Xen and this code should be removed as it's
>> done for QEMU-KVM. Do you think this patch needs to do that?
> 
> It would be nice to remove the code that isn't useful so feel free to do
> it and/or keep the current patch with the description updated.

Right -- I'd like to add one keyword here, for background: EFI_PCI_HOST_BRIDGE_COMBINE_MEM_PMEM. (It's documented in both edk2 [MdePkg/Include/Protocol/PciHostBridgeResourceAllocation.h] and the PI spec [EFI_PCI_HOST_BRIDGE_RESOURCE_ALLOCATION_PROTOCOL.GetAllocAttributes()].)

Thanks
Laszlo

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

  reply	other threads:[~2019-03-20 11:15 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-06 12:40 [PATCH RESEND 0/3] Xen PCI passthrough fixes Igor Druzhinin
2019-03-06 12:40 ` [PATCH RESEND 1/3] OvmfPkg/XenSupport: remove usage of prefetchable PCI host bridge aperture Igor Druzhinin
2019-03-14 17:41   ` Anthony PERARD
2019-03-14 19:45     ` Igor Druzhinin
2019-03-19 14:03       ` Anthony PERARD
2019-03-20 11:15         ` Laszlo Ersek [this message]
2019-03-22  8:33   ` Roger Pau Monné
2019-03-22  9:06     ` Laszlo Ersek
     [not found]     ` <7b8b9559-6479-9ee0-5b5a-300b43606669@redhat.com>
2019-03-24  3:50       ` Roger Pau Monné
2019-03-25 14:32         ` Igor Druzhinin
2019-03-06 12:40 ` [PATCH RESEND 2/3] OvmfPkg/XenSupport: use a correct PCI host bridge aperture for BAR64 Igor Druzhinin
2019-03-14 17:44   ` Anthony PERARD
2019-03-06 12:40 ` [PATCH RESEND 3/3] OvmfPkg/XenSupport: turn off address decoding before BAR sizing Igor Druzhinin
2019-03-06 13:22   ` Laszlo Ersek
     [not found]   ` <e8cdf4a2-b02b-daa7-4301-803fb1e0086d@redhat.com>
2019-03-06 14:26     ` Igor Druzhinin
2019-03-06 17:39       ` Laszlo Ersek
2019-03-14 17:55   ` Anthony PERARD
2019-03-14 20:09     ` Igor Druzhinin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='c97f13ad-b9c0-6716-7c34-9d2e226297a6__26326.5275558055$1553080591$gmane$org@redhat.com' \
    --to=lersek@redhat.com \
    --cc=anthony.perard@citrix.com \
    --cc=ard.biesheuvel@linaro.org \
    --cc=edk2-devel@lists.01.org \
    --cc=igor.druzhinin@citrix.com \
    --cc=jordan.l.justen@intel.com \
    --cc=julien.grall@arm.com \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.