qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v10 6/6] tpm: add ACPI memory clear interface


From: Marc-André Lureau
Subject: Re: [Qemu-devel] [PATCH v10 6/6] tpm: add ACPI memory clear interface
Date: Tue, 18 Sep 2018 19:40:51 +0400

Hi

On Tue, Sep 11, 2018 at 6:19 PM Laszlo Ersek <address@hidden> wrote:
>
> +Alex, due to mention of 21e00fa55f3fd
>
> On 09/10/18 15:03, Marc-André Lureau wrote:
> > Hi
> >
> > On Mon, Sep 10, 2018 at 2:44 PM Dr. David Alan Gilbert
> > <address@hidden> wrote:
> >> (I didn't know about guest_phys_block* and would have probably just used
> >> qemu_ram_foreach_block )
> >>
> >
> > guest_phys_block*() seems to fit, as it lists only the blocks actually
> > used, and already skip the device RAM.
> >
> > Laszlo, you wrote the functions
> > (https://git.qemu.org/?p=qemu.git;a=commit;h=c5d7f60f0614250bd925071e25220ce5958f75d0),
> > do you think it's appropriate to list the memory to clear, or we
> > should rather use qemu_ram_foreach_block() ?
>
> Originally, I would have said, "use either, doesn't matter". Namely,
> when I introduced the guest_phys_block*() functions, the original
> purpose was not related to RAM *contents*, but to RAM *addresses*
> (GPAs). This is evident if you look at the direct child commit of
> c5d7f60f0614, namely 56c4bfb3f07f, which put GuestPhysBlockList to use.
> And, for your use case (= wiping RAM), GPAs don't matter, only contents
> matter.
>
> However, with the commits I mentioned previously, namely e4dc3f5909ab9
> and 21e00fa55f3fd, we now filter out some RAM blocks from the dumping
> based on contents / backing as well. I think? So I believe we should
> honor that for the wiping to. I guess I'd (vaguely) suggest using
> guest_phys_block*().
>
> (And then, as Dave suggests, maybe extend the filter to consider pmem
> too, separately.)

I looked a bit into skipping pmem memory. The issue is that RamBlock
and MemoryRegion have no idea they are actually used for nvram (you
could rely on hostmem.pmem flag, but this is optional), and I don't
see a clear way to figure this out.

I can imagine to retrieve the MemoryRegion from guest phys address,
then check the owner is TYPE_NVDIMM for example. Is this a good
solution?

There is memory_region_from_host(), is there a memory_region_from_guest() ?

thanks


-- 
Marc-André Lureau



reply via email to

[Prev in Thread] Current Thread [Next in Thread]