All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: Laszlo Ersek <lersek@redhat.com>, Bandan Das <bsd@redhat.com>,
	qemu-devel@nongnu.org
Cc: kvm@vger.kernel.org, Eduardo Habkost <ehabkost@redhat.com>
Subject: Re: [PATCH] target-i386: Sanity check host processor physical address width
Date: Thu, 9 Jul 2015 15:04:15 +0200	[thread overview]
Message-ID: <559E714F.1080505@redhat.com> (raw)
In-Reply-To: <559E304B.4090706@redhat.com>



On 09/07/2015 10:26, Laszlo Ersek wrote:
>> > 
>> > Perhaps KVM could simply hide memory above the limit (i.e. treat it as
>> > MMIO), and the BIOS could remove RAM above the limit from the e820
>> > memory map?
> I'd prefer to leave the guest firmware*s* out of this... :)
> 
> E820 is a legacy BIOS concept. In OVMF we'd have to hack the memory
> resource descriptor HOBs (which in turn control the DXE memory space
> map, which in turn controls the UEFI memory map). Those HOBs are
> currently based on what the CMOS reports about the RAM available under
> and above 4GB.
> 
> It's pretty complex already (will get more complex with SMM support),
> and TBH, for working around such an obscure issue, I wouldn't like to
> complicate it even further...
> 
> After all, this is a host platform limitation. The solution should be to
> either move to a more capable host, or do it in software (disable EPT).

The reason I mentioned the firmware is because you could in principle
have the same issue on real hardware - say putting 128 GB on your
laptop.  The firmware should cope with it.

If OVMF does not use etc/e820, it can instead hack the values it reads
from CMOS, bounding them according to the CPUID value.

Paolo

WARNING: multiple messages have this Message-ID (diff)
From: Paolo Bonzini <pbonzini@redhat.com>
To: Laszlo Ersek <lersek@redhat.com>, Bandan Das <bsd@redhat.com>,
	qemu-devel@nongnu.org
Cc: Eduardo Habkost <ehabkost@redhat.com>, kvm@vger.kernel.org
Subject: Re: [Qemu-devel] [PATCH] target-i386: Sanity check host processor physical address width
Date: Thu, 9 Jul 2015 15:04:15 +0200	[thread overview]
Message-ID: <559E714F.1080505@redhat.com> (raw)
In-Reply-To: <559E304B.4090706@redhat.com>



On 09/07/2015 10:26, Laszlo Ersek wrote:
>> > 
>> > Perhaps KVM could simply hide memory above the limit (i.e. treat it as
>> > MMIO), and the BIOS could remove RAM above the limit from the e820
>> > memory map?
> I'd prefer to leave the guest firmware*s* out of this... :)
> 
> E820 is a legacy BIOS concept. In OVMF we'd have to hack the memory
> resource descriptor HOBs (which in turn control the DXE memory space
> map, which in turn controls the UEFI memory map). Those HOBs are
> currently based on what the CMOS reports about the RAM available under
> and above 4GB.
> 
> It's pretty complex already (will get more complex with SMM support),
> and TBH, for working around such an obscure issue, I wouldn't like to
> complicate it even further...
> 
> After all, this is a host platform limitation. The solution should be to
> either move to a more capable host, or do it in software (disable EPT).

The reason I mentioned the firmware is because you could in principle
have the same issue on real hardware - say putting 128 GB on your
laptop.  The firmware should cope with it.

If OVMF does not use etc/e820, it can instead hack the values it reads
from CMOS, bounding them according to the CPUID value.

Paolo

  reply	other threads:[~2015-07-09 13:04 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-08 22:42 [PATCH] target-i386: Sanity check host processor physical address width Bandan Das
2015-07-08 22:42 ` [Qemu-devel] " Bandan Das
2015-07-09  7:02 ` Laszlo Ersek
2015-07-09  7:02   ` [Qemu-devel] " Laszlo Ersek
2015-07-09  9:27   ` Igor Mammedov
2015-07-09  9:27     ` Igor Mammedov
2015-07-09 10:03     ` Laszlo Ersek
2015-07-09 10:03       ` Laszlo Ersek
2015-07-09 19:11       ` Bandan Das
2015-07-09 19:11         ` Bandan Das
2015-07-09 19:30         ` Laszlo Ersek
2015-07-09 19:30           ` Laszlo Ersek
2015-07-09  7:59 ` Paolo Bonzini
2015-07-09  7:59   ` [Qemu-devel] " Paolo Bonzini
2015-07-09  8:26   ` Laszlo Ersek
2015-07-09  8:26     ` [Qemu-devel] " Laszlo Ersek
2015-07-09 13:04     ` Paolo Bonzini [this message]
2015-07-09 13:04       ` Paolo Bonzini
2015-07-09 19:22       ` Bandan Das
2015-07-09 19:22         ` [Qemu-devel] " Bandan Das
2015-07-09 12:51 ` Igor Mammedov
2015-07-09 12:51   ` Igor Mammedov
2015-07-09 19:25   ` Bandan Das
2015-07-09 19:25     ` Bandan Das

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=559E714F.1080505@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=bsd@redhat.com \
    --cc=ehabkost@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=lersek@redhat.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.