OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [virtio-comment] Re: [PATCH 09/11] transport-pci: Describe PCI MMR dev config registers


> From: Jason Wang <jasowang@redhat.com>
> Sent: Tuesday, April 11, 2023 5:02 AM

> > The point of the capability is to allow using modern device ID so such
> > guests will not even try to bind.
> 
> It means a mediation layer is required to use. Then it's not an issue for this
> simple relaxing any more?
> 
It is desired to for the best performance because the notification 2B is sandwitched by legacy in middle of the configuration registers.
So like described in patch-10, a mediation layer will be able to use dedicated notification region.

Secondly, PCI has only effectively 3 BARs.
It is better to reuse one of the existing BAR when possible for the device depending on the features it offered.
So better not to hard code to BAR0 always.

> An advantage of such relaxing is that, for the legacy drivers like an ancient Linux
> version that can already do MMIO access to legacy BAR it can work without any
> mediation.
May be, such MMIO BAR mapping to user space will need page aligned BAR instead of 32B or 64B
(You asked about 4K in other thread).
It is unlikely performant due to intermixing of notification and config registers.

So letting it driven by notification region is better, may be some device can map to the same notification register in middle of the config area.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]