On Wed, 13 May 2020 19:26:34 +0000 "Derrick, Jonathan" <jonathan.derrick@xxxxxxxxx> wrote: > On Wed, 2020-05-13 at 11:55 -0600, Alex Williamson wrote: > > On Wed, 13 May 2020 00:35:47 +0000 > > "Derrick, Jonathan" <jonathan.derrick@xxxxxxxxx> wrote: > > > > > Hi Alex, > > > > > > > [snip] > > > > > Thanks for the confirmation. The approach seems ok, but a subtle > > side-effect of MemoryRegion quirks is that we're going to trap the > > entire PAGE_SIZE range overlapping the quirk out to QEMU on guest > > access. The two registers at 0x2000 might be reserved for this > > purpose, but is there anything else that could be performance sensitive > > anywhere in that page? If so, it might be less transparent, but more > > efficient to invent a new quirk making use of config space (ex. adding > > an emulated vendor capability somewhere known to be unused on the > > device). Thanks, > > > > Alex > > Seems like that could be a problem if we're running with huge pages and > overlapping msix tables. FWIW, MSI-X tables are already getting trapped into QEMU for emulation. We have a mechanism via x-msix-relocation=<OffAutoPCIBAR> in QEMU to deal with that when it becomes a problem by emulating the MSI-X structures in MMIO space that doesn't overlap with the actual device (ie. virtually resizing or adding BARs). The issue is what else can be in that 4K page or will this device be supported on archs where the system page size is >4K more so than huge pages (as in hugetlbfs or transparent huge pages). Thanks, Alex
