On Mon, Apr 27, 2020 at 08:18:41AM -0600, Alex Williamson wrote: > On Mon, 27 Apr 2020 10:22:18 -0300 > Jason Gunthorpe <jgg@xxxxxxxxxxxx> wrote: > > > On Mon, Apr 27, 2020 at 07:19:39AM -0600, Alex Williamson wrote: > > > > > > It is not trivial masking. It is a 2000 line patch doing comprehensive > > > > emulation. > > > > > > Not sure what you're referring to, I see about 30 lines of code in > > > vdcm_vidxd_cfg_write() that specifically handle writes to the 4 BARs in > > > config space and maybe a couple hundred lines of code in total handling > > > config space emulation. Thanks, > > > > Look around vidxd_do_command() > > > > If I understand this flow properly.. > > I've only glanced at it, but that's called in response to a write to > MMIO space on the device, so it's implementing a device specific > register. It is doing emulation of the secure BAR. The entire 1000 lines of vidxd_* functions appear to be focused on this task. > Are you asking that PCI config space be done in userspace > or any sort of device emulation? I'm concerned about doing full emulation of registers on a MMIO BAR that trigger complex actions in response to MMIO read/write. Simple masking and simple config space stuff doesn't seem so problematic. > The assumption with mdev is that we need emulation in the host > kernel because we need a trusted entity to mediate device access and > interact with privileged portion of the device control. Thanks, Sure, but there are all kinds of different levels to this - mdev should not be some open ended device emulation framework, IMHO. ie other devices need only a small amount of kernel side help and don't need complex MMIO BAR emulation. Would you be happy if someone proposed an e1000 NIC emulator using mdev? Why not move every part of qemu's PCI device emulation into the kernel? Jason
