On 4/27/2020 9:16 AM, Jason Gunthorpe wrote:
On Mon, Apr 27, 2020 at 09:41:37AM -0600, Alex Williamson wrote:
On Mon, 27 Apr 2020 11:25:53 -0300
Jason Gunthorpe <jgg@xxxxxxxxxxxx> wrote:
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.
Ok, we/I need a terminology clarification, a BAR is a register in
config space for determining the size, type, and setting the location
of a I/O or memory region of a device. I've been asserting that the
emulation of the BAR itself is trivial, but are you actually focused on
emulation of the region described by the BAR?
Yes, BAR here means the actually MMIO memory window - not the config
space part. Config space emulation is largely trivial.
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.
Maybe what you're recalling me say about mdev is that its Achilles
heel is that we rely on mediation provider (ie. vendor driver) for
security, we don't necessarily have an piece of known, common hardware
like an IOMMU to protect us when things go wrong. That's true, but
don't we also trust drivers in the host kernel to correctly manage and
validate their own interactions with hardware, including the APIs
provided through other user interfaces. Is the assertion then that
device specific, register level API is too difficult to emulate?
No, it is a reflection on the standard Linux philosophy that if it can
be done in user space it should be done in userspace. Ie keep minimal
work in the monolithic kernel.
Also to avoid duplication, ie idxd proposes to have a char dev with a
normal kernel driver interface and then an in-kernel emulated MMIO BAR
version of that same capability for VFIO consumption.
The char dev interface serves user apps on host (which we will deprecate
and move to the UACCE framework in near future). The mdev interface will
be servicing guests only. I'm not sure where the duplication of
functionality comes into play.
Jason
