>>> On 01.04.16 at 11:21, wrote:
>> Beyond that I guess I could use some help in at least diagnosing the issue,
>> e.g.
>> by logging the actions done by Xen, so we can understand why
>> guest_mask_msi_irq() doesn't get called to unmask the MSI-X vector(s). I've
>> found the reason why this isn't
> >>> On 01.04.16 at 09:40, wrote:
> > A couple of weeks ago, Jianzhong reported an issue, the SRIOV NICs
> > (Intel 82599, 82571 ) can't work correctly in Windows guest.
> > By debugging, we found your this patch, the commit ID
> > ad28e42bd1d28d746988ed71654e8aa670629753, caused the regression.
>>> On 01.04.16 at 09:40, wrote:
> A couple of weeks ago, Jianzhong reported an issue, the SRIOV NICs (Intel
> 82599, 82571 ) can't work correctly in Windows guest.
> By debugging, we found your this patch, the commit ID
> ad28e42bd1d28d746988ed71654e8aa670629753, caused the regression.
That w
n-devel
> Cc: Andrew Cooper; Keir Fraser
> Subject: [Xen-devel] [PATCH v3 05/10] x86/MSI: track host and guest
> masking separately
>
> In particular we want to avoid losing track of our own intention to have an
> entry masked. Physical unmasking now happens only when both host and
&g
On 05/06/15 12:22, Jan Beulich wrote:
> In particular we want to avoid losing track of our own intention to
> have an entry masked. Physical unmasking now happens only when both
> host and guest requested so.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
I really need to dust off my
In particular we want to avoid losing track of our own intention to
have an entry masked. Physical unmasking now happens only when both
host and guest requested so.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/hpet.c
+++ b/xen/arch/x86/hpet.c
@@ -241,7 +241,7 @@ static void hpet_msi_unmask(stru
