From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: [PATCH 11/18 V2]: PVH xen: some misc changes like mtrr, intr, msi. Date: Tue, 19 Mar 2013 08:55:20 +0000 Message-ID: <5148360802000078000C6A27@nat28.tlf.novell.com> References: <20130315174605.4090e816@mantra.us.oracle.com> <514714C702000078000C6590@nat28.tlf.novell.com> <20130318182018.2fd92acb@mantra.us.oracle.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20130318182018.2fd92acb@mantra.us.oracle.com> Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Mukesh Rathor Cc: xen-devel List-Id: xen-devel@lists.xenproject.org >>> On 19.03.13 at 02:20, Mukesh Rathor wrote: > On Mon, 18 Mar 2013 12:21:11 +0000 > "Jan Beulich" wrote: > >> >>> On 16.03.13 at 01:46, Mukesh Rathor >> >>> wrote: >> > +++ b/xen/arch/x86/msi.c >> > @@ -787,10 +787,15 @@ static int msix_capability_init(struct >> > pci_dev *dev, >> > if ( !dev->msix_used_entries ) >> > { >> > - if ( rangeset_add_range(mmio_ro_ranges, >> > dev->msix_table.first, >> > + /* PVH: this is temporary only until linux msi.c is fixed. >> > See xen-devel >> > + * thread: "[PVH]: Help: msi.c". >> > + */ >> > + if ( !is_pvh_domain(dev->domain) && >> > + rangeset_add_range(mmio_ro_ranges, >> > dev->msix_table.first, dev->msix_table.last) ) >> > WARN(); >> > - if ( rangeset_add_range(mmio_ro_ranges, >> > dev->msix_pba.first, >> > + if ( !is_pvh_domain(dev->domain) && >> > + rangeset_add_range(mmio_ro_ranges, >> > dev->msix_pba.first, dev->msix_pba.last) ) >> > WARN(); >> > >> >> As already said before, the whole change above has my explicit >> NAK. >> Jan > > Do you have any suggestions? Do you want to hold off on entire xen patch > until we go fix linux for this? Or can we just omit this change in the next > V 3 and come back to this later. Would you be OK with that? If you can't get MSI (or perhaps just MSI-X) to work properly for PVH, failing the respective setup operations just for PVH guests would be the right approach - the guest has to be prepared to run without MSI generally anyway (minus devices that have no interrupt pin at all of course). Opening security holes certainly isn't acceptable, even for code that is considered experimental only (mostly because it way too easily happens that the experimental status then gets dropped without remembering all the pieces that need fixing). Jan