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

Re: [Xen-devel] VMX status report. Xen: #17702 & Xen0: #559 -- nonew issue


  • To: "Xu, Dongxiao" <dongxiao.xu@xxxxxxxxx>, "Li, Haicheng" <haicheng.li@xxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
  • Date: Fri, 23 May 2008 09:51:01 +0100
  • Delivery-date: Fri, 23 May 2008 01:51:41 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: Aci8nAMmHt/Ie4mmT9iQiMEDjqnwXAADhxqjAABGt1AAANhIlwAAMZhQAAB9DFYAADKEyg==
  • Thread-topic: [Xen-devel] VMX status report. Xen: #17702 & Xen0: #559 -- nonew issue

One thought: in c/s 17690 Xin Xiaohui fixed superpage shattering in EPT
tables. Could there be a similar bug relating to superpage shattering in the
ordinary (non-EPT) p2m logic?

 -- Keir

On 23/5/08 09:45, "Keir Fraser" <keir.fraser@xxxxxxxxxxxxx> wrote:

> Okay, I have failed to repro this issue, but my test machine does not have
> 4G of memory, so I created a low-memory/high-memory split by placing the
> start of the MMIO 'hole' at 256MB rather than the usual 3.75GB. Doing this,
> for a 512MB Linux guest, did not cause the guest to crash. So I guess either
> you really do need to give the guest >4GB of RAM (i.e., it's not a
> split-across-the-MMIO-hole bug) and/or it's related to usage of EPT?
> 
> At least it looks like this one is not *my* bug. :-)
> 
>  -- Keir
> 
> On 23/5/08 09:37, "Xu, Dongxiao" <dongxiao.xu@xxxxxxxxx> wrote:
> 
>> Hi, Keir, 
>>     I think the problem may be not in the tools side, but in the shadow side.
>> I ever removed the shadow 2MB superpage support code in p2m.c, and the Linux
>> guest (hap=0, using shadow) can boot successful with more than 4G memory.
>> 
>> Thanks!
>> -- Dongxiao
>> 
>> -----Original Message-----
>> From: Keir Fraser [mailto:keir.fraser@xxxxxxxxxxxxx]
>> Sent: 2008年5月23日 16:26
>> To: Xu, Dongxiao; Li, Haicheng; xen-devel@xxxxxxxxxxxxxxxxxxx
>> Subject: Re: [Xen-devel] VMX status report. Xen: #17702 & Xen0: #559 -- nonew
>> issue
>> 
>> That means I broke memory allocation when I cleaned up the tools side of
>> that patch. I will look into it and fix it.
>> 
>>  -- Keir
>> 
>> On 23/5/08 09:06, "Xu, Dongxiao" <dongxiao.xu@xxxxxxxxx> wrote:
>> 
>>> Hi, Keir, 
>>>     This issue is caused by the 2MB superpage patch in Xen C/S 17645. It
>>> seems
>>> that any linux guest (hap=0, using shadow) with more than 4G memory will
>>> fail
>>> to boot (4095M memory can boot successful). I haven't tried EPT guest.
>>> 
>>> -- Dongxiao
>>> 
>>> -----Original Message-----
>>> From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>>> [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Keir Fraser
>>> Sent: 2008年5月23日 15:54
>>> To: Li, Haicheng; xen-devel@xxxxxxxxxxxxxxxxxxx
>>> Subject: Re: [Xen-devel] VMX status report. Xen: #17702 & Xen0: #559 --
>>> nonew
>>> issue
>>> 
>>> On 23/5/08 07:12, "Li, Haicheng" <haicheng.li@xxxxxxxxx> wrote:
>>> 
>>>> Old issues:
>>>> ==============================================
>>>> 1. linux guest kernel panic when booting up with 4G memory.
>>>> http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1255
>>> 
>>> Can you provide more info on this one? Linux version, configuration, etc?
>>> And/or send me the vmlinux/bzImage files privately to try to repro.
>>> 
>>>  -- Keir
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@xxxxxxxxxxxxxxxxxxx
>>> http://lists.xensource.com/xen-devel
>> 
>> 
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.