WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

RE: [Xen-devel] [PATCH] non-flat protected mode HVM support

To: "Jan Beulich" <jbeulich@xxxxxxxxxx>, "Trolle Selander" <trolle.selander@xxxxxxxxx>
Subject: RE: [Xen-devel] [PATCH] non-flat protected mode HVM support
From: "Petersson, Mats" <Mats.Petersson@xxxxxxx>
Date: Wed, 29 Nov 2006 16:42:10 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Wed, 29 Nov 2006 07:44:50 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <456DB30C.76E4.0078.0@xxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AccTyfTT/IwaYSLZTwOdLGQ9Ah3NfAAADaww
Thread-topic: [Xen-devel] [PATCH] non-flat protected mode HVM support
 

> -----Original Message-----
> From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx 
> [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of 
> Jan Beulich
> Sent: 29 November 2006 15:19
> To: Trolle Selander
> Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [Xen-devel] [PATCH] non-flat protected mode HVM support
> 
> >>> "Trolle Selander" <trolle.selander@xxxxxxxxx> 29.11.06 15:45 >>>
> >The assumption of zero base/limit still exists in insn_fetch in
> >x86_emulate.c. When an EXCEPTION_PF occurs and cs.base is non-zero,
> >x86_emulate_memop fails because it does not take cs.base 
> into account when
> >reading the instruction to be decoded/emulated from memory. 
> I had an email
> >discussion with Mats early last week about this and he made some
> >suggestions, but I didn't have a chance to really look at it until
> >yesterday, and by then you had done a lot of work on the zero segment
> >base/limit assumptions anyway. Looking at it now, I'm not 
> wholly sure what
> >would be the best way to pass this info to 
> x86_emulate_memop. Maybe extend
> >the struct x86_emulate_ctxt to include cs base (and 
> limits/attibutes)? Or
> >would that cause problems elsewhere?
> 
> Indeed, I didn't look outside the hvm directories. But it's 
> not just the instruction
> fetching there, there are other segment based operations in 
> there, too. Hence
> I think adding a callback to obtain the base address would be cleaner;
> hvm_get_segment_base() could be used in the hvm case, and a 
> simple function
> should be put in place for pv guest handling (for those, 
> assuming a zero base
> address seems reasonably safe at this point, since the 
> behavior of them is
> known, and if ever page table updates get done through 
> segments with non-
> zero base addresses this would need to be revisited.

There should be a per-domain function pointer to get the segment-data -
we can either allow this function pointer to be NULL (for non HVM-case),
in which case the base is assumed to be zero. Or implement a function
that just returns zero for non HVM domains. I'm thinking something like
this (written as a function for ease of explaining, rather than
efficiency - a macro may be better...)

unsigned long get_seg_base(int segno)
{
        if (current->get_segment_base)
                return current->get_segment_base;
        else
                return 0;
}

The if-statement should be leaner than calling a function that returns
zero... 

--
Mats


> 
> I'll try to take care of this unless you beat me.
> 
> Jan
> 
> 
> _______________________________________________
> 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

<Prev in Thread] Current Thread [Next in Thread>