Re: [RFC] vduse config write support
Jason Wang <[email protected]> Tue, 30 Jul 2024 11:10:35 +0800
| Newsgroups | dev.linux.lists.virtio-dev,dev.linux.lists.virtualization |
|---|---|
| Message-ID | <CACGkMEt+hCQTfCkPhPR+47rMiPCfZLCJkpC-=2drKAiAFRxJCA@mail.gmail.com> |
On Tue, Jul 30, 2024 at 11:06 AM Jason Wang <[email protected]> wrote: > > On Mon, Jul 29, 2024 at 2:03 PM Srivatsa Vaddagiri > <[email protected]> wrote: > > > > * Jason Wang <[email protected]> [2024-07-29 10:16:48]: > > > > > > Without this optimization, guest VCPU would have stalled until VMM in host can > > > > emulate it, which can be long, especially a concern when the read is issued in > > > > hot path (interrupt handler, w/o MSI_X). > > > > > > I think I agree with Michael, let's try to use MSI-X here where > > > there's a lot of existing optimizations in various layers. > > > > Yes sure. Even if we implement MSI-X, there is a security angle to why we want > > hypervisor-hosted PCI bus (have provided details in an earlier reply > > > > https://lore.kernel.org/virtio-dev/[email protected]/T/#m84455763d6b4d0d3b8df814b3d64e6e48ec12ae3 > > > > > > > > > > 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)? > > > > > > > > > > I think so, looking at virtio_gpu_config_changed_work_func(), the > > > > > events_clear seems to be fine to have a posted semantic. > > > > > > > > > > Maybe you can post an RFC to support config writing and let's start from there? > > > > Does VDUSE support runtime configuration changes (ex: block device capacity > > changes)? > > Looks like it can, it has VDUSE_DEV_INJECT_CONFIG_IRQ. > > > I am curious how the atomicity of that update is handled. For ex: > > guest reading config space while concurrent updates are underway (SET_CONFIG). > > I think the generation count should help there - but it was not clear to me how > > VDUSE is handling generation_count reads during such concurrent udpates. > > Similar to the above, we are missing uAPI to do that. Probably just an > uAPI to update the device generation. I meant userspace can just do: ioctl(fd,VDUSE_DEV_INC_GENRATION); ioctl(fd,VDUSE_DEV_SET_CONFIG); ioctl(fd,VDUSE_DEV_INC_GENREATION); And synchronize the device generation increasing with vduse_vdpa_get_generation(). Then we should be fine. Thanks > > Thanks > > > > > - vatsa > >