From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: Re: APIC rework Date: Mon, 30 Nov 2009 09:34:19 -0500 Message-ID: <20091130143419.GB19527@phenom.dumpdata.com> References: <706158FABBBA044BAD4FE898A02E4BC201CD3207E0@pdsmsx503.ccr.corp.intel.com> <706158FABBBA044BAD4FE898A02E4BC201CD3A074E@pdsmsx503.ccr.corp.intel.com> <20091124194401.GA29566@phenom.dumpdata.com> <706158FABBBA044BAD4FE898A02E4BC201CD3A08EB@pdsmsx503.ccr.corp.intel.com> <20091125134144.GA2586@phenom.dumpdata.com> <706158FABBBA044BAD4FE898A02E4BC201CD419316@pdsmsx503.ccr.corp.intel.com> <20091125180031.GA5531@phenom.dumpdata.com> <706158FABBBA044BAD4FE898A02E4BC201CD419656@pdsmsx503.ccr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <706158FABBBA044BAD4FE898A02E4BC201CD419656@pdsmsx503.ccr.corp.intel.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: "Zhang, Xiantao" Cc: Jeremy Fitzhardinge , Xen-devel , "Jiang, Yunhong" , "Han, Weidong" , Keir@acsinet11.oracle.com, Fraser List-Id: xen-devel@lists.xenproject.org > > 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@lists.xensource.com > http://lists.xensource.com/xen-devel