qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v3] hw/arm/virt: Add high MMIO PCI region


From: Igor Mammedov
Subject: Re: [Qemu-devel] [PATCH v3] hw/arm/virt: Add high MMIO PCI region
Date: Wed, 29 Jul 2015 14:05:19 +0200

On Wed, 29 Jul 2015 13:03:57 +0300
Pavel Fedin <address@hidden> wrote:

>  Hello!
> 
> > >  I'm not sure that ARM architecture has this machine_done callback.
> > Maybe this would help you,
> >    git grep machine_done
> 
>  Heh, i was not patient enough. I have already discovered this by myself, and 
> yes, "virt" uses the
> same mechanism. But, still, i perhaps can have problems with testing it.
> 
> > >  So, can we leave fixed layout for now?
> > I suppose we could, it just means that we will have to add version-ed 
> > machines like
> > it's done on x86 to keep memory layout on old machine type the same so that
> > hardware won't change under guest's feet unexpectedly.
> 
>  Why?
>  First, "virt" is completely virtual hardware. It does not exist in real 
> world.
>  Second, ARM architecture is flexible by definition. Guest is never expected 
> to use hardcoded
> addresses, it is expected to read device tree. And, if base address of RAM 
> changes, or base address
> of PCI region changes, nothing bad should happen.
Now imagine that guest was started on host with 'old' layout and then has been
migrated to a host with 'new' layout. Stability of layout matters, that's why
we support versioned machine types and compat nightmare even if basic machine
is the same, the same applies to ARM's virt machine.

> 
> > Also in light of guests with huge memory size, 512Gb  gap for RAM seems too 
> > small,
> > what are limitations of ARM64 regarding max supported physical address bits?
> 
>  40 bits IIRC.
> 
> > Could we put this 64 bit PCI hole at the end of address space, leaving the 
> > rest of
> > address space for RAM or whatever?
> 
>  I've done exactly this. Start = 512GB and size = 512GB. 
> 0x8000000000...0xFFFFFFFFFF. I've done this
> after Paolo's comment that 2G is still small. And i agree because single 
> ivshmem could be used by
> lots of VMs.
> 
> Kind regards,
> Pavel Fedin
> Expert Engineer
> Samsung Electronics Research center Russia
> 
> 




reply via email to

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