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

[Dr. David Alan Gilbert]

* Marc-André Lureau (address@hidden) wrote:
> 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 think the pmem flag is what we should use; the problem though is we
have two different pieces of semantics:
    a) PMEM - needs special flush instruction/calls
    b) PMEM - my data is persistent, please don't clear me

Do those always go together?

(Copying in Junyan He who added the RAM_PMEM flag)

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

No, I think it's upto whatever creates the region to set a flag
somewhere properly - there's no telling whether it'll always be NVDIMM
or some other object.

Dave

> There is memory_region_from_host(), is there a memory_region_from_guest() ?
> 
> thanks
> 
> 
> -- 
> Marc-André Lureau
--
Dr. David Alan Gilbert / address@hidden / Manchester, UK