qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Igor Mammedov <imammedo@redhat.com>
To: Pavel Fedin <p.fedin@samsung.com>
Cc: 'Peter Maydell' <peter.maydell@linaro.org>,
	'Alexander Graf' <agraf@suse.de>,
	mst@redhat.com, 'QEMU Developers' <qemu-devel@nongnu.org>,
	pbonzini@redhat.com
Subject: Re: [Qemu-devel] [PATCH v3] hw/arm/virt: Add high MMIO PCI region
Date: Wed, 29 Jul 2015 11:32:45 +0200	[thread overview]
Message-ID: <20150729113245.31a46746@nial.brq.redhat.com> (raw)
In-Reply-To: <00da01d0c9dc$b39503e0$1abf0ba0$@samsung.com>

On Wed, 29 Jul 2015 11:58:11 +0300
Pavel Fedin <p.fedin@samsung.com> wrote:

>  Hello!
> 
> > I'm not sure  but fixed hole start/size might be a problem later when adding memory hotplug
> wasting
> > address space.
> 
>  But 'virt' machine entirely relies on fixed layout. And, we can always change it if we need to.
> 
> > 
> > On x86 we do it a little different, see call chain:
> >  acpi_setup -> build_ssdt ->
> >    i440fx_pcihost_get_pci_hole64_start -> pci_bus_get_w64_range
> >    ...                          _end -> ...
> > 
> > where acpi_setup() is called from pc_guest_info_machine_done() right before
> > guest starts and later after guest's BIOS(UEFI) initialized PCI devices.
> > 
> > Perhaps we should do the same for ARM as well, CCing Michael
> 
>  I took a look at the code. As far as i could understand, it iterates devices on the bus and finds
> out start of the lowest assigned region and end of the highest assigned region. Does it?
yep

>  I'm not sure that ARM architecture has this machine_done callback.
Maybe this would help you,
   git grep machine_done

> And, to tell the truth, i don't
> use EFI on my setup so i cannot test the thing.
>  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.

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?

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 am currently reworking the patch because i discovered
> problems with 32-bit guests. They simply truncate high word and end up in attempt to put PCI at
> 0x00000000 - 0xFFFFFFFF, fail, and do not work of course. So, my next version will have high MMIO
> only for 64-bit guests.
>  By the way, what is the most correct way to determine whether selected CPU is 32 or 64 bit?
> 
> Kind regards,
> Pavel Fedin
> Expert Engineer
> Samsung Electronics Research center Russia
> 
> 

  parent reply	other threads:[~2015-07-29  9:32 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-27 11:09 [Qemu-devel] [PATCH v3] hw/arm/virt: Add high MMIO PCI region Pavel Fedin
2015-07-27 13:26 ` Igor Mammedov
2015-07-27 14:36   ` Pavel Fedin
2015-07-27 15:18     ` Michael S. Tsirkin
2015-07-27 15:51       ` Peter Maydell
2015-07-29  8:58   ` Pavel Fedin
2015-07-29  9:03     ` Peter Maydell
2015-07-29  9:45       ` Pavel Fedin
2015-07-29  9:56         ` Peter Maydell
2015-07-29 11:16           ` Pavel Fedin
2015-07-29 11:45             ` Peter Maydell
2015-07-29 14:01               ` Pavel Fedin
2015-08-03  7:03               ` Pavel Fedin
2015-08-03  7:56                 ` Peter Maydell
2015-08-03  8:09                   ` Pavel Fedin
2015-08-03  9:48                     ` Peter Maydell
2015-08-03 10:20                       ` Pavel Fedin
2015-08-03 20:17                         ` Alexander Graf
2015-07-29  9:32     ` Igor Mammedov [this message]
2015-07-29 10:03       ` Pavel Fedin
2015-07-29 10:21         ` Peter Maydell
2015-07-29 12:05         ` Igor Mammedov
2015-07-29 12:13           ` Pavel Fedin
2015-07-29 12:35           ` Peter Maydell
2015-07-29  9:10 ` Igor Mammedov
2015-07-29  9:48   ` Pavel Fedin
2015-07-29 11:59     ` Igor Mammedov
2015-07-29 12:02       ` Pavel Fedin
2015-07-29 13:24         ` Igor Mammedov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150729113245.31a46746@nial.brq.redhat.com \
    --to=imammedo@redhat.com \
    --cc=agraf@suse.de \
    --cc=mst@redhat.com \
    --cc=p.fedin@samsung.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).