Re: [RFC] vduse config write support

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Jul 30, 2024 at 11:06 AM Jason Wang <jasowang@xxxxxxxxxx> wrote:
>
> On Mon, Jul 29, 2024 at 2:03 PM Srivatsa Vaddagiri
> <quic_svaddagi@xxxxxxxxxxx> wrote:
> >
> > * Jason Wang <jasowang@xxxxxxxxxx> [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/20240726070609.GB723942@xxxxxxxxxxx/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
> >






[Index of Archives]     [KVM Development]     [Libvirt Development]     [Libvirt Users]     [CentOS Virtualization]     [Netdev]     [Ethernet Bridging]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite Forum]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux