gt;>>>>>> Are these two patches still needed? ISTR they were written originally
>>>>>>>>> to deal with guest trying to use device that was previously assigned
>>>>>>>>> to
>>>>>>>>> another gue
t;>>>>> implementation in xl/libxl to be linux-only..
>>>>>>>> Are these two patches still needed? ISTR they were written originally
>>>>>>>> to deal with guest trying to use device that was previously assi
lr()
interface" is already applied in upstream linux kernel, so it's
not needed anymore]
"[Xen-devel] [PATCH V3 2/2] Xen/PCIback: Implement PCI
flr/slot/bus reset with 'reset' SysFS attribute":
https://lists.xen.org/archives/html/xen-devel/2017-12/msg00661.html
"[Xen-devel] [
not needed anymore]
"[Xen-devel] [PATCH V3 2/2] Xen/PCIback: Implement PCI flr/slot/bus reset with
'reset' SysFS attribute":
https://lists.xen.org/archives/html/xen-devel/2017-12/msg00661.html
"[Xen-devel] [PATCH V1 0/1] Xen/Tools: PCI reset using 'reset' SysFS attribute":
ht
y now realized I forgot to reply to this
>>> message earlier.
>>>
>>> afaik these patches are still needed. Håkon (CC'd) wrote to me in private
>>> that
>>> he gets a (dom0) Linux kernel crash if he doesn't have these patches
>>> applied.
>
tries FLR, and it looks like
> >> it was added relatively recently.
> >
> > Replying to an old thread.. I only now realized I forgot to reply to this
> > message earlier.
> >
> > afaik these patches are still needed. Håkon (CC'd) wrote to me in
t using 'reset' SysFS
> attribute":
> https://lists.xen.org/archives/html/xen-devel/2017-12/msg00659.html
> [Note that PATCH V3 1/2 "Drivers/PCI: Export pcie_has_flr() interface"
> is already applied in upstream linux kernel, so it's not needed anymore]
>
ed. Håkon (CC'd) wrote to me in private that
> he gets a (dom0) Linux kernel crash if he doesn't have these patches applied.
>
>
> Here are the links to both the linux kernel and libxl patches:
>
>
> "[Xen-devel] [PATCH V3 0/2] Xen/PCIback: PCI reset using 'r
tches are still needed. Håkon (CC'd) wrote to me in private that
he gets a (dom0) Linux kernel crash if he doesn't have these patches applied.
Here are the links to both the linux kernel and libxl patches:
"[Xen-devel] [PATCH V3 0/2] Xen/PCIback: PCI reset using 'reset' SysFS
attribute":
h
Hi,
On Tue, Oct 23, 2018 at 08:40:29PM +0200, Håkon Alstadheim wrote:
>
>
> Den 08. okt. 2018 16:32, skrev Boris Ostrovsky:
> >
> > Are these two patches still needed? ISTR they were written originally
> > to deal with guest trying to use device that was previously assigned to
> > another
On 10/3/18 11:51 AM, Pasi Kärkkäinen wrote:
> On Wed, Sep 19, 2018 at 11:05:26AM +0200, Roger Pau Monné wrote:
>> On Tue, Sep 18, 2018 at 02:09:53PM -0400, Boris Ostrovsky wrote:
>>> On 9/18/18 5:32 AM, George Dunlap wrote:
> On Sep 18, 2018, at 8:15 AM, Pasi Kärkkäinen wrote:
>
> Hi,
On Wed, Sep 19, 2018 at 11:05:26AM +0200, Roger Pau Monné wrote:
> On Tue, Sep 18, 2018 at 02:09:53PM -0400, Boris Ostrovsky wrote:
> > On 9/18/18 5:32 AM, George Dunlap wrote:
> > >
> > >> On Sep 18, 2018, at 8:15 AM, Pasi Kärkkäinen wrote:
> > >>
> > >> Hi,
> > >>
> > >> On Mon, Sep 17, 2018 at
On Tue, Sep 18, 2018 at 02:09:53PM -0400, Boris Ostrovsky wrote:
> On 9/18/18 5:32 AM, George Dunlap wrote:
> >
> >> On Sep 18, 2018, at 8:15 AM, Pasi Kärkkäinen wrote:
> >>
> >> Hi,
> >>
> >> On Mon, Sep 17, 2018 at 02:06:02PM -0400, Boris Ostrovsky wrote:
> >>> What about the toolstack changes?
On 9/18/18 5:32 AM, George Dunlap wrote:
>
>> On Sep 18, 2018, at 8:15 AM, Pasi Kärkkäinen wrote:
>>
>> Hi,
>>
>> On Mon, Sep 17, 2018 at 02:06:02PM -0400, Boris Ostrovsky wrote:
>>> What about the toolstack changes? Have they been accepted? I vaguely
>>> recall there was a discussion about those
> On Sep 18, 2018, at 8:15 AM, Pasi Kärkkäinen wrote:
>
> Hi,
>
> On Mon, Sep 17, 2018 at 02:06:02PM -0400, Boris Ostrovsky wrote:
>> On 9/16/18 7:43 AM, Pasi Kärkkäinen wrote:
>>> Hi,
>>>
>>> On Mon, Dec 18, 2017 at 12:32:11PM -0500, Boris Ostrovsky wrote:
On 12/18/2017 02:36 AM, Jan
Hi,
On Mon, Sep 17, 2018 at 02:06:02PM -0400, Boris Ostrovsky wrote:
> On 9/16/18 7:43 AM, Pasi Kärkkäinen wrote:
> > Hi,
> >
> > On Mon, Dec 18, 2017 at 12:32:11PM -0500, Boris Ostrovsky wrote:
> >> On 12/18/2017 02:36 AM, Jan Beulich wrote:
> >> On 15.12.17 at 20:52, wrote:
> >>>
On 9/16/18 7:43 AM, Pasi Kärkkäinen wrote:
> Hi,
>
> On Mon, Dec 18, 2017 at 12:32:11PM -0500, Boris Ostrovsky wrote:
>> On 12/18/2017 02:36 AM, Jan Beulich wrote:
>> On 15.12.17 at 20:52, wrote:
>>> +static int pcistub_device_reset(struct pci_dev *dev)
>>> +{
>>> + struct
Hi,
On Mon, Dec 18, 2017 at 12:32:11PM -0500, Boris Ostrovsky wrote:
> On 12/18/2017 02:36 AM, Jan Beulich wrote:
> On 15.12.17 at 20:52, wrote:
> > +static int pcistub_device_reset(struct pci_dev *dev)
> > +{
> > + struct xen_pcibk_dev_data *dev_data;
> > + bool
On 12/18/2017 02:36 AM, Jan Beulich wrote:
On 15.12.17 at 20:52, wrote:
> +static int pcistub_device_reset(struct pci_dev *dev)
> +{
> + struct xen_pcibk_dev_data *dev_data;
> + bool slot = false, bus = false;
> + struct pcistub_args arg = {};
>>> On 15.12.17 at 20:52, wrote:
+static int pcistub_device_reset(struct pci_dev *dev)
+{
+ struct xen_pcibk_dev_data *dev_data;
+ bool slot = false, bus = false;
+ struct pcistub_args arg = {};
+
+ if (!dev)
+ return
Jan,
One quick update on pcie_flr() specific implementation. Please see below.
+static int pcistub_device_reset(struct pci_dev *dev)
+{
+ struct xen_pcibk_dev_data *dev_data;
+ bool slot = false, bus = false;
+ struct pcistub_args arg = {};
+
+ if (!dev)
+
On 12/12/2017 9:01 AM, Jan Beulich wrote:
On 12.12.17 at 15:48, wrote:
Thanks Jan for your review comments. Please see below for my comments.
First of all - can you please do something about your reply style?
HTML mail should be avoided. You'll see that the (plain
>>> On 12.12.17 at 15:48, wrote:
> Thanks Jan for your review comments. Please see below for my comments.
First of all - can you please do something about your reply style?
HTML mail should be avoided. You'll see that the (plain text) reply
as a result is rather hard to
Thanks Jan for your review comments. Please see below for my
comments.
On 12/8/2017 3:34 AM, Jan Beulich
wrote:
On 07.12.17 at 23:21, wrote:
Due to the
>>> On 07.12.17 at 23:21, wrote:
> Due to the complexity with the PCI lock we cannot do the reset when a
> device is bound ('echo $BDF > bind') or when unbound ('echo $BDF > unbind')
> as the pci_[slot|bus]_reset also takes the same lock resulting in a
> dead-lock.
It
25 matches
Mail list logo