QEMU upstream and memory registration

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

 



On 13.04.2010, at 14:59, Christoffer Dall wrote:

> Hi all.
> 
> I asked the question below on the QEMU mailing list, but haven't
> received a response. I figured maybe Hollis or Alex have been through
> the same considerations?
> 
> Thanks!
> 
> ---
> I am bringing changes from my implementation of KVM for ARM into the
> upstream version of QEMU and trying to do things right.
> 
> My concern is how to handle MMIO mapped device registration with KVM. In
> kvm_set_phys_mem(...) it's required that the flags are not >=
> IO_MEM_UNASSIGNED. However, for most of the devices, for instance
> connected to the integrator board, the cpu_register_physical_memory
> (called from hw/sysbus.c) uses dev->mmio[n].iofunc as argument for
> phys_offset.
> 
> As far as I can understand, this value will always result in flags >=
> IO_MEM_UNASSIGNED, since the iofunc value comes from
> cpu_register_io_memory(...).
> 
> Without fully understanding the different uses of phys_offset, I
> gather that my choices are these:
> 1. Change the call to cpu_register_physical_memory in hw/sysbus.c
> when KVM is enabled
> 2. Change the initialization of every device (seems very invasive)
> 3. Change kvm_set_phys_mem to deal specifically with ARM (seems like
> something more general for other architectures should be done).
> 
> I have tried looking at the PPC and x86 implementations, but it seems
> that the MMIO devices are not created with dedicated io zones. If
> anyone can explain this difference between the way it's done on ARM
> and either PPC or x86, it would for sure clear things up for me.

I have no idea what the io zones are, but in general you just don't register MMIO regions. You only register memory slots and that should all be done automatically by the existing generic kvm code.

Alex




[Index of Archives]     [Linux KVM]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux