Re: [Xen-devel] [RFC][PATCH 07/13] xen/passthrough: extend hypercall to support rdm reservation policy

[Tim Deegan <tim@xxxxxxx>]

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.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel