Marc-André Lureau <marcandre.lur...@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.
