Re: [PATCH v4 29/31] hw/i386/sev: Allow use of pflash in conjunction with -bios
On Mon, Jun 03, 2024 at 03:38:05PM GMT, Paolo Bonzini wrote: > On Mon, Jun 3, 2024 at 1:55 PM Daniel P. Berrangé wrote: > > I really wish we didn't have to introduce this though - is there really > > no way to make it possible to use pflash for both CODE & VARS with SNP, > > as is done with traditional VMs, so we don't diverge in setup, needing > > yet more changes up the mgmt stack ? > > No, you cannot use pflash for CODE in either SNP or TDX. The hardware > does not support it. > > One possibility is to only support non-pflash-based variable store. > This is not yet in QEMU, but it is how both AWS and Google implemented > UEFI variables and I think Gerd was going to work on it for QEMU. Yes, working on and off on it. Progress is slower that I wish it would be due to getting side tracked into other important edk2 things ... But, yes, the longer-term plan is that edk2 wouldn't manage the variable store itself. It will be either qemu (non-confidential setups), or the svsm (confidential setups). Where we are going to store svsm state (vtpm, efi vars, ...) is not fully clear yet. pflash is one option, but we are also checking out alternatives like virtio-blk (via virtio-mmio). take care, Gerd
Re: [Qemu-devel] [PATCH for-3.2 01/11] vhost-user: define conventions for vhost-user backends
Hi, > Unfortunately, vdev is not set before vhost_dev_start(). > > We could add the migration blocker there somehow? Sure. Just use migrate_add_blocker() to do that at any time (see qxl.c for an example). HTH, Gerd
Re: [Qemu-devel] [PATCH for-3.2 01/11] vhost-user: define conventions for vhost-user backends
Hi, > Right. The main issue is that we need to make sure only > in-tree devices are supported. Well, that is under debate right now, see: https://lists.gnu.org/archive/html/qemu-devel/2018-11/msg04912.html > vhost-user by design > is for out of tree users. It needn't be hard, > maybe it's enough to just make qemu launch these processes > as opposed to connecting to them on command line. Not sure this is a good idea, with security being one of the motivating factors to move device emulation to other processes. When libvirt launches the processes it can place them in separate sandboxes ... cheers, Gerd
Re: [Qemu-devel] [PATCH for-4.0 v2] configure: bump spice-server required version to 0.12.6
On Wed, Nov 28, 2018 at 02:54:09PM +, Daniel P. Berrangé wrote: > On Wed, Nov 28, 2018 at 06:46:37PM +0400, Marc-André Lureau wrote: > > Hi > > > > On Wed, Nov 28, 2018 at 6:33 PM Daniel P. Berrangé > > wrote: > > > > > > On Wed, Nov 28, 2018 at 06:21:35PM +0400, Marc-André Lureau wrote: > > > > Looking at chardev/spice.c code, I realize compilation was broken for > > > > a while with spice-server < 0.12.3. I propose to bump required version > > > > to 0.12.6, released 3y ago, instead of adding more #ifdef. > > > > > > As mentioned last time this patch was posted[1], any changes in the > > > min required versions should follow our supported build platforms > > > support statement: > > > > Sorry, I totally forgot that. > > > > > > > > https://qemu.weilnetz.de/doc/qemu-doc.html#Supported-build-platforms > > > > > > Preferrably the commit message should list the version in each of the > > > main distros, such as in a0722409bcb980ecdab8330d4c716a73c9fcb489 > > > > > > At a glance it looks like Debian Jessie is likely to be the determining > > > vote with 0.12.5 as its newest version. > > > > https://repology.org/metapackage/spice/versions > > > > Debian Oldstable > > oldstable/main spice 0.12.5 > > > > https://wiki.debian.org/DebianReleases > > > > ~June 6th 2020 (LTS) > > > > But the current stable, Stretch, was released on June 17th 2017. > > > > So we are stuck with spice server 0.12.5 until +2y, June 17th 2019 ? > > Yep, but that means one more dev cycle - 4.0 > > We're free to drop Jessie once QEMU 4.1 opens for development at > end of April / early May. Ok, lets just put the patch on hold then. I don't think it makes that much sense to jump to 0.12.5 now and 0.12.6 next year. cheers, Gerd
Re: [Qemu-devel] [PATCH v2] vhost-user: define conventions for vhost-user backends
On Sat, Oct 06, 2018 at 02:32:45AM +0400, Marc-André Lureau wrote: > Hi > > On Fri, Oct 5, 2018 at 7:59 PM Hoffmann, Gerd wrote: > > > > Hi, > > > > > For example, "virgl" support may not be implemented. This > > > --print-capabilities is a simple way to check what the backend > > > implements. > > > > What is the expected behavior in case virgl is implemented by the > > backend, but not available (due to lack of 3d hardware in the host for > > example) ? > > I would say either it fails at runtime, or the backend doesn't announce it. > > Would you want something else? Yes, one of the two, but we should clarify which one. I suspect "fail at runtime" is easier for libvirt, given that it libvirt must handle backend failures anyway ... cheers, Gerd
Re: [Qemu-devel] [PATCH v2] vhost-user: define conventions for vhost-user backends
Hi, > For example, "virgl" support may not be implemented. This > --print-capabilities is a simple way to check what the backend > implements. What is the expected behavior in case virgl is implemented by the backend, but not available (due to lack of 3d hardware in the host for example) ? cheers, Gerd
