qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [RFC PATCH v1 15/22] i386: sev: register RAM read/write


From: Brijesh Singh
Subject: Re: [Qemu-devel] [RFC PATCH v1 15/22] i386: sev: register RAM read/write ops for BIOS and PC.RAM region
Date: Wed, 14 Sep 2016 15:59:34 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0

Hi Paolo,

On 09/13/2016 06:05 PM, Paolo Bonzini wrote:


On 13/09/2016 16:49, Brijesh Singh wrote:

+    /* Register SEV read/write ops for the guest RAM */
+    if (kvm_sev_enabled())
+        memory_region_set_ram_ops(ram, kvm_sev_get_ram_ops());

If you don't actually need this one except for -kernel it would be very
nice, because then the hooks could be limited to cpu_memory_rw_debug.


Yes so far i see that we needing this only for -kernel option.

address_space_write and address_space_read are the central entry point
for device DMA, and calling mr->ram_ops->write from there seems very
wrong.  I'd rather make those hooks *ROM* read/write ops rather than RAM
read/write ops.


I will look into hooking up the callback into ROM read/write ops. I was thinking about adding a new argument in cpu_physical_memory_write_rom_internal()

void cpu_physical_memory_write_rom(AddressSpace *as, hwaddr addr,
                                   const uint8_t *buf, int len,
                                   WriteCB *cb)
{
   ....
   ptr = qemu_map_ram_ptr(mr->ram_block, addr1);

   if (cb)
     cb(ptr, buf, len)
   else
     memcpy(ptr, buf, len)
....

}

In case of SEV, we pass a CB function pointer which calls SEV API's to encrypt memory. Does this make sense?

-Brijesh






reply via email to

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