> From: Jason Gunthorpe <jgg@xxxxxxxxxx> > Sent: Friday, September 8, 2023 8:16 PM > > On Fri, Sep 08, 2023 at 01:50:36AM -0700, Christoph Hellwig wrote: > > On Thu, Sep 07, 2023 at 10:04:10PM -0600, Alex Williamson wrote: > > > > I think it really depends on what the qemu side wants to do.. > > > > > > Ok, I thought you had been one of the proponents of the fake BAR > > > approach as more resembling CXL. > > Yes, I do prefer this because it is ultimately simpler on the qemu and > VM side. This ACPI tinkering is not nice. > > > > Do we need to reevaluate that the tinkering with the VM machine > > > topology and firmware tables would better align to a device > > > specific region that QEMU inserts into the VM address space so > > > that bare metal and virtual machine versions of this device look > > > more similar? Thanks, > > > Yes, providing something to a VM that doesn't look anything like the > > underlying hardware feels pretty strange. > > I don't see the goal as perfect emulation of the real HW. > > Aiming for minimally disruptive to the ecosystem to support this > quirky pre-CXL HW. > > Perfect emulation would need a unique VFIO uAPI and more complex qemu > changes, and it really brings nothing of value. > Does it mean that this requires maintaining a new guest driver different from the existing one on bare metal?
