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] Anatomy of a trap

To: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Xen-devel] Anatomy of a trap
From: Mark Williamson <mark.williamson@xxxxxxxxxxxx>
Date: Wed, 27 Jun 2007 01:34:32 +0100
Cc: "Petersson, Mats" <Mats.Petersson@xxxxxxx>, Girish V <girish.xen@xxxxxxxxx>
Delivery-date: Tue, 26 Jun 2007 17:32:29 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <907625E08839C4409CE5768403633E0B02561E86@xxxxxxxxxxxxxxxxx>
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>
References: <907625E08839C4409CE5768403633E0B02561E86@xxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: KMail/1.9.6
Basically, "what Mats said" ;-)

> In the case where the guest is actually "causing the trap itself", then
> the hypervisor keeps a list of handlers for the respective guest, and it
> just calls that handler (do_guest_trap). This is set by the
> "do_set_trap_table", which is a hypercall function from the guest.

Also in the specific case of PV guests: paravirtualised guests can take system 
call software interupts directly without Xen having to get involved (although 
if privileged operations are required to implement the system call, Xen may 
need to get involved during the call handler).

> [1] Or a disk that isn't OWNED by DomU itself. DomU can only own entire
> PCI devices, such as disk controllers (e.g. a SCSI, SATA or IDE
> controller). It must own the WHOLE controller, as individual disks
> aren't separated well enough within the disk controller, and the context
> within the controller can only be consistant under one owner domain -
> unless we add an interface to the entire system to support multiple
> domain-locking from one device, and that wouldn't exactly be easy -
> every device driver in the entire Linux source code would have to be
> touched in MANY places. Since that's not likely to be feasible, the
> frontend/backend

Did something get missed off here?

Cheers,
Mark

> [2] The backend doesn't have to be in Dom0 - any domain can be made into
> a driver-domain. It is NORMALLY Dom0, but doesn't have to be. It'll be
> the driver domain that is being woken up - so if it's not Dom0, then
> Dom0 will have nothing at all to do with the trap.
>
> > I was wondering if there is some documentation on this or
> > someone may be able to help me out.
> > Thanks,
> > Girish
>
> Sorry, but I don't know of any direct documentation. You may want to
> look at .../xen/arch/x86/traps.c
> Particularly the functions:
> do_set_trap_table()
> do_guest_trap()
> .../linux*/arch/x86_64/kernel/traps-xen.c
> Particularly:
> trap_init()
>
> --
> Mats
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel



-- 
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

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