Re: [PATCH 2/7] guest_memfd: Introduce an object to manage the guest-memfd with RamDiscardManager

[Peter Xu]

On Fri, Jan 24, 2025 at 04:56:50PM +1100, Alexey Kardashevskiy wrote:
> > Now, I assume Peter's real question is, if we can copy the vBIOS to a
> > private region and no need to create a specific guest_memfd-backed
> > memory region for it?

Yes.

> 
> I guess we can copy it but we have pc.bios and pc.rom in own memory regions
> for some reason even for legacy non-secure VMs, for ages, so it has little
> or nothing to do with whether vBIOS is in private or shared memory. Thanks,

My previous question is whether they are required to be converted to be
guest-memfd backed memory regions, irrelevant of whether they're separate
or not.

I think I found some answers in the commit logs here (it isn't hiding too
deep; I could have tried when asking):

===8<===
commit fc7a69e177e4ba26d11fcf47b853f85115b35a11
Author: Michael Roth <michael.roth@amd.com>
Date:   Thu May 30 06:16:40 2024 -0500

    hw/i386: Add support for loading BIOS using guest_memfd
    
    When guest_memfd is enabled, the BIOS is generally part of the initial
    encrypted guest image and will be accessed as private guest memory. Add
    the necessary changes to set up the associated RAM region with a
    guest_memfd backend to allow for this.
    
    Current support centers around using -bios to load the BIOS data.
    Support for loading the BIOS via pflash requires additional enablement
    since those interfaces rely on the use of ROM memory regions which make
    use of the KVM_MEM_READONLY memslot flag, which is not supported for
    guest_memfd-backed memslots.

commit 413a67450750e0459efeffc3db3ba9759c3e381c
Author: Michael Roth <michael.roth@amd.com>
Date:   Thu May 30 06:16:39 2024 -0500

    hw/i386/sev: Use guest_memfd for legacy ROMs
    
    Current SNP guest kernels will attempt to access these regions with
    with C-bit set, so guest_memfd is needed to handle that. Otherwise,
    kvm_convert_memory() will fail when the guest kernel tries to access it
    and QEMU attempts to call KVM_SET_MEMORY_ATTRIBUTES to set these ranges
    to private.
    
    Whether guests should actually try to access ROM regions in this way (or
    need to deal with legacy ROM regions at all), is a separate issue to be
    addressed on kernel side, but current SNP guest kernels will exhibit
    this behavior and so this handling is needed to allow QEMU to continue
    running existing SNP guest kernels.
===8<===

So IIUC the CoCo VMs will assume they're somehow convertable memories or
they'll stop working I assume, at least on some existing hardwares.

Thanks,

-- 
Peter Xu