* [PATCH] VT-d: make remap_entry_to_msi_msg() return consistent message
@ 2012-10-02 14:55 Jan Beulich
2012-10-02 17:00 ` Keir Fraser
0 siblings, 1 reply; 4+ messages in thread
From: Jan Beulich @ 2012-10-02 14:55 UTC (permalink / raw)
To: xen-devel
[-- Attachment #1: Type: text/plain, Size: 968 bytes --]
During debugging of another problem I found that in x2APIC mode, the
destination field of the low address value wasn't passed back
correctly. While this is benign in most cases (as the value isn't being
used anywhere), it can be confusing (and misguiding) when printing the
value read or when comparing it to the one previously passed into the
inverse function.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
--- a/xen/drivers/passthrough/vtd/intremap.c
+++ b/xen/drivers/passthrough/vtd/intremap.c
@@ -504,7 +504,11 @@ static int remap_entry_to_msi_msg(
MSI_ADDR_REDIRECTION_CPU:
MSI_ADDR_REDIRECTION_LOWPRI);
if ( x2apic_enabled )
+ {
msg->dest32 = iremap_entry->lo.dst;
+ msg->address_lo |=
+ (iremap_entry->lo.dst & 0xff) << MSI_ADDR_DEST_ID_SHIFT;
+ }
else
msg->address_lo |=
((iremap_entry->lo.dst >> 8) & 0xff ) << MSI_ADDR_DEST_ID_SHIFT;
[-- Attachment #2: VT-d-read-MSI-full.patch --]
[-- Type: text/plain, Size: 1027 bytes --]
VT-d: make remap_entry_to_msi_msg() return consistent message
During debugging of another problem I found that in x2APIC mode, the
destination field of the low address value wasn't passed back
correctly. While this is benign in most cases (as the value isn't being
used anywhere), it can be confusing (and misguiding) when printing the
value read or when comparing it to the one previously passed into the
inverse function.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
--- a/xen/drivers/passthrough/vtd/intremap.c
+++ b/xen/drivers/passthrough/vtd/intremap.c
@@ -504,7 +504,11 @@ static int remap_entry_to_msi_msg(
MSI_ADDR_REDIRECTION_CPU:
MSI_ADDR_REDIRECTION_LOWPRI);
if ( x2apic_enabled )
+ {
msg->dest32 = iremap_entry->lo.dst;
+ msg->address_lo |=
+ (iremap_entry->lo.dst & 0xff) << MSI_ADDR_DEST_ID_SHIFT;
+ }
else
msg->address_lo |=
((iremap_entry->lo.dst >> 8) & 0xff ) << MSI_ADDR_DEST_ID_SHIFT;
[-- Attachment #3: 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] 4+ messages in thread* Re: [PATCH] VT-d: make remap_entry_to_msi_msg() return consistent message
2012-10-02 14:55 [PATCH] VT-d: make remap_entry_to_msi_msg() return consistent message Jan Beulich
@ 2012-10-02 17:00 ` Keir Fraser
2012-10-03 12:58 ` Jan Beulich
0 siblings, 1 reply; 4+ messages in thread
From: Keir Fraser @ 2012-10-02 17:00 UTC (permalink / raw)
To: Jan Beulich, xen-devel
On 02/10/2012 15:55, "Jan Beulich" <JBeulich@suse.com> wrote:
> During debugging of another problem I found that in x2APIC mode, the
> destination field of the low address value wasn't passed back
> correctly. While this is benign in most cases (as the value isn't being
> used anywhere), it can be confusing (and misguiding) when printing the
> value read or when comparing it to the one previously passed into the
> inverse function.
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
> --- a/xen/drivers/passthrough/vtd/intremap.c
> +++ b/xen/drivers/passthrough/vtd/intremap.c
> @@ -504,7 +504,11 @@ static int remap_entry_to_msi_msg(
> MSI_ADDR_REDIRECTION_CPU:
> MSI_ADDR_REDIRECTION_LOWPRI);
> if ( x2apic_enabled )
> + {
> msg->dest32 = iremap_entry->lo.dst;
> + msg->address_lo |=
> + (iremap_entry->lo.dst & 0xff) << MSI_ADDR_DEST_ID_SHIFT;
> + }
> else
> msg->address_lo |=
> ((iremap_entry->lo.dst >> 8) & 0xff ) << MSI_ADDR_DEST_ID_SHIFT;
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: [PATCH] VT-d: make remap_entry_to_msi_msg() return consistent message
2012-10-02 17:00 ` Keir Fraser
@ 2012-10-03 12:58 ` Jan Beulich
2012-10-03 14:33 ` Keir Fraser
0 siblings, 1 reply; 4+ messages in thread
From: Jan Beulich @ 2012-10-03 12:58 UTC (permalink / raw)
To: keir; +Cc: xen-devel
>>> Keir Fraser <keir@xen.org> 10/02/12 7:01 PM >>>
>On 02/10/2012 15:55, "Jan Beulich" <JBeulich@suse.com> wrote:
>
>> During debugging of another problem I found that in x2APIC mode, the
>> destination field of the low address value wasn't passed back
>> correctly. While this is benign in most cases (as the value isn't being
>> used anywhere), it can be confusing (and misguiding) when printing the
>> value read or when comparing it to the one previously passed into the
>> inverse function.
>>
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>
>Acked-by: Keir Fraser <keir@xen.org>
Actually on my way home yesterday I realized that this is not consistent, i.e.
fails to cover symmetrically the !x2apic case. Therefore, I'd like to adjust this
to pull out the msg->dest32 assignment from the conditional. Will that be okay
to commit without re-submission?
Jan
> --- a/xen/drivers/passthrough/vtd/intremap.c
> +++ b/xen/drivers/passthrough/vtd/intremap.c
> @@ -504,7 +504,11 @@ static int remap_entry_to_msi_msg(
> MSI_ADDR_REDIRECTION_CPU:
> MSI_ADDR_REDIRECTION_LOWPRI);
> if ( x2apic_enabled )
> + {
> msg->dest32 = iremap_entry->lo.dst;
> + msg->address_lo |=
> + (iremap_entry->lo.dst & 0xff) << MSI_ADDR_DEST_ID_SHIFT;
> + }
> else
> msg->address_lo |=
> ((iremap_entry->lo.dst >> 8) & 0xff ) << MSI_ADDR_DEST_ID_SHIFT;
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: [PATCH] VT-d: make remap_entry_to_msi_msg() return consistent message
2012-10-03 12:58 ` Jan Beulich
@ 2012-10-03 14:33 ` Keir Fraser
0 siblings, 0 replies; 4+ messages in thread
From: Keir Fraser @ 2012-10-03 14:33 UTC (permalink / raw)
To: Jan Beulich; +Cc: xen-devel
On 03/10/2012 13:58, "Jan Beulich" <jbeulich@suse.com> wrote:
>>>> Keir Fraser <keir@xen.org> 10/02/12 7:01 PM >>>
>> On 02/10/2012 15:55, "Jan Beulich" <JBeulich@suse.com> wrote:
>>
>>> During debugging of another problem I found that in x2APIC mode, the
>>> destination field of the low address value wasn't passed back
>>> correctly. While this is benign in most cases (as the value isn't being
>>> used anywhere), it can be confusing (and misguiding) when printing the
>>> value read or when comparing it to the one previously passed into the
>>> inverse function.
>>>
>>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>>
>> Acked-by: Keir Fraser <keir@xen.org>
>
> Actually on my way home yesterday I realized that this is not consistent, i.e.
> fails to cover symmetrically the !x2apic case. Therefore, I'd like to adjust
> this
> to pull out the msg->dest32 assignment from the conditional. Will that be okay
> to commit without re-submission?
Yes, that's fine by me.
-- Keir
> Jan
>
>> --- a/xen/drivers/passthrough/vtd/intremap.c
>> +++ b/xen/drivers/passthrough/vtd/intremap.c
>> @@ -504,7 +504,11 @@ static int remap_entry_to_msi_msg(
>> MSI_ADDR_REDIRECTION_CPU:
>> MSI_ADDR_REDIRECTION_LOWPRI);
>> if ( x2apic_enabled )
>> + {
>> msg->dest32 = iremap_entry->lo.dst;
>> + msg->address_lo |=
>> + (iremap_entry->lo.dst & 0xff) << MSI_ADDR_DEST_ID_SHIFT;
>> + }
>> else
>> msg->address_lo |=
>> ((iremap_entry->lo.dst >> 8) & 0xff ) << MSI_ADDR_DEST_ID_SHIFT;
>>
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
>
>
>
>
>
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2012-10-03 14:33 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-10-02 14:55 [PATCH] VT-d: make remap_entry_to_msi_msg() return consistent message Jan Beulich
2012-10-02 17:00 ` Keir Fraser
2012-10-03 12:58 ` Jan Beulich
2012-10-03 14:33 ` Keir Fraser
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).