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] Communication between HVM and dom0 through the Hyperviso

To: "Mark Williamson" <mark.williamson@xxxxxxxxxxxx>
Subject: RE: [Xen-devel] Communication between HVM and dom0 through the Hypervisor
From: "Petersson, Mats" <Mats.Petersson@xxxxxxx>
Date: Thu, 19 Apr 2007 16:21:56 +0200
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, Daniele Sgandurra <dansgan@xxxxxxxx>
Delivery-date: Thu, 19 Apr 2007 07:20:55 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <200704191507.00155.mark.williamson@xxxxxxxxxxxx>
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: AceCjEYmhbkheUEzSn2Z8GM2hV9pBwAAFiKw
Thread-topic: [Xen-devel] Communication between HVM and dom0 through the Hypervisor
 

> -----Original Message-----
> From: M.A. Williamson [mailto:maw48@xxxxxxxxxxxxxxxx] On 
> Behalf Of Mark Williamson
> Sent: 19 April 2007 15:07
> To: Petersson, Mats
> Cc: xen-devel@xxxxxxxxxxxxxxxxxxx; Daniele Sgandurra
> Subject: Re: [Xen-devel] Communication between HVM and dom0 
> through the Hypervisor
> 
> > > It it possible to arrange for a VMEXIT to occur on int 0x80
> > > (which IIRC is the
> > > Linux system call...  I guess VT-x would also be able to
> > > intercept sysenter)?
> > > That way the guest wouldn't have to be modified to notify
> > > Xen.  Xen would
> > > then have to e.g. share a ring buffer with dom0 regarding
> > > events of this
> > > nature for each domain.  You could hack something up so that
> > > the guest
> > > blocked on each syscall until dom0 acknowledged it...
> >
> > Now,that's a brilliant idea. Why didn't I think of that.
> >
> > Only one minor problem: It will only work for INT n 
> instructions (but
> > since it's possible to hide SYSENTER/SYSCALL instrutions 
> from the guest
> > via CPUID intercept, it can at least for 32-bit be forced 
> to only do INT
> > 80h calls), and only on AMD processors (this is more of a 
> problem, as
> > the original post talks about Intel processors). Intel 
> processors don't
> > allow intercepts of INT n instructions. Neither processor allow
> > intercepts of SYSENTER/SYSCALL instructions. [It's still a very good
> > idea, and I wish I had at least THOUGHT of it!]
> 
> Perhaps on intel, something could be bodged together?  E.g. 
> intercept loading 
> the IDT and replace the handler for the int n you're 
> interested in with 
> something that'll cause a trap?  I'm not really clear out 
> sysenter etc 
> actually works, so not so sure about that.

Possibly. The obvious solution of just stuffing an invalid value in CS
would perhaps work, and then fix up CS and "continue". Of course, the
difficulty may well be that IDT isn't actually hard-coded, so the IDT
entry for INT 80h isn't in the IDT when it's written to - of course, we
could change the IDT to an "invalid" address so that it generates a
page-fault, identify that it's the IDT and then set the entries manually
in the page-fault handler. Ideally, for this, you'd want to set the IDT
read-only, and then trap only on writes - that way there's no penalty on
interrupt traffic itself (which only reads the IDT). 

SYSENTER/SYSCALL uses MSR's to determine the RIP, RSP, CS etc. Not sure
if it's possible to set those up with a bad register (CS) or some such -
possibly it will work - it's possible to intercept the MSR writes to
these registers (in fact Intel does for some of them already, if not
all). 

An alternative to an invalid CS is an invalid RIP that causes a
page-fault, and replace the RIP with the correct value (as per the
MSR/IDT write). If the RIP is wrong, I expect the trap to come after the
IDT has been read and the old values stored on the stack - not quite
sure if that's the case for invalid CS for example, so using an invalid
RIP value may be better]. 

> 
> I did read through the VT-x / VT-i manuals at some stage, but 
> it's a long time 
> ago and things are a bit hazy now :-)

I had to look it up, so I don't expect someone who isn't actively
working on HVM-stuff to know these type of things. 

--
Mats
> 
> Cheers,
> Mark
> 
> -- 
> Dave: Just a question. What use is a unicyle with no seat?  
> And no pedals!
> Mark: To answer a question with a question: What use is a skateboard?
> Dave: Skateboards have wheels.
> Mark: My wheel has a wheel!
> 
> 
> 



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