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

[Tim Deegan <tim@xxxxxxx>]

At 14:59 +0100 on 23 Apr (1429801184), Jan Beulich wrote:
> >>> On 23.04.15 at 14:32, <tiejun.chen@xxxxxxxxx> wrote:
> > On 2015/4/16 23:40, Tim Deegan wrote:
> >> At 17:21 +0800 on 10 Apr (1428686518), Tiejun Chen wrote:
> >>> @@ -1851,7 +1857,14 @@ static int rmrr_identity_mapping(struct domain *d, 
> >>> bool_t map,
> >>>           if ( !is_hardware_domain(d) )
> >>>           {
> >>>               if ( (err = set_identity_p2m_entry(d, base_pfn, 
> >>> p2m_access_rw)) )
> >>> -                return err;
> >>> +            {
> >>> +                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.
> 
> I don't think we can, since a single RMRR may be associated with
> more than one device.

Ah, and we don't know which device we have in hand when we're doing
this?  Fair enough, just printing the address and domain will do then.

Tim.

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