virtualization.lists.linux-foundation.org archive mirror
 help / color / mirror / Atom feed
From: Srivatsa Vaddagiri <quic_svaddagi@quicinc.com>
To: <xieyongji@bytedance.com>, <jasowang@redhat.com>, <stefanha@redhat.com>
Cc: <virtio-dev@lists.linux.dev>, <virtualization@lists.linux.dev>,
	<quic_svaddagi@quicinc.com>, <quic_mnalajal@quicinc.com>,
	<quic_eberman@quicinc.com>, <quic_pheragu@quicinc.com>,
	<quic_pderrin@quicinc.com>, <quic_cvanscha@quicinc.com>,
	<quic_pkondeti@quicinc.com>, <quic_tsoni@quicinc.com>
Subject: [RFC] vduse config write support
Date: Wed, 24 Jul 2024 09:08:16 +0530	[thread overview]
Message-ID: <20240724033816.GD492231@quicinc.com> (raw)

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:

https://patchwork.kernel.org/project/netdevbpf/patch/20210615141331.407-11-xieyongji@bytedance.com/

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)?

Thanks
vatsa

             reply	other threads:[~2024-07-24  3:38 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-24  3:38 Srivatsa Vaddagiri [this message]
2024-07-26  2:37 ` [RFC] vduse config write support Yongji Xie
2024-07-26  7:06   ` Srivatsa Vaddagiri
2024-07-26  2:47 ` Jason Wang
2024-07-26  5:15   ` Michael S. Tsirkin
2024-07-29  2:06     ` Jason Wang
2024-07-26  7:03   ` Srivatsa Vaddagiri
2024-07-26  7:29     ` Michael S. Tsirkin
2024-07-29  2:16     ` Jason Wang
2024-07-29  6:02       ` Srivatsa Vaddagiri
2024-07-30  3:06         ` Jason Wang
2024-07-30  3:10           ` Jason Wang
2024-07-26 12:42   ` Srivatsa Vaddagiri
2024-07-30  2:53     ` Jason Wang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240724033816.GD492231@quicinc.com \
    --to=quic_svaddagi@quicinc.com \
    --cc=jasowang@redhat.com \
    --cc=quic_cvanscha@quicinc.com \
    --cc=quic_eberman@quicinc.com \
    --cc=quic_mnalajal@quicinc.com \
    --cc=quic_pderrin@quicinc.com \
    --cc=quic_pheragu@quicinc.com \
    --cc=quic_pkondeti@quicinc.com \
    --cc=quic_tsoni@quicinc.com \
    --cc=stefanha@redhat.com \
    --cc=virtio-dev@lists.linux.dev \
    --cc=virtualization@lists.linux.dev \
    --cc=xieyongji@bytedance.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).