From mboxrd@z Thu Jan  1 00:00:00 1970
From: Mukesh Rathor <mukesh.rathor@oracle.com>
Subject: Re: [RFC PATCH 11/16]: PVH xen: some misc changes like
 mtrr, intr, msi.
Date: Tue, 5 Feb 2013 16:31:40 -0800
Message-ID: <20130205163140.40e29a77@mantra.us.oracle.com>
References: <20130111180356.2eedfb82@mantra.us.oracle.com>
	<50F4031402000078000B5434@nat28.tlf.novell.com>
	<20130115170200.694907c4@mantra.us.oracle.com>
	<50F6885102000078000B616A@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <50F6885102000078000B616A@nat28.tlf.novell.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Jan Beulich <JBeulich@suse.com>
Cc: xen-devel <xen-devel@lists.xen.org>
List-Id: xen-devel@lists.xenproject.org

On Wed, 16 Jan 2013 10:00:33 +0000
"Jan Beulich" <JBeulich@suse.com> wrote:

> >>> On 16.01.13 at 02:02, Mukesh Rathor <mukesh.rathor@oracle.com>
> >>> wrote:
> > On Mon, 14 Jan 2013 12:07:32 +0000 "Jan Beulich"
> > <JBeulich@suse.com> wrote:
> >> >>> On 12.01.13 at 03:03, Mukesh Rathor <mukesh.rathor@oracle.com>
> >> > --- a/xen/arch/x86/msi.c	Fri Jan 11 16:34:17 2013 -0800
> >> > +++ b/xen/arch/x86/msi.c	Fri Jan 11 16:35:48 2013 -0800
> >> > @@ -766,10 +766,12 @@ static int msix_capability_init(struct p
> >> >          WARN_ON(rangeset_overlaps_range(mmio_ro_ranges,
> >> > dev->msix_pba.first, dev->msix_pba.last));
> >> >  
> >> > -        if ( rangeset_add_range(mmio_ro_ranges,
> >> > dev->msix_table.first, +/* PVH: for now we don't make the mmio
> >> > range readonly. See xen-devel for thread:
> >> > + * "[PVH]: Help: msi.c". When linux msi.c is fixed, pvh check
> >> > can be removed */
> >> > +        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();
> >> 
> >> I hope there is no plan for this to go in in this shape.
> > 
> > 
> > Can I ifdef it and make it go'able? Ifdef saying PVH is
> > experimental? Not sure who's working on the issue on linux side.
> 
> No, unless you intend the whole PVH code to become conditional,
> default off. You're widening a known security hole by suppressing
> this.

No, it's only for PVH that the rangesets are not added, and only
temporary so we've something working for PVH in xen, and others
can play with PVH, test, contribute fixes, etc... If it's a problem, I
can look into disabling MSI for PVH too? If no one picks up the
issue on the linux side, I can start looking at it too after xen patches
for phase I are checked in.

thanks,
M-