Laszlo Ersek <lersek@xxxxxxxxxx> 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. Regards, The confused teenager who can't make up his mind. >> Paolo >> -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
