* [PATCH] xen vtd : set msi guest_masked 0 by default @ 2016-01-26 1:34 Jianzhong,Chang 2016-01-26 12:56 ` Jan Beulich 2018-05-21 11:46 ` David Woodhouse 0 siblings, 2 replies; 18+ messages in thread From: Jianzhong,Chang @ 2016-01-26 1:34 UTC (permalink / raw) To: keir, jbeulich, andrew.cooper3, xen-devel; +Cc: 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 ^ permalink raw reply related [flat|nested] 18+ messages in thread
* Re: [PATCH] xen vtd : set msi guest_masked 0 by default 2016-01-26 1:34 [PATCH] xen vtd : set msi guest_masked 0 by default Jianzhong,Chang @ 2016-01-26 12:56 ` Jan Beulich 2016-01-26 22:24 ` Tian, Kevin 2016-03-07 8:12 ` jzh Chang 2018-05-21 11:46 ` David Woodhouse 1 sibling, 2 replies; 18+ messages in thread From: Jan Beulich @ 2016-01-26 12:56 UTC (permalink / raw) To: Chang Jianzhong; +Cc: andrew.cooper3, keir, xen-devel >>> 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] xen vtd : set msi guest_masked 0 by default 2016-01-26 12:56 ` Jan Beulich @ 2016-01-26 22:24 ` Tian, Kevin 2016-03-07 8:12 ` jzh Chang 1 sibling, 0 replies; 18+ messages in thread From: Tian, Kevin @ 2016-01-26 22:24 UTC (permalink / raw) To: Jan Beulich, Chang Jianzhong; +Cc: andrew.cooper3, keir, xen-devel > 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] xen vtd : set msi guest_masked 0 by default 2016-01-26 12:56 ` Jan Beulich 2016-01-26 22:24 ` Tian, Kevin @ 2016-03-07 8:12 ` jzh Chang 2016-03-07 10:57 ` Jan Beulich 1 sibling, 1 reply; 18+ messages in thread From: jzh Chang @ 2016-03-07 8:12 UTC (permalink / raw) To: Jan Beulich; +Cc: andrew.cooper3, keir, xen-devel [-- 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] xen vtd : set msi guest_masked 0 by default 2016-03-07 8:12 ` jzh Chang @ 2016-03-07 10:57 ` Jan Beulich 0 siblings, 0 replies; 18+ messages in thread From: Jan Beulich @ 2016-03-07 10:57 UTC (permalink / raw) To: jzh Chang; +Cc: andrew.cooper3, keir, xen-devel >>> 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: xen vtd : set msi guest_masked 0 by default 2016-01-26 1:34 [PATCH] xen vtd : set msi guest_masked 0 by default Jianzhong,Chang 2016-01-26 12:56 ` Jan Beulich @ 2018-05-21 11:46 ` David Woodhouse 2018-05-21 12:10 ` Roger Pau Monné 1 sibling, 1 reply; 18+ messages in thread From: David Woodhouse @ 2018-05-21 11:46 UTC (permalink / raw) To: Jianzhong,Chang, keir, jbeulich, andrew.cooper3, xen-devel Cc: Andra-Irina Paraschiv [-- 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: xen vtd : set msi guest_masked 0 by default 2018-05-21 11:46 ` David Woodhouse @ 2018-05-21 12:10 ` Roger Pau Monné 2018-05-23 7:01 ` David Woodhouse 0 siblings, 1 reply; 18+ messages in thread From: Roger Pau Monné @ 2018-05-21 12:10 UTC (permalink / raw) To: David Woodhouse Cc: keir, Andra-Irina Paraschiv, andrew.cooper3, xen-devel, jbeulich, Jianzhong, Chang 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: xen vtd : set msi guest_masked 0 by default 2018-05-21 12:10 ` Roger Pau Monné @ 2018-05-23 7:01 ` David Woodhouse 2018-06-18 9:35 ` [PATCH qemu-xen-traditional] xen/pt: allow QEMU to request MSI unmasking at bind time Andra Paraschiv 2018-06-18 10:31 ` xen vtd : set msi guest_masked 0 by default Paraschiv, Andra-Irina 0 siblings, 2 replies; 18+ messages in thread From: David Woodhouse @ 2018-05-23 7:01 UTC (permalink / raw) To: Roger Pau Monné Cc: keir, Andra-Irina Paraschiv, andrew.cooper3, xen-devel, jbeulich, Jianzhong, Chang [-- 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* [PATCH qemu-xen-traditional] xen/pt: allow QEMU to request MSI unmasking at bind time 2018-05-23 7:01 ` David Woodhouse @ 2018-06-18 9:35 ` Andra Paraschiv 2018-06-18 11:43 ` Roger Pau Monné 2018-06-18 10:31 ` xen vtd : set msi guest_masked 0 by default Paraschiv, Andra-Irina 1 sibling, 1 reply; 18+ messages in thread From: Andra Paraschiv @ 2018-06-18 9:35 UTC (permalink / raw) To: xen-devel Cc: sstabellini, andraprs, andrew.cooper3, jbeulich, dwmw, roger.pau 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 ^ permalink raw reply related [flat|nested] 18+ messages in thread
* Re: [PATCH qemu-xen-traditional] xen/pt: allow QEMU to request MSI unmasking at bind time 2018-06-18 9:35 ` [PATCH qemu-xen-traditional] xen/pt: allow QEMU to request MSI unmasking at bind time Andra Paraschiv @ 2018-06-18 11:43 ` Roger Pau Monné 2018-06-21 8:37 ` Paraschiv, Andra-Irina 0 siblings, 1 reply; 18+ messages in thread From: Roger Pau Monné @ 2018-06-18 11:43 UTC (permalink / raw) To: Andra Paraschiv; +Cc: xen-devel, sstabellini, dwmw, jbeulich, andrew.cooper3 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH qemu-xen-traditional] xen/pt: allow QEMU to request MSI unmasking at bind time 2018-06-18 11:43 ` Roger Pau Monné @ 2018-06-21 8:37 ` Paraschiv, Andra-Irina 2018-07-31 10:22 ` Woodhouse, David 0 siblings, 1 reply; 18+ messages in thread From: Paraschiv, Andra-Irina @ 2018-06-21 8:37 UTC (permalink / raw) To: Roger Pau Monné Cc: sstabellini, andrew.cooper3, ian.jackson, jbeulich, xen-devel, Woodhouse, David + 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH qemu-xen-traditional] xen/pt: allow QEMU to request MSI unmasking at bind time 2018-06-21 8:37 ` Paraschiv, Andra-Irina @ 2018-07-31 10:22 ` Woodhouse, David 2018-09-17 8:40 ` Paraschiv, Andra-Irina 0 siblings, 1 reply; 18+ messages in thread From: Woodhouse, David @ 2018-07-31 10:22 UTC (permalink / raw) To: roger.pau, Paraschiv, Andra-Irina Cc: andrew.cooper3, sstabellini, ian.jackson, jbeulich, xen-devel [-- 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH qemu-xen-traditional] xen/pt: allow QEMU to request MSI unmasking at bind time 2018-07-31 10:22 ` Woodhouse, David @ 2018-09-17 8:40 ` Paraschiv, Andra-Irina 2018-10-09 13:55 ` Ian Jackson 0 siblings, 1 reply; 18+ messages in thread From: Paraschiv, Andra-Irina @ 2018-09-17 8:40 UTC (permalink / raw) To: ian.jackson, ian.jackson Cc: sstabellini, andrew.cooper3, jbeulich, xen-devel, Woodhouse, David, roger.pau >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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH qemu-xen-traditional] xen/pt: allow QEMU to request MSI unmasking at bind time 2018-09-17 8:40 ` Paraschiv, Andra-Irina @ 2018-10-09 13:55 ` Ian Jackson 2018-10-09 15:23 ` Paraschiv, Andra-Irina 0 siblings, 1 reply; 18+ messages in thread From: Ian Jackson @ 2018-10-09 13:55 UTC (permalink / raw) To: Paraschiv, Andra-Irina Cc: sstabellini, andrew.cooper3, jbeulich, xen-devel, Woodhouse, David, roger.pau > >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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH qemu-xen-traditional] xen/pt: allow QEMU to request MSI unmasking at bind time 2018-10-09 13:55 ` Ian Jackson @ 2018-10-09 15:23 ` Paraschiv, Andra-Irina 2018-10-10 14:56 ` Ian Jackson 0 siblings, 1 reply; 18+ messages in thread From: Paraschiv, Andra-Irina @ 2018-10-09 15:23 UTC (permalink / raw) To: Ian Jackson Cc: sstabellini, Paraschiv, Andra-Irina, andrew.cooper3, jbeulich, xen-devel, Woodhouse, David, roger.pau > > >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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH qemu-xen-traditional] xen/pt: allow QEMU to request MSI unmasking at bind time 2018-10-09 15:23 ` Paraschiv, Andra-Irina @ 2018-10-10 14:56 ` Ian Jackson 2018-10-10 19:06 ` Paraschiv, Andra-Irina 0 siblings, 1 reply; 18+ messages in thread From: Ian Jackson @ 2018-10-10 14:56 UTC (permalink / raw) To: Paraschiv, Andra-Irina Cc: sstabellini, andrew.cooper3, jbeulich, xen-devel, Woodhouse, David, roger.pau 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH qemu-xen-traditional] xen/pt: allow QEMU to request MSI unmasking at bind time 2018-10-10 14:56 ` Ian Jackson @ 2018-10-10 19:06 ` Paraschiv, Andra-Irina 0 siblings, 0 replies; 18+ messages in thread From: Paraschiv, Andra-Irina @ 2018-10-10 19:06 UTC (permalink / raw) To: Ian Jackson Cc: sstabellini, andrew.cooper3, jbeulich, xen-devel, Woodhouse, David, roger.pau 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: xen vtd : set msi guest_masked 0 by default 2018-05-23 7:01 ` David Woodhouse 2018-06-18 9:35 ` [PATCH qemu-xen-traditional] xen/pt: allow QEMU to request MSI unmasking at bind time Andra Paraschiv @ 2018-06-18 10:31 ` Paraschiv, Andra-Irina 1 sibling, 0 replies; 18+ messages in thread From: Paraschiv, Andra-Irina @ 2018-06-18 10:31 UTC (permalink / raw) To: David Woodhouse, Roger Pau Monné Cc: keir, xen-devel, Jianzhong, Chang, jbeulich, andrew.cooper3 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2018-10-10 19:06 UTC | newest] Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-01-26 1:34 [PATCH] xen vtd : set msi guest_masked 0 by default Jianzhong,Chang 2016-01-26 12:56 ` Jan Beulich 2016-01-26 22:24 ` Tian, Kevin 2016-03-07 8:12 ` jzh Chang 2016-03-07 10:57 ` Jan Beulich 2018-05-21 11:46 ` David Woodhouse 2018-05-21 12:10 ` Roger Pau Monné 2018-05-23 7:01 ` David Woodhouse 2018-06-18 9:35 ` [PATCH qemu-xen-traditional] xen/pt: allow QEMU to request MSI unmasking at bind time Andra Paraschiv 2018-06-18 11:43 ` Roger Pau Monné 2018-06-21 8:37 ` Paraschiv, Andra-Irina 2018-07-31 10:22 ` Woodhouse, David 2018-09-17 8:40 ` Paraschiv, Andra-Irina 2018-10-09 13:55 ` Ian Jackson 2018-10-09 15:23 ` Paraschiv, Andra-Irina 2018-10-10 14:56 ` Ian Jackson 2018-10-10 19:06 ` Paraschiv, Andra-Irina 2018-06-18 10:31 ` xen vtd : set msi guest_masked 0 by default Paraschiv, Andra-Irina
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.