[Top][All Lists]

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

Re: [Qemu-devel] [PATCH] KVM: x86: Add host physical address width capab

From: Bandan Das
Subject: Re: [Qemu-devel] [PATCH] KVM: x86: Add host physical address width capability
Date: Fri, 10 Jul 2015 11:45:15 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

Laszlo Ersek <address@hidden> writes:

> On 07/10/15 16:59, Paolo Bonzini wrote:
>> On 10/07/2015 16:57, Laszlo Ersek wrote:
>>>>> ... In any case, please understand that I'm not campaigning for this
>>>>> warning :) IIRC the warning was your (very welcome!) idea after I
>>>>> reported the problem; I'm just trying to ensure that the warning match
>>>>> the exact issue I encountered.
>>>> Yup.  I think the right thing to do would be to hide memory above the
>>>> limit.
>>> How so?
>>> - The stack would not be doing what the user asks for. Pass -m <a_lot>,
>>> and the guest would silently see less memory. If the user found out,
>>> he'd immediately ask (or set out debugging) why. I think if the user's
>>> request cannot be satisfied, the stack should fail hard.
>> That's another possibility.  I think both of them are wrong depending on
>> _why_ you're using "-m <a lot>" in the first place.
>> Considering that this really happens (on Xeons) only for 1TB+ guests,
> I reported this issue because I ran into it with a ~64GB guest. From my
> /proc/cpuinfo:
> model name      : Intel(R) Core(TM) i7 CPU       M 620  @ 2.67GHz
> address sizes   : 36 bits physical, 48 bits virtual
> I was specifically developing 64GB+ support for OVMF, and this
> limitation caused me to think that there was a bug in my OVMF patches.
> (There wasn't.) An error message from QEMU, advising me to turn off EPT,
> would have saved me many hours.

Right, I specifically reserved a system with 36 bits physical to reproduce
this and it was very easy to reproduce. If it's a hardware bug, I would say,
it's a very annoying one (if not serious). I wonder if Intel folks can
chime in.

> Thanks
> Laszlo
>> it's probably just for debugging and then hiding the memory makes some
>> sense.
Actually, I agree with Laszlo here. Hiding memory is synonymous to forcing the
user to use less for the -m argument as is failing. But failing and letting the
user do it himself can save hours of debugging.

The confused teenager who can't make up his mind.

>> Paolo

reply via email to

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