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/
Home Products Support Community News


Re: [Xen-devel] Re: APIC rework

To: "Zhang, Xiantao" <xiantao.zhang@xxxxxxxxx>
Subject: Re: [Xen-devel] Re: APIC rework
From: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
Date: Mon, 30 Nov 2009 09:34:19 -0500
Cc: Jeremy Fitzhardinge <jeremy@xxxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, "Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx>, "Han, Weidong" <weidong.han@xxxxxxxxx>, Keir@xxxxxxxxxxxxxxxxxxxx, Fraser <keir.fraser@xxxxxxxxxxxxx>
Delivery-date: Mon, 30 Nov 2009 06:36:07 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <706158FABBBA044BAD4FE898A02E4BC201CD419656@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
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/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <706158FABBBA044BAD4FE898A02E4BC201CD3207E0@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <C72970BC.C323%keir.fraser@xxxxxxxxxxxxx> <706158FABBBA044BAD4FE898A02E4BC201CD3A074E@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <20091124194401.GA29566@xxxxxxxxxxxxxxxxxxx> <706158FABBBA044BAD4FE898A02E4BC201CD3A08EB@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <20091125134144.GA2586@xxxxxxxxxxxxxxxxxxx> <706158FABBBA044BAD4FE898A02E4BC201CD419316@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <20091125180031.GA5531@xxxxxxxxxxxxxxxxxxx> <706158FABBBA044BAD4FE898A02E4BC201CD419656@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.19 (2009-01-05)
> > During boot the device can be owned by pciback or by the modele for
> > which a 
> > PCI entry exist. Look for pciback.hide entry.
> > 
> > There are two modes of execution:
> >  1). First being what you described wherein the device initially
> >      belogs to Dom0. The user unbinds it from the PCI device and
> >      binds it to the pciback module. At that point, the device is
> >      disabled and ready for PV guests. When a PV guest starts pciback
> >      module makes the pci_enable_device call and sets the IRQ, etc
> >      for the device (for MSI, it obviously gets the IDT value from
> >  the hypervisor call). 2). Dom0 boots where the user specified on the
> >      command line pciback.hide=(0000:01:03.1). The pciback owns the
> >      device (is binded to it) and the native module that would load
> > for this PCI device is not called. 
> > 
> > It is correct that the unmapping/mapping and the ownership needs to
> > be dynamic. As user could bind to the pciback module, give it to
> > guest, kill the guest, then map the PCI device back to dom0, and
> > after that repeat the whole thing.
> If only the above two cases are needed to support, I think my patch should 
> meet the requirement. This is because once the device is hidden by the 
> pciback, the pirq unmap logic should be callled in both cases. So it the 
> mapping for dom0 should be cleared in the operation, so there is not the 
> issue you figured.  :-)

Ah, what about maping the device to a guest? That is not neccessary? Or are you
saying that the PV guest should be making a hypervisor call to 
PHYSDEVOP_map_pirq and
it will map the device itself? I thought those calls in the Hypervisor
were guarded by a IS_PRIV(xx) which would expel a PV guest. The other 
complication is
that the PV guests have their own PCI subsystem (look in arch/x86/pci/xen.c)
which only calls 'xen_allocate_pirq' to setup the chip_data to xen_pirq_chip.

The next call the PV guest does is to startup_pirq.

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

Xen-devel mailing list

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