From: Pavel Fedin <p.fedin@samsung.com>
To: 'Peter Maydell' <peter.maydell@linaro.org>
Cc: 'QEMU Developers' <qemu-devel@nongnu.org>,
'Igor Mammedov' <imammedo@redhat.com>,
'Paolo Bonzini' <pbonzini@redhat.com>,
'Alexander Graf' <agraf@suse.de>,
"'Michael S. Tsirkin'" <mst@redhat.com>
Subject: Re: [Qemu-devel] [PATCH v3] hw/arm/virt: Add high MMIO PCI region
Date: Wed, 29 Jul 2015 14:16:36 +0300 [thread overview]
Message-ID: <015b01d0c9f0$0981cd20$1c856760$@samsung.com> (raw)
In-Reply-To: <CAFEAcA_iPDveo0myLKECX2N8iNwqE0ucpH095xmN7hNNdKJFXA@mail.gmail.com>
Hello!
> It matters because you can run 32 bit guests in 64-bit-capable
> CPUs.
Yes, i know.
> I don't really want to have two different address layouts
> just to work around a kernel bug
They will not be really different. Just for 32-bit machines there will be no second MMIO window, and for 64-bit ones there will be. Nothing else will be different.
> if we could fix the kernel bug instead...
We could. But what about existing installations? They will be forced to upgrade kernels, we will not have backwards compatibility option. And users will complain that "my old VM stopped working with new qemu".
Well, this discussion seems to be stuck, so let's move on. What is your final word? Options are:
1. Include second region unconditionally. Old 32-bit guests will stop working.
2. Add machine option to specify second region size. For 64-bits it will default to something, for 32-bits it will default to 0 (= off). It will be possible to turn on the region for 32-bit machines explicitly.
3. Include second region only on 64-bit guests. 32-bit ones will wait until somebody needs it.
Your choice ?
P.S. My 3.19 guest has LPAE disabled in the configuration. Perhaps my fault, but still it's a potential problem.
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
next prev parent reply other threads:[~2015-07-29 11:16 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 [this message]
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
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='015b01d0c9f0$0981cd20$1c856760$@samsung.com' \
--to=p.fedin@samsung.com \
--cc=agraf@suse.de \
--cc=imammedo@redhat.com \
--cc=mst@redhat.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).