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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 25.04.12 at 04:46, "Hao, Xudong" <xudong.hao@xxxxxxxxx> wrote:
>>  -----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)".  

No - if the guest asks the host to call pci_enable_ltr(), it'll imply enabling
for the entire path (as that's what the call results in). Which imo is better
than enabling a feature upfront, just in case.

Jan


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