From mboxrd@z Thu Jan  1 00:00:00 1970
From: Tim Deegan <tim@xen.org>
Subject: Re: [RFC][PATCH 07/13] xen/passthrough: extend
 hypercall to support rdm reservation policy
Date: Thu, 23 Apr 2015 14:05:30 +0100
Message-ID: <20150423130530.GH10810@deinos.phlegethon.org>
References: <1428657724-3498-1-git-send-email-tiejun.chen@intel.com>
	<1428657724-3498-8-git-send-email-tiejun.chen@intel.com>
	<20150416154056.GI13441@deinos.phlegethon.org>
	<5538E65F.60903@intel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
Content-Disposition: inline
In-Reply-To: <5538E65F.60903@intel.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: "Chen, Tiejun" <tiejun.chen@intel.com>
Cc: kevin.tian@intel.com, wei.liu2@citrix.com, ian.campbell@citrix.com, andrew.cooper3@citrix.com, Ian.Jackson@eu.citrix.com, xen-devel@lists.xen.org, stefano.stabellini@citrix.com, JBeulich@suse.com, yang.z.zhang@intel.com
List-Id: xen-devel@lists.xenproject.org

At 20:32 +0800 on 23 Apr (1429821151), Chen, Tiejun wrote:
> >> +                if ( flag == XEN_DOMCTL_PCIDEV_RDM_TRY )
> >> +                {
> >> +                    printk(XENLOG_G_WARNING "Some devices may work failed .\n");
> >
> > This is a bit cryptic.  How about:
> >   "RMRR map failed.  Device %04x:%02x:%02x.%u and domain %d may be unstable.",
> > (and pass in the devfn from the caller so we can print the details of
> > the device).
> 
> Got it but we can't get SBDF here directly.
> 
> So just now we can have this line.
> 
>          {
>              if ( flag == XEN_DOMCTL_PCIDEV_RDM_TRY )
>                  dprintk(XENLOG_ERR VTDPREFIX,
>                          "RMRR mapping failed to pfn:%"PRIx64""
>                          " so Dom%d may be unstable.\n",
>                          base_pfn, d->domain_id);
>              else
>                  return err;
>          }
> 
> Certainly, we can extend rmrr_identity_mapping() to own its associated 
> SBDF as an input parameter (and bring some syncs) if you still think 
> this is necessary.

Yes please.  It makes it clear to the admin which device is causing
the problem.

> > "STRICT" might be a better word than "FORCE" (here and everywhere
> > else).  "FORCE" sounds like either Xen will assign the device even if
> > it's unsafe,  which is the opposite of what's meant IIUC.
> 
> This is definitely fine to me but this is derived from our policy based 
> on that previous design,
> 
> Global RDM parameter:
>      rdm = [ 'host, reserve=force/try' ]
> Per-device RDM parameter:
>      pci = [ 'sbdf, rdm_reserve=force/try' ]
> 
> Please refer to patch #1. So I guess we need a further agreement or 
> comments from other guys :)

Well, it was just a suggestion.  If other people are happy with
'force', I am too. :)

Tim.