Re: [Xen-devel] [PATCH] Re-enable LTR/OBFF when device is owned by pciback

["Hao, Xudong" <xudong.hao@xxxxxxxxx>]

> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> Sent: Tuesday, April 24, 2012 2:49 PM
> To: Hao, Xudong
> Cc: xen-devel; konrad.wilk@xxxxxxxxxx
> Subject: RE: [Xen-devel] [PATCH] Re-enable LTR/OBFF when device is owned by
> pciback
> 
> >>> On 24.04.12 at 04:49, "Hao, Xudong" <xudong.hao@xxxxxxxxx> wrote:
> >> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> >> >>> On 22.04.12 at 17:25, "Hao, Xudong" <xudong.hao@xxxxxxxxx> wrote:
> >> > +        /* set default value */
> >> > +        unsigned long type = PCI_EXP_OBFF_SIGNAL_ALWAYS;
> >> > +        int snoop_lat_ns = 1024, nosnoop_lat_ns = 1024; /* 1024ns is max
> value */
> >> > +
> >> > +        /* Enable LTR and OBFF before do device assignment */
> >> > +        /* LTR(Latency tolerance reporting) allows devices to send 
> >> > messages
> to the
> >> > +         * root complex indicating their latency tolerance for snooped &
> unsnooped
> >> > +         * memory transactions.
> >> > +         */
> >> > +        pci_enable_ltr(dev);
> >> > +        pci_set_ltr(dev, snoop_lat_ns, nosnoop_lat_ns);
> >>
> >> Wouldn't the guest kernel be able to do this itself, as it's just playing
> > with bits in
> >> the PCIE capability structure, or the LTR extended one?
> >
> > There are two reasons I want to enable ltr/obff in host but not in guest.
> > 1) ltr/obff is not only for one device, enabling them need to enable the
> > whole pci bus, include root port, upstream and downstream port. It's
> complex
> > to let guest enable the whole path.
> 
> Then it would still be more clean to extend the pciif, allowing the guest
> to request enabling, or even better snoop the writes to the capabilities/
> LTR structures in pciback.
> 

Qemu only emulate the device which is assigned to guest, but it does not 
emulate the physic device's whole bus path. Seems allowing guest request 
enabling looks reasonable, but I think it's only applicable for "per device 
feature(that unnecessary to enable the whole pci path)".  

> > 2) LTR/obff are PCIE device capabilities2, current qemu did not support
> > exposing PCIe capabilities2 to guest.
> 
> Mostly the same here, except that adding support for these capabilities
> is obviously going to be needed.
> 
> Jan


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