On Wed, Jul 24, 2024 at 11:38 AM Srivatsa Vaddagiri <quic_svaddagi@xxxxxxxxxxx> wrote: > > Currently vduse does not seem to support configuration space writes > (vduse_vdpa_set_config does nothing). Is there any plan to lift that > limitation? I am aware of the discussions that took place here: > The problem is that current virtio code can't allow the failure of config write. > https://patchwork.kernel.org/project/netdevbpf/patch/20210615141331.407-11-xieyongji@xxxxxxxxxxxxx/ > > Perhaps writes can be supported *selectively* without violating safety concerns > expressed in the above email discussion? > > We are thinking of using vduse for hypervisor assisted virtio devices, which > may need config write support and hence this question. > > To provide more details, we have a untrusted host that spins off a protected > (confidential) guest VM on a Type-1 hypervisor (Gunyah). VMM in untrusted host > leads to couple of issues: > > 1) Latency of (virtio) register access. VMM can take too long to respond with > VCPU stalled all that while. I think vduse shares a similar concern, due to > which it maintains a cache of configuratin registers inside kernel. > > 2) For PCI pass-through devices, we are concerned of letting VMM be in charge of > emulating the complete configuration space (how can VM defend against invalid > attributes presented for passthr devices)? I am aware of TDISP, but I think it > may not be available for some of the devices on our platform. > > One option we are considering is for hypervisor to be in charge of virtio-PCI > bus emulation, allowing only select devices (with recognized features) to be > registered on the bus. VMM would need to register devices/features with > hypervisor, which would verify it (as per some policy) and present them to VM on > the virtio-PCI bus it would emulate. Protected VM should be shielded from > invalid device configuration information that it may otherwise read from a > compromised VMM. > > For virtio devices, the hypervisor would also service most register read/writes > (to address concern #1), which implies it would need to cache a copy of the > device configuration information (similar to vduse). > > We think vduse can be leveraged here to initialize the hypervisor cache of > virtio registers. Basically have a vdpa-gunyah driver registered on the vdpa > bus to which vduse devices are bound (rather than virtio-vdpa or vhost-vdpa). > vdpa-gunyah driver can pull configuration information from vduse and pass that > on to hypervisor. It will also help inject IRQ and pass on queue notifications > (using hypervisor specific APIs). > > We will however likely need vduse to support configuration writes (guest VM > updating configuration space, for ex: writing to 'events_clear' field in case of > virtio-gpu). Would vduse maintainers be willing to accept config_write support > for select devices/features (as long as the writes don't violate any safety > concerns we may have)? > It would be easier to support it if the config write just triggers an async operation on the device side, e.g. a doorbell. That means we can't ensure that any required internal actions on the device side triggered by the config write have been completed after the driver gets a successful return. But I'm not sure if this is your case. Thanks, Yongji
