Re: [Qemu-devel] [PATCH v10 3/6] tpm: allocate/map buffer for TPM Physical Presence interface

[Juan Quintela <quintela@redhat.com>]

Marc-André Lureau <marcandre.lureau@gmail.com> wrote:
Hi

>> > Physical RAM is multiple of TARGET_PAGE_SIZE O:-)
>> > That assumtion is held in too many places, if you can change the size to
>> > be multiple of page size, that would be greate.
>
> It needs the RAMBlock to be a multiple of TARGET_PAGE_SIZE, but the
> memory region (in guest and qemu MemoryRegion) can be less. This is
> already the case with for ex, "/rom@etc/acpi/rsdp", which is 36 bytes.
>
> I suppose 2 different MemoryRegions (backed by different RAMBlock)
> that would be placed on the same page (for ex, at offset 0x0, size
> 0x10 and offset 0x10, size 0x100) would work fine in general and with
> migration?

Honestly I don't know.  But if the ramblock is correct, I think that we
have no problem at all.  Migration code just does:

for each ramblock
  for each page in ramblock

(Yes, I know,  I have oversimplified)

>> > > Should the migration code be fixed, or should the TPM code allocate
>> > > ram differently?
>> >
>> > Migration people (i.e. me) would preffer that you fix the TPM
>> > allocation.  Or you can decide that this is *not* RAM.  The unit of
>> > transfer for migrate ram is ram pages, a.k.a. TARGET_PAGE_SIZE.
>> I'd loath to waste whole page in already cramped area.
>> Can we implement it as mmio region? (it will add some bolerplate
>> code for read/write
>> handlers/migration and cause vmexits on every read/write but it's
>> not a hot path so we might not care)
>>
>
>
> I have done some small adjustments to allow
> memory_region_init_ram_device_ptr() to work with a MemoryRegions size
> != backed RAMBlock, and it seems to work fine (and doesn't need to
> allocate more space of guest memory range, or fall back to mmio)

If the ramblock are full pages, everything should be ok.

Later, Juan.