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

RE: [Xen-devel] [PATCH] This patch fixes several issues related to vmxassist


  • To: "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx>
  • From: "Li, Xin B" <xin.b.li@xxxxxxxxx>
  • Date: Fri, 31 Mar 2006 01:02:16 +0800
  • Cc: Xen Devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Thu, 30 Mar 2006 17:04:06 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcZUGFKZwv439MTETae4ItAjzRTJagAAKWYQ
  • Thread-topic: [Xen-devel] [PATCH] This patch fixes several issues related to vmxassist

 

>-----Original Message-----
>From: Keir Fraser [mailto:Keir.Fraser@xxxxxxxxxxxx] 
>Sent: 2006年3月31日 0:38
>To: Li, Xin B
>Cc: Xen Devel
>Subject: Re: [Xen-devel] [PATCH] This patch fixes several 
>issues related to vmxassist
>
>
>On 30 Mar 2006, at 17:09, Li, Xin B wrote:
>
>> Changeset 9366 from Leendert is to support big real mode, in turn to
>> support the SYSLINUX/ISOLINUX.
>> so the address calculation is kludgy, the point here is to 
>identify if 
>> a
>> cpu is in big real mode, if so, we should use protected mode 
>addressing
>> even in real mode.
>
>Shouldn't we get the Xen portion of vmxassist help us with that, for 
>example by making the hidden descriptor info (base, limit, etc) 
>available to us? There's already a method for loading that 
>stuff out of 
>Xen, right?
>
>Looks to me as though the kludge won't work if you unluckily load a 
>real-mode segment value that happens to also reference a 'big segment' 
>in the currently registered GDT.

Yes, we may have potential bug here, maybe we should hold this patch and try to 
find a cleaner way.
-Xin


>
>  -- Keir
>

_______________________________________________
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®.