[PATCH] xen vtd : set msi guest_masked 0 by default

[PATCH] xen vtd : set msi guest_masked 0 by default

[Jianzhong,Chang]

There are some problems when msi guest_masked is set to 1 by default.
When guest os is windows 2008 r2 server,
the device(eg X540-AT2 vf) is not initialized correctly.
Host will always receive message like this :"VF Reset msg received from vf".
Guest has network connectivity issues,
and can not correctly receive/send the packet.
So, guest_masked is set to 0 by default.

Signed-off-by: Jianzhong,Chang <changjzh@gmail.com>
---
 xen/arch/x86/msi.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/msi.c b/xen/arch/x86/msi.c
index 5a481f6..b4f60a3 100644
--- a/xen/arch/x86/msi.c
+++ b/xen/arch/x86/msi.c
@@ -512,7 +512,7 @@ void guest_mask_msi_irq(struct irq_desc *desc, bool_t mask)
 
 static unsigned int startup_msi_irq(struct irq_desc *desc)
 {
-    if ( unlikely(!msi_set_mask_bit(desc, 0, !!(desc->status & IRQ_GUEST))) )
+    if ( unlikely(!msi_set_mask_bit(desc, 0, 0) ))
         WARN();
     return 0;
 }
@@ -972,7 +972,7 @@ static int msix_capability_init(struct pci_dev *dev,
         entry->msi_attrib.entry_nr = msi->entry_nr;
         entry->msi_attrib.maskbit = 1;
         entry->msi_attrib.host_masked = 1;
-        entry->msi_attrib.guest_masked = 1;
+        entry->msi_attrib.guest_masked = 0;
         entry->msi_attrib.pos = pos;
         entry->irq = msi->irq;
         entry->dev = dev;
-- 
1.7.1

Re: [PATCH] xen vtd : set msi guest_masked 0 by default

[Jan Beulich]

>>> On 26.01.16 at 02:34, <changjzh@gmail.com> wrote:
> There are some problems when msi guest_masked is set to 1 by default.
> When guest os is windows 2008 r2 server,
> the device(eg X540-AT2 vf) is not initialized correctly.
> Host will always receive message like this :"VF Reset msg received from vf".
> Guest has network connectivity issues,
> and can not correctly receive/send the packet.
> So, guest_masked is set to 0 by default.

You describe a problem and half of your change, but there's no
connection between the two: What is actually wrong with current
behavior (matching the hardware's - MSI-X mask bits are set when
coming out of reset).

> --- a/xen/arch/x86/msi.c
> +++ b/xen/arch/x86/msi.c
> @@ -512,7 +512,7 @@ void guest_mask_msi_irq(struct irq_desc *desc, bool_t mask)
>  
>  static unsigned int startup_msi_irq(struct irq_desc *desc)
>  {
> -    if ( unlikely(!msi_set_mask_bit(desc, 0, !!(desc->status & IRQ_GUEST))) )
> +    if ( unlikely(!msi_set_mask_bit(desc, 0, 0) ))
>          WARN();
>      return 0;
>  }

Whether this part can go under "set ... by default" is highly
questionable. Plus, while this affects MSI and MSI-X, ...

> @@ -972,7 +972,7 @@ static int msix_capability_init(struct pci_dev *dev,
>          entry->msi_attrib.entry_nr = msi->entry_nr;
>          entry->msi_attrib.maskbit = 1;
>          entry->msi_attrib.host_masked = 1;
> -        entry->msi_attrib.guest_masked = 1;
> +        entry->msi_attrib.guest_masked = 0;
>          entry->msi_attrib.pos = pos;
>          entry->irq = msi->irq;
>          entry->dev = dev;

... this change affect MSI-X only, and doing some guessing from
what you write above I suspect you only really tested one of the
two cases.

So while the change _may_ be necessary, you'll need to do a
better job at explaining why you what you do.

Jan

Re: [PATCH] xen vtd : set msi guest_masked 0 by default

[Tian, Kevin]

> From: Jan Beulich
> Sent: Tuesday, January 26, 2016 8:57 PM
> To: Chang Jianzhong
> Cc: andrew.cooper3@citrix.com; keir@xen.org; xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] [PATCH] xen vtd : set msi guest_masked 0 by default
> 
> >>> On 26.01.16 at 02:34, <changjzh@gmail.com> wrote:
> > There are some problems when msi guest_masked is set to 1 by default.
> > When guest os is windows 2008 r2 server,
> > the device(eg X540-AT2 vf) is not initialized correctly.
> > Host will always receive message like this :"VF Reset msg received from vf".
> > Guest has network connectivity issues,
> > and can not correctly receive/send the packet.
> > So, guest_masked is set to 0 by default.
> 
> You describe a problem and half of your change, but there's no
> connection between the two: What is actually wrong with current
> behavior (matching the hardware's - MSI-X mask bits are set when
> coming out of reset).
> 

Agree. Jianzhong, could you elaborate how mask bit is related to
the error message above? Also instead of changing the behavior
completely, you need consider there must be a reason for 
guest_masked set to 1 originally. So when you fix one issue please
pay attention to not break other scenarios.

Thanks
Kevin

Re: [PATCH] xen vtd : set msi guest_masked 0 by default

[jzh Chang]

[-- Attachment #1.1: Type: text/plain, Size: 2651 bytes --]

2016-01-26 20:56 GMT+08:00 Jan Beulich <JBeulich@suse.com>:

> >>> On 26.01.16 at 02:34, <changjzh@gmail.com> wrote:
> > There are some problems when msi guest_masked is set to 1 by default.
> > When guest os is windows 2008 r2 server,
> > the device(eg X540-AT2 vf) is not initialized correctly.
> > Host will always receive message like this :"VF Reset msg received from
> vf".
> > Guest has network connectivity issues,
> > and can not correctly receive/send the packet.
> > So, guest_masked is set to 0 by default.
>
> You describe a problem and half of your change, but there's no
> connection between the two: What is actually wrong with current
> behavior (matching the hardware's - MSI-X mask bits are set when
> coming out of reset).
>
> > --- a/xen/arch/x86/msi.c
> > +++ b/xen/arch/x86/msi.c
> > @@ -512,7 +512,7 @@ void guest_mask_msi_irq(struct irq_desc *desc,
> bool_t mask)
> >
> >  static unsigned int startup_msi_irq(struct irq_desc *desc)
> >  {
> > -    if ( unlikely(!msi_set_mask_bit(desc, 0, !!(desc->status &
> IRQ_GUEST))) )
> > +    if ( unlikely(!msi_set_mask_bit(desc, 0, 0) ))
> >          WARN();
> >      return 0;
> >  }
>
> Whether this part can go under "set ... by default" is highly
> questionable. Plus, while this affects MSI and MSI-X, ...
>
>  If irq is owned by guest,in function msi_set_mask_bit():
...
bool_t flag = host || guest; //The flag should be true.
...
 writel(flag, entry->mask_base + PCI_MSIX_ENTRY_VECTOR_CTRL_OFFSET);
...
PCI device can not generate interrrupt.
windows guest can not change vector_ctrl_mask, guest os get abnormal status
of nic.

> > @@ -972,7 +972,7 @@ static int msix_capability_init(struct pci_dev *dev,
> >          entry->msi_attrib.entry_nr = msi->entry_nr;
> >          entry->msi_attrib.maskbit = 1;
> >          entry->msi_attrib.host_masked = 1;
> > -        entry->msi_attrib.guest_masked = 1;
> > +        entry->msi_attrib.guest_masked = 0;
> >          entry->msi_attrib.pos = pos;
> >          entry->irq = msi->irq;
> >          entry->dev = dev;
>
> ... this change affect MSI-X only, and doing some guessing from
> what you write above I suspect you only really tested one of the
> two cases.
>
> So while the change _may_ be necessary, you'll need to do a
> better job at explaining why you what you do.
>
Msi guest_masked is set to 0 in the original code, only msi-x guest_masked
is modifed in msix_capability_init() function by patch.

>
> Jan
>
>
This issue appears after commited the variable guest_mask.
Initialization operations of pci device may be changed in windows
guest,or Xen need to change the initial state of vtd pci device.
-- 
Jianzhong,Chang

[-- Attachment #1.2: Type: text/html, Size: 4217 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

Re: [PATCH] xen vtd : set msi guest_masked 0 by default

[Jan Beulich]

>>> On 07.03.16 at 09:12, <changjzh@gmail.com> wrote:
> 2016-01-26 20:56 GMT+08:00 Jan Beulich <JBeulich@suse.com>:
> 
>> >>> On 26.01.16 at 02:34, <changjzh@gmail.com> wrote:
>> > There are some problems when msi guest_masked is set to 1 by default.
>> > When guest os is windows 2008 r2 server,
>> > the device(eg X540-AT2 vf) is not initialized correctly.
>> > Host will always receive message like this :"VF Reset msg received from
>> vf".
>> > Guest has network connectivity issues,
>> > and can not correctly receive/send the packet.
>> > So, guest_masked is set to 0 by default.
>>
>> You describe a problem and half of your change, but there's no
>> connection between the two: What is actually wrong with current
>> behavior (matching the hardware's - MSI-X mask bits are set when
>> coming out of reset).
>>
>> > --- a/xen/arch/x86/msi.c
>> > +++ b/xen/arch/x86/msi.c
>> > @@ -512,7 +512,7 @@ void guest_mask_msi_irq(struct irq_desc *desc,
>> bool_t mask)
>> >
>> >  static unsigned int startup_msi_irq(struct irq_desc *desc)
>> >  {
>> > -    if ( unlikely(!msi_set_mask_bit(desc, 0, !!(desc->status &
>> IRQ_GUEST))) )
>> > +    if ( unlikely(!msi_set_mask_bit(desc, 0, 0) ))
>> >          WARN();
>> >      return 0;
>> >  }
>>
>> Whether this part can go under "set ... by default" is highly
>> questionable. Plus, while this affects MSI and MSI-X, ...
>>
>>  If irq is owned by guest,in function msi_set_mask_bit():
> ...
> bool_t flag = host || guest; //The flag should be true.
> ...
>  writel(flag, entry->mask_base + PCI_MSIX_ENTRY_VECTOR_CTRL_OFFSET);
> ...
> PCI device can not generate interrrupt.
> windows guest can not change vector_ctrl_mask, guest os get abnormal status
> of nic.

Here and below - I'm sorry, I do not understand what you're trying
to tell us, or how this is meant to extend beyond the original (too
vague) description of your change. Among unclear things is why
"windows guest can not change vector_ctrl_mask" - you again just
make statements without dealing with any of the why-s.

Please can you try to explain things by matching operations done
by the guest, qemu, and the hypervisor to the effect they have
on the state of the mask bit, and then point out which of those
steps needs changing or doesn't work as intended?

Jan

>> > @@ -972,7 +972,7 @@ static int msix_capability_init(struct pci_dev *dev,
>> >          entry->msi_attrib.entry_nr = msi->entry_nr;
>> >          entry->msi_attrib.maskbit = 1;
>> >          entry->msi_attrib.host_masked = 1;
>> > -        entry->msi_attrib.guest_masked = 1;
>> > +        entry->msi_attrib.guest_masked = 0;
>> >          entry->msi_attrib.pos = pos;
>> >          entry->irq = msi->irq;
>> >          entry->dev = dev;
>>
>> ... this change affect MSI-X only, and doing some guessing from
>> what you write above I suspect you only really tested one of the
>> two cases.
>>
>> So while the change _may_ be necessary, you'll need to do a
>> better job at explaining why you what you do.
>>
> Msi guest_masked is set to 0 in the original code, only msi-x guest_masked
> is modifed in msix_capability_init() function by patch.
> 
>>
>> Jan
>>
>>
> This issue appears after commited the variable guest_mask.
> Initialization operations of pci device may be changed in windows
> guest,or Xen need to change the initial state of vtd pci device.
> -- 
> Jianzhong,Chang




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

Re: xen vtd : set msi guest_masked 0 by default

[David Woodhouse]

[-- Attachment #1.1: Type: text/plain, Size: 2187 bytes --]

On Tue, 2016-01-26 at 09:34 +0800, Jianzhong,Chang wrote:
> There are some problems when msi guest_masked is set to 1 by default.
> When guest os is windows 2008 r2 server,
> the device(eg X540-AT2 vf) is not initialized correctly.
> Host will always receive message like this :"VF Reset msg received from vf".
> Guest has network connectivity issues,
> and can not correctly receive/send the packet.

In other words "the guest doesn't get any interrupts from the NIC".

> So, guest_masked is set to 0 by default.

This seems consistent with the PCI spec, which says that "After reset,
the state of all implemented Mask and Pending bits is 0 (no vectors are
masked and no messages are pending)."

That's what we *used* to have in Xen, before these commits changed it
to assume that IRQs were guest-masked by default:

https://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=ad28e42bd1d28d746988ed71654e8aa670629753
https://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=84d6add5593d865736831d150da7c38588f669f6

> --- a/xen/arch/x86/msi.c
> +++ b/xen/arch/x86/msi.c
> @@ -512,7 +512,7 @@ void guest_mask_msi_irq(struct irq_desc *desc, bool_t mask)
>  
>  static unsigned int startup_msi_irq(struct irq_desc *desc)
>  {
> -    if ( unlikely(!msi_set_mask_bit(desc, 0, !!(desc->status & IRQ_GUEST))) )
> +    if ( unlikely(!msi_set_mask_bit(desc, 0, 0) ))
>          WARN();
>      return 0;
>  }

In testing, this part actually seems to make the difference in
practice. Interrupts now work, and Windows guests have connectivity
again.

> @@ -972,7 +972,7 @@ static int msix_capability_init(struct pci_dev *dev,
>          entry->msi_attrib.entry_nr = msi->entry_nr;
>          entry->msi_attrib.maskbit = 1;
>          entry->msi_attrib.host_masked = 1;
> -        entry->msi_attrib.guest_masked = 1;
> +        entry->msi_attrib.guest_masked = 0;
>          entry->msi_attrib.pos = pos;
>          entry->irq = msi->irq;
>          entry->dev = dev;

That also seems correct though, since it reflects the actual state we
intend to emulate.

[-- Attachment #1.2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5213 bytes --]

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: xen vtd : set msi guest_masked 0 by default

[Roger Pau Monné]

On Mon, May 21, 2018 at 12:46:19PM +0100, David Woodhouse wrote:
> On Tue, 2016-01-26 at 09:34 +0800, Jianzhong,Chang wrote:
> > There are some problems when msi guest_masked is set to 1 by default.
> > When guest os is windows 2008 r2 server,
> > the device(eg X540-AT2 vf) is not initialized correctly.
> > Host will always receive message like this :"VF Reset msg received from vf".
> > Guest has network connectivity issues,
> > and can not correctly receive/send the packet.
> 
> In other words "the guest doesn't get any interrupts from the NIC".
> 
> > So, guest_masked is set to 0 by default.
> 
> This seems consistent with the PCI spec, which says that "After reset,
> the state of all implemented Mask and Pending bits is 0 (no vectors are
> masked and no messages are pending)."
> 
> That's what we *used* to have in Xen, before these commits changed it
> to assume that IRQs were guest-masked by default:
> 
> https://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=ad28e42bd1d28d746988ed71654e8aa670629753
> https://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=84d6add5593d865736831d150da7c38588f669f6
> 
> > --- a/xen/arch/x86/msi.c
> > +++ b/xen/arch/x86/msi.c
> > @@ -512,7 +512,7 @@ void guest_mask_msi_irq(struct irq_desc *desc, bool_t mask)
> >  
> >  static unsigned int startup_msi_irq(struct irq_desc *desc)
> >  {
> > -    if ( unlikely(!msi_set_mask_bit(desc, 0, !!(desc->status & IRQ_GUEST))) )
> > +    if ( unlikely(!msi_set_mask_bit(desc, 0, 0) ))
> >          WARN();
> >      return 0;
> >  }
> 
> In testing, this part actually seems to make the difference in
> practice. Interrupts now work, and Windows guests have connectivity
> again.
> 
> > @@ -972,7 +972,7 @@ static int msix_capability_init(struct pci_dev *dev,
> >          entry->msi_attrib.entry_nr = msi->entry_nr;
> >          entry->msi_attrib.maskbit = 1;
> >          entry->msi_attrib.host_masked = 1;
> > -        entry->msi_attrib.guest_masked = 1;
> > +        entry->msi_attrib.guest_masked = 0;
> >          entry->msi_attrib.pos = pos;
> >          entry->irq = msi->irq;
> >          entry->dev = dev;
> 
> That also seems correct though, since it reflects the actual state we
> intend to emulate.

Hm, I think I might have fixed this issue, see:

https://git.qemu.org/?p=qemu.git;a=commit;h=a8036336609d2e184fc3543a4c439c0ba7d7f3a2

And the Xen side:

http://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=69d99d1b223fc5082400374698ddd7486e5ea953

The original report of the issue is at:

https://lists.xenproject.org/archives/html/xen-devel/2017-07/msg00915.html

Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: xen vtd : set msi guest_masked 0 by default

[David Woodhouse]

[-- Attachment #1.1: Type: text/plain, Size: 302 bytes --]

On Mon, 2018-05-21 at 14:10 +0200, Roger Pau Monné wrote:
> 
> Hm, I think I might have fixed this issue, see:
> 
> https://git.qemu.org/?p=qemu.git;a=commit;h=a8036336609d2e184fc3543a4c439c0ba7d7f3a2

Hm, thanks. We'll look at porting that change to qemu-traditional which
still doesn't do it.

[-- Attachment #1.2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5213 bytes --]

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[PATCH qemu-xen-traditional] xen/pt: allow QEMU to request MSI unmasking at bind time

[Andra Paraschiv]

When a MSI interrupt is bound to a guest using
xc_domain_update_msi_irq (XEN_DOMCTL_bind_pt_irq) the interrupt is
left masked by default.

This causes problems with guests that first configure interrupts and
clean the per-entry MSIX table mask bit and afterwards enable MSIX
globally. In such scenario the Xen internal msixtbl handlers would not
detect the unmasking of MSIX entries because vectors are not yet
registered since MSIX is not enabled, and vectors would be left
masked.

Introduce a new flag in the gflags field to signal Xen whether a MSI
interrupt should be unmasked after being bound.

This also requires to track the mask register for MSI interrupts, so
QEMU can also notify to Xen whether the MSI interrupt should be bound
masked or unmasked

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Reported-by: Andreas Kinzler <hfp@posteo.de>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>

[Backported from commit a8036336609d2e184fc3543a4c439c0ba7d7f3a2
 https://git.qemu.org/?p=qemu.git;a=commit;h=a8036336609d2e184fc3543a4c439c0ba7d7f3a2
 https://xenbits.xen.org/gitweb/?p=qemu-xen.git;a=commit;h=a8036336609d2e184fc3543a4c439c0ba7d7f3a2]

Signed-off-by: Andra Paraschiv <andraprs@amazon.com>
---
 hw/pass-through.c | 23 +++++++++++++++++++++--
 hw/pass-through.h |  1 +
 hw/pt-msi.c       | 25 +++++++++++++++++++++----
 hw/pt-msi.h       |  9 +++++++++
 4 files changed, 52 insertions(+), 6 deletions(-)

diff --git a/hw/pass-through.c b/hw/pass-through.c
index 0b76585..c6cb60e 100644
--- a/hw/pass-through.c
+++ b/hw/pass-through.c
@@ -188,6 +188,9 @@ static int pt_word_reg_write(struct pt_dev *ptdev,
 static int pt_long_reg_write(struct pt_dev *ptdev,
     struct pt_reg_tbl *cfg_entry,
     uint32_t *value, uint32_t dev_value, uint32_t valid_mask);
+static int pt_mask_reg_write(struct pt_dev *ptdev,
+    struct pt_reg_tbl *cfg_entry,
+    uint32_t *value, uint32_t dev_value, uint32_t valid_mask);
 static int pt_cmd_reg_write(struct pt_dev *ptdev,
     struct pt_reg_tbl *cfg_entry,
     uint16_t *value, uint16_t dev_value, uint16_t valid_mask);
@@ -755,7 +758,7 @@ static struct pt_reg_info_tbl pt_emu_reg_msi_tbl[] = {
         .emu_mask   = 0xFFFFFFFF,
         .init       = pt_mask_reg_init,
         .u.dw.read  = pt_long_reg_read,
-        .u.dw.write = pt_long_reg_write,
+        .u.dw.write = pt_mask_reg_write,
     },
     /* Mask reg (if PCI_MSI_FLAGS_MASK_BIT set, for 64-bit devices) */
     {
@@ -766,7 +769,7 @@ static struct pt_reg_info_tbl pt_emu_reg_msi_tbl[] = {
         .emu_mask   = 0xFFFFFFFF,
         .init       = pt_mask_reg_init,
         .u.dw.read  = pt_long_reg_read,
-        .u.dw.write = pt_long_reg_write,
+        .u.dw.write = pt_mask_reg_write,
     },
     /* Pending reg (if PCI_MSI_FLAGS_MASK_BIT set, for 32-bit devices) */
     {
@@ -3572,6 +3575,22 @@ static int pt_long_reg_write(struct pt_dev *ptdev,
     return 0;
 }
 
+/* write guest mask bits */
+static int pt_mask_reg_write(struct pt_dev *ptdev,
+        struct pt_reg_tbl *cfg_entry,
+        uint32_t *value, uint32_t dev_value, uint32_t valid_mask)
+{
+    int rc;
+
+    rc = pt_long_reg_write(ptdev, cfg_entry, value, dev_value, valid_mask);
+    if (rc)
+        return rc;
+
+    ptdev->msi->mask = *value;
+
+    return 0;
+}
+
 /* write Command register */
 static int pt_cmd_reg_write(struct pt_dev *ptdev,
         struct pt_reg_tbl *cfg_entry,
diff --git a/hw/pass-through.h b/hw/pass-through.h
index bb6ddce..0b58224 100644
--- a/hw/pass-through.h
+++ b/hw/pass-through.h
@@ -191,6 +191,7 @@ struct pt_region {
 struct pt_msi_info {
     uint32_t flags;
     uint32_t ctrl_offset; /* saved control offset */
+    uint32_t mask;     /* guest mask bits */
     int pirq;          /* guest pirq corresponding */
     uint32_t addr_lo;  /* guest message address */
     uint32_t addr_hi;  /* guest message upper address */
diff --git a/hw/pt-msi.c b/hw/pt-msi.c
index c6baea9..8b06450 100644
--- a/hw/pt-msi.c
+++ b/hw/pt-msi.c
@@ -138,6 +138,9 @@ int pt_msi_update(struct pt_dev *d)
     addr = (uint64_t)d->msi->addr_hi << 32 | d->msi->addr_lo;
     gflags = __get_msi_gflags(d->msi->data, addr);
 
+    /* Current MSI emulation in QEMU only supports 1 vector */
+    gflags |= (d->msi->mask & 1) ? 0 : (1u << GLFAGS_SHIFT_UNMASKED);
+
     PT_LOG("Update msi with pirq %x gvec %x gflags %x\n",
            d->msi->pirq, gvec, gflags);
 
@@ -275,7 +278,8 @@ void pt_disable_msi_translate(struct pt_dev *dev)
     }
 }
 
-static int pt_msix_update_one(struct pt_dev *dev, int entry_nr)
+static int pt_msix_update_one(struct pt_dev *dev, int entry_nr,
+                              uint32_t vec_ctrl)
 {
     struct msix_entry_info *entry = &dev->msix->msix_entry[entry_nr];
     int pirq = entry->pirq;
@@ -316,6 +320,9 @@ static int pt_msix_update_one(struct pt_dev *dev, int entry_nr)
         entry->pirq = pirq;
     }
 
+    gflags |= (vec_ctrl & PCI_MSIX_ENTRY_CTRL_MASKBIT) ? 0 :
+        (1u << GLFAGS_SHIFT_UNMASKED);
+
     PT_LOG("Update msix entry %x with pirq %x gvec %x\n",
             entry_nr, pirq, gvec);
 
@@ -343,7 +350,7 @@ int pt_msix_update(struct pt_dev *dev)
 
     for ( i = 0; i < msix->total_entries; i++ )
     {
-        pt_msix_update_one(dev, i);
+        pt_msix_update_one(dev, i, msix->msix_entry[i].io_mem[3]);
     }
 
     return 0;
@@ -479,8 +486,18 @@ static void pci_msix_writel(void *opaque, target_phys_addr_t addr, uint32_t val)
 
     if ( offset == 3 )
     {
-        if ( msix->enabled && !(val & 0x1) )
-            pt_msix_update_one(dev, entry_nr);
+        if ( msix->enabled && !(val & 0x1) ) {
+            const volatile uint32_t *vec_ctrl;
+
+            /*
+             * If Xen intercepts the mask bit access, io_mem[3] may not be
+             * up-to-date. Read from hardware directly.
+             */
+            vec_ctrl = dev->msix->phys_iomem_base +
+                PCI_MSIX_ENTRY_SIZE * entry_nr + PCI_MSIX_ENTRY_VECTOR_CTRL;
+
+            pt_msix_update_one(dev, entry_nr, *vec_ctrl);
+        }
     }
 }
 
diff --git a/hw/pt-msi.h b/hw/pt-msi.h
index 94e0d35..a80d76e 100644
--- a/hw/pt-msi.h
+++ b/hw/pt-msi.h
@@ -33,6 +33,14 @@
 #define PCI_MSIX_PBA        8
 #define  PCI_MSIX_BIR       0x7
 
+/* MSI-X Table entry format */
+#define PCI_MSIX_ENTRY_SIZE             16
+#define  PCI_MSIX_ENTRY_LOWER_ADDR      0
+#define  PCI_MSIX_ENTRY_UPPER_ADDR      4
+#define  PCI_MSIX_ENTRY_DATA            8
+#define  PCI_MSIX_ENTRY_VECTOR_CTRL     12
+#define   PCI_MSIX_ENTRY_CTRL_MASKBIT   1
+
 #define MSI_FLAG_UNINIT 0x1000
 #define PT_MSI_MAPPED   0x2000
 
@@ -77,6 +85,7 @@
 #define GFLAGS_SHIFT_DM             9
 #define GLFAGS_SHIFT_DELIV_MODE     12
 #define GLFAGS_SHIFT_TRG_MODE       15
+#define GLFAGS_SHIFT_UNMASKED       16
 
 void
 msi_set_enable(struct pt_dev *dev, int en);
-- 
2.7.3.AMZN




Amazon Development Center (Romania) S.R.L. registered office: 27A Sf. Lazar Street, UBC5, floor 2, Iasi, Iasi County, 700045, Romania. Registered in Romania. Registration number J22/2621/2005.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: xen vtd : set msi guest_masked 0 by default

[Paraschiv, Andra-Irina]

On Wed, 2018-05-23 at 10:01 +0200, David Woodhouse wrote:
>
>On Mon, 2018-05-21 at 14:10 +0200, Roger Pau Monné wrote:
>>
>> Hm, I think I might have fixed this issue, see:
>>
>> https://git.qemu.org/?p=qemu.git;a=commit;h=a8036336609d2e184fc3543a4c439c0ba7d7f3a2
>
>Hm, thanks. We'll look at porting that change to qemu-traditional which
>still doesn't do it.

Backported patch to qemu-xen-traditional repo:
https://lists.xenproject.org/archives/html/xen-devel/2018-06/msg01248.html

Thank you.



Amazon Development Center (Romania) S.R.L. registered office: 27A Sf. Lazar Street, UBC5, floor 2, Iasi, Iasi County, 700045, Romania. Registered in Romania. Registration number J22/2621/2005.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH qemu-xen-traditional] xen/pt: allow QEMU to request MSI unmasking at bind time

[Roger Pau Monné]

On Mon, Jun 18, 2018 at 09:35:20AM +0000, Andra Paraschiv wrote:
> When a MSI interrupt is bound to a guest using
> xc_domain_update_msi_irq (XEN_DOMCTL_bind_pt_irq) the interrupt is
> left masked by default.
> 
> This causes problems with guests that first configure interrupts and
> clean the per-entry MSIX table mask bit and afterwards enable MSIX
> globally. In such scenario the Xen internal msixtbl handlers would not
> detect the unmasking of MSIX entries because vectors are not yet
> registered since MSIX is not enabled, and vectors would be left
> masked.
> 
> Introduce a new flag in the gflags field to signal Xen whether a MSI
> interrupt should be unmasked after being bound.
> 
> This also requires to track the mask register for MSI interrupts, so
> QEMU can also notify to Xen whether the MSI interrupt should be bound
> masked or unmasked
> 
> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
> Reviewed-by: Jan Beulich <jbeulich@suse.com>
> Reported-by: Andreas Kinzler <hfp@posteo.de>
> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
> Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
> 
> [Backported from commit a8036336609d2e184fc3543a4c439c0ba7d7f3a2
>  https://git.qemu.org/?p=qemu.git;a=commit;h=a8036336609d2e184fc3543a4c439c0ba7d7f3a2
>  https://xenbits.xen.org/gitweb/?p=qemu-xen.git;a=commit;h=a8036336609d2e184fc3543a4c439c0ba7d7f3a2]
> 
> Signed-off-by: Andra Paraschiv <andraprs@amazon.com>

Thanks for doing the backport, LGTM.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH qemu-xen-traditional] xen/pt: allow QEMU to request MSI unmasking at bind time

[Paraschiv, Andra-Irina]

+ Cc: Ian Jackson <ian.jackson@eu.citrix.com> for review.

Thanks, Roger, for review and feedback.

Andra
________________________________________
From: Roger Pau Monné <roger.pau@citrix.com>
Sent: Monday, June 18, 2018 2:43 PM
To: Paraschiv, Andra-Irina
Cc: xen-devel@lists.xenproject.org; sstabellini@kernel.org; jbeulich@suse.com; andrew.cooper3@citrix.com; Woodhouse, David
Subject: Re: [PATCH qemu-xen-traditional] xen/pt: allow QEMU to request MSI unmasking at bind time

On Mon, Jun 18, 2018 at 09:35:20AM +0000, Andra Paraschiv wrote:
> When a MSI interrupt is bound to a guest using
> xc_domain_update_msi_irq (XEN_DOMCTL_bind_pt_irq) the interrupt is
> left masked by default.
>
> This causes problems with guests that first configure interrupts and
> clean the per-entry MSIX table mask bit and afterwards enable MSIX
> globally. In such scenario the Xen internal msixtbl handlers would not
> detect the unmasking of MSIX entries because vectors are not yet
> registered since MSIX is not enabled, and vectors would be left
> masked.
>
> Introduce a new flag in the gflags field to signal Xen whether a MSI
> interrupt should be unmasked after being bound.
>
> This also requires to track the mask register for MSI interrupts, so
> QEMU can also notify to Xen whether the MSI interrupt should be bound
> masked or unmasked
>
> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
> Reviewed-by: Jan Beulich <jbeulich@suse.com>
> Reported-by: Andreas Kinzler <hfp@posteo.de>
> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
> Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
>
> [Backported from commit a8036336609d2e184fc3543a4c439c0ba7d7f3a2
>  https://git.qemu.org/?p=qemu.git;a=commit;h=a8036336609d2e184fc3543a4c439c0ba7d7f3a2
>  https://xenbits.xen.org/gitweb/?p=qemu-xen.git;a=commit;h=a8036336609d2e184fc3543a4c439c0ba7d7f3a2]
>
> Signed-off-by: Andra Paraschiv <andraprs@amazon.com>

Thanks for doing the backport, LGTM.



Amazon Development Center (Romania) S.R.L. registered office: 27A Sf. Lazar Street, UBC5, floor 2, Iasi, Iasi County, 700045, Romania. Registered in Romania. Registration number J22/2621/2005.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH qemu-xen-traditional] xen/pt: allow QEMU to request MSI unmasking at bind time

[Woodhouse, David]

[-- Attachment #1.1: Type: text/plain, Size: 2636 bytes --]

Ian, any objections?

Thanks.On Thu, 2018-06-21 at 08:37 +0000, Paraschiv, Andra-Irina wrote:
> + Cc: Ian Jackson <ian.jackson@eu.citrix.com> for review.
> 
> Thanks, Roger, for review and feedback.
> 
> Andra
> ________________________________________
> From: Roger Pau Monné <roger.pau@citrix.com>
> Sent: Monday, June 18, 2018 2:43 PM
> To: Paraschiv, Andra-Irina
> Cc: xen-devel@lists.xenproject.org; sstabellini@kernel.org; jbeulich@
> suse.com; andrew.cooper3@citrix.com; Woodhouse, David
> Subject: Re: [PATCH qemu-xen-traditional] xen/pt: allow QEMU to
> request MSI unmasking at bind time
> 
> On Mon, Jun 18, 2018 at 09:35:20AM +0000, Andra Paraschiv wrote:
> > 
> > When a MSI interrupt is bound to a guest using
> > xc_domain_update_msi_irq (XEN_DOMCTL_bind_pt_irq) the interrupt is
> > left masked by default.
> > 
> > This causes problems with guests that first configure interrupts
> > and
> > clean the per-entry MSIX table mask bit and afterwards enable MSIX
> > globally. In such scenario the Xen internal msixtbl handlers would
> > not
> > detect the unmasking of MSIX entries because vectors are not yet
> > registered since MSIX is not enabled, and vectors would be left
> > masked.
> > 
> > Introduce a new flag in the gflags field to signal Xen whether a
> > MSI
> > interrupt should be unmasked after being bound.
> > 
> > This also requires to track the mask register for MSI interrupts,
> > so
> > QEMU can also notify to Xen whether the MSI interrupt should be
> > bound
> > masked or unmasked
> > 
> > Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
> > Reviewed-by: Jan Beulich <jbeulich@suse.com>
> > Reported-by: Andreas Kinzler <hfp@posteo.de>
> > Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
> > Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
> > 
> > [Backported from commit a8036336609d2e184fc3543a4c439c0ba7d7f3a2
> >  https://git.qemu.org/?p=qemu.git;a=commit;h=a8036336609d2e184fc354
> > 3a4c439c0ba7d7f3a2
> >  https://xenbits.xen.org/gitweb/?p=qemu-xen.git;a=commit;h=a8036336
> > 609d2e184fc3543a4c439c0ba7d7f3a2]
> > 
> > Signed-off-by: Andra Paraschiv <andraprs@amazon.com>
> Thanks for doing the backport, LGTM.
> 
> 
> 
> Amazon Development Center (Romania) S.R.L. registered office: 27A Sf.
> Lazar Street, UBC5, floor 2, Iasi, Iasi County, 700045, Romania.
> Registered in Romania. Registration number J22/2621/2005.
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xenproject.org
> https://lists.xenproject.org/mailman/listinfo/xen-devel

[-- Attachment #1.2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5210 bytes --]

[-- Attachment #2.1: Type: text/plain, Size: 215 bytes --]




Amazon Development Centre (London) Ltd. Registered in England and Wales with registration number 04543232 with its registered office at 1 Principal Place, Worship Street, London EC2A 2FA, United Kingdom.



[-- Attachment #2.2: Type: text/html, Size: 228 bytes --]

[-- Attachment #3: Type: text/plain, Size: 157 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH qemu-xen-traditional] xen/pt: allow QEMU to request MSI unmasking at bind time

[Paraschiv, Andra-Irina]

>From: Woodhouse, David
>Sent: Tuesday, July 31, 2018 1:22 PM
>To: roger.pau@citrix.com; Paraschiv, Andra-Irina
>Cc: ian.jackson@eu.citrix.com; jbeulich@suse.com; sstabellini@kernel.org; andrew.cooper3@citrix.com; xen->devel@lists.xenproject.org
>Subject: Re: [Xen-devel] [PATCH qemu-xen-traditional] xen/pt: allow QEMU to request MSI unmasking at bind >time
>
>Ian, any objections?
>
>Thanks.On Thu, 2018-06-21 at 08:37 +0000, Paraschiv, Andra-Irina wrote:
>> + Cc: Ian Jackson <ian.jackson@eu.citrix.com> for review.
>>
>> Thanks, Roger, for review and feedback.
>>
>> Andra
>> ________________________________________
>> From: Roger Pau Monné <roger.pau@citrix.com>
>> Sent: Monday, June 18, 2018 2:43 PM
>> To: Paraschiv, Andra-Irina
>> Cc: xen-devel@lists.xenproject.org; sstabellini@kernel.org; jbeulich@
>> suse.com; andrew.cooper3@citrix.com; Woodhouse, David
>> Subject: Re: [PATCH qemu-xen-traditional] xen/pt: allow QEMU to
>> request MSI unmasking at bind time
>>
>> On Mon, Jun 18, 2018 at 09:35:20AM +0000, Andra Paraschiv wrote:
>> >
>> > When a MSI interrupt is bound to a guest using
> > xc_domain_update_msi_irq (XEN_DOMCTL_bind_pt_irq) the interrupt is
>> > left masked by default.
>> >
>> > This causes problems with guests that first configure interrupts
>> > and
>> > clean the per-entry MSIX table mask bit and afterwards enable MSIX
>> > globally. In such scenario the Xen internal msixtbl handlers would
>> > not
>> > detect the unmasking of MSIX entries because vectors are not yet
>> > registered since MSIX is not enabled, and vectors would be left
>> > masked.
>> >
>> > Introduce a new flag in the gflags field to signal Xen whether a
>> > MSI
>> > interrupt should be unmasked after being bound.
>> >
>> > This also requires to track the mask register for MSI interrupts,
>> > so
>> > QEMU can also notify to Xen whether the MSI interrupt should be
>> > bound
>> > masked or unmasked
>> >
>> > Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
>> > Reviewed-by: Jan Beulich <jbeulich@suse.com>
>> > Reported-by: Andreas Kinzler <hfp@posteo.de>
>> > Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
>> > Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
>> >
>> > [Backported from commit a8036336609d2e184fc3543a4c439c0ba7d7f3a2
>> >  https://git.qemu.org/?p=qemu.git;a=commit;h=a8036336609d2e184fc354
>> > 3a4c439c0ba7d7f3a2
>> >  https://xenbits.xen.org/gitweb/?p=qemu-xen.git;a=commit;h=a8036336
>> > 609d2e184fc3543a4c439c0ba7d7f3a2]
>> >
>> > Signed-off-by: Andra Paraschiv <andraprs@amazon.com>
>> Thanks for doing the backport, LGTM.
>>

Ian, can you please take a look on this patch that is considered for backporting from QEMU upstream repo to QEMU traditional?

Thanks.

>>
>>
>> Amazon Development Center (Romania) S.R.L. registered office: 27A Sf.
>> Lazar Street, UBC5, floor 2, Iasi, Iasi County, 700045, Romania.
>> Registered in Romania. Registration number J22/2621/2005.
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xenproject.org
>> https://lists.xenproject.org/mailman/listinfo/xen-devel



Amazon Development Center (Romania) S.R.L. registered office: 27A Sf. Lazar Street, UBC5, floor 2, Iasi, Iasi County, 700045, Romania. Registered in Romania. Registration number J22/2621/2005.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH qemu-xen-traditional] xen/pt: allow QEMU to request MSI unmasking at bind time

[Ian Jackson]

> >Ian, any objections?

Sorry for dropping this.  It's been a while!

> >> > When a MSI interrupt is bound to a guest using
> >> > xc_domain_update_msi_irq (XEN_DOMCTL_bind_pt_irq) the interrupt
> >> > is left masked by default.
> >> >
> >> > This causes problems with guests that first configure
> >> > interrupts and clean the per-entry MSIX table mask bit and
> >> > afterwards enable MSIX globally. In such scenario the Xen
> >> > internal msixtbl handlers would not detect the unmasking of
> >> > MSIX entries because vectors are not yet registered since MSIX
> >> > is not enabled, and vectors would be left masked.
> >> >
> >> > Introduce a new flag in the gflags field to signal Xen whether
> >> > a MSI interrupt should be unmasked after being bound.
> >> >
> >> > This also requires to track the mask register for MSI
> >> > interrupts, so QEMU can also notify to Xen whether the MSI
> >> > interrupt should be bound masked or unmasked

I searched my email archives but I haven't been able to find a copy of
the actual patch.  Was it ever sent to me ?

Also, qemu-trad is quite deeply frozen.  I'd like an explanation of
the practical impact of this bug, and the use cases where the fix is
needed, to justify the change.  Sorry to be awkward.

Regards,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH qemu-xen-traditional] xen/pt: allow QEMU to request MSI unmasking at bind time

[Paraschiv, Andra-Irina]

> > >Ian, any objections?
>
> Sorry for dropping this.  It's been a while!

No problem, Ian, we have this heads-up now.

>
> > >> > When a MSI interrupt is bound to a guest using
> > >> > xc_domain_update_msi_irq (XEN_DOMCTL_bind_pt_irq) the interrupt
> > >> > is left masked by default.
> > >> >
> > >> > This causes problems with guests that first configure
> > >> > interrupts and clean the per-entry MSIX table mask bit and
> > >> > afterwards enable MSIX globally. In such scenario the Xen
> > >> > internal msixtbl handlers would not detect the unmasking of
> > >> > MSIX entries because vectors are not yet registered since MSIX
> > >> > is not enabled, and vectors would be left masked.
> > >> >
> > >> > Introduce a new flag in the gflags field to signal Xen whether
> > >> > a MSI interrupt should be unmasked after being bound.
> > >> >
> > >> > This also requires to track the mask register for MSI
> > >> > interrupts, so QEMU can also notify to Xen whether the MSI
> > >> > interrupt should be bound masked or unmasked
>
> I searched my email archives but I haven't been able to find a copy of
> the actual patch.  Was it ever sent to me ?
> 
> Also, qemu-trad is quite deeply frozen.  I'd like an explanation of
> the practical impact of this bug, and the use cases where the fix is
> needed, to justify the change.  Sorry to be awkward.

That's the link to the patch for qemu-xen-traditional:
https://lists.xenproject.org/archives/html/xen-devel/2018-06/msg01248.html

(https://lists.xenproject.org/archives/html/xen-devel/2018-06/msg01373.html - added you in CC)

The issue was notified here - https://lists.xenproject.org/archives/html/xen-devel/2018-05/msg01238.html and fixes were added in xen and qemu. QEMU needs to interact with Xen to have guest interrupts masked/unmasked.

This patch is a backport from qemu.

One of the use cases where this fix is needed is: guest OS is Windows and the host has the latest stable version of xen and qemu-xen-traditional. Using this environment, setting up a PCI device (using MSI/MSI-X interrupts) will not successfully finish.

Thanks,
Andra

>
> Regards,
> Ian.



Amazon Development Center (Romania) S.R.L. registered office: 27A Sf. Lazar Street, UBC5, floor 2, Iasi, Iasi County, 700045, Romania. Registered in Romania. Registration number J22/2621/2005.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH qemu-xen-traditional] xen/pt: allow QEMU to request MSI unmasking at bind time

[Ian Jackson]

Paraschiv, Andra-Irina writes ("Re: [Xen-devel] [PATCH qemu-xen-traditional] xen/pt: allow QEMU to request MSI unmasking at bind time"):
> One of the use cases where this fix is needed is: guest OS is Windows and the host has the latest stable version of xen and qemu-xen-traditional. Using this environment, setting up a PCI device (using MSI/MSI-X interrupts) will not successfully finish.

OK, I'm sold on applying the patch to qemu-trad.  Great.

> That's the link to the patch for qemu-xen-traditional:
> https://lists.xenproject.org/archives/html/xen-devel/2018-06/msg01248.html

Right, thanks.

> (https://lists.xenproject.org/archives/html/xen-devel/2018-06/msg01373.html - added you in CC)

Unfortunately I don't want to fish the patch out of the mailing list
archives (because the conversion from email to html and back
etc. might mangle it) and the email with the CC to me didn't actually
have the patch in it.

So can you please resend the backported patch to me ?  Or point me at
a git tree that contains the backported patch ?

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH qemu-xen-traditional] xen/pt: allow QEMU to request MSI unmasking at bind time

[Paraschiv, Andra-Irina]

Ian Jackson writes ("Re: [Xen-devel] [PATCH qemu-xen-traditional] xen/pt: allow QEMU to request MSI unmasking at bind time"):
>
> Paraschiv, Andra-Irina writes ("Re: [Xen-devel] [PATCH qemu-xen-traditional] xen/pt: allow QEMU to request MSI unmasking at bind time"):
> > One of the use cases where this fix is needed is: guest OS is Windows and the host has the latest stable version of xen and qemu-xen-traditional. Using this environment, setting up a PCI device (using MSI/MSI-X interrupts) will not successfully finish.
>
> OK, I'm sold on applying the patch to qemu-trad.  Great.

Good :)  It's useful to have it applied.

>
> > That's the link to the patch for qemu-xen-traditional:
> > https://lists.xenproject.org/archives/html/xen-devel/2018-06/msg01248.html
> 
> Right, thanks.
> 
> > (https://lists.xenproject.org/archives/html/xen-devel/2018-06/msg01373.html - added you in CC)
> 
> Unfortunately I don't want to fish the patch out of the mailing list
> archives (because the conversion from email to html and back
> etc. might mangle it) and the email with the CC to me didn't actually
> have the patch in it.
> 
> So can you please resend the backported patch to me ?  Or point me at
> a git tree that contains the backported patch ?

Resent the patch, here it is on the list:
https://lists.xenproject.org/archives/html/xen-devel/2018-10/msg00937.html

Thanks for helping with this.

Andra

> 
>Thanks,
>Ian.



Amazon Development Center (Romania) S.R.L. registered office: 27A Sf. Lazar Street, UBC5, floor 2, Iasi, Iasi County, 700045, Romania. Registered in Romania. Registration number J22/2621/2005.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel