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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> 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.

> 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