* [XTF 1/4] lib: Add XEN_MAJOR() and XEN_MINOR() macros
2020-04-16 9:41 [XTF 0/4] Small fixes and improvements Pawel Wieczorkiewicz
@ 2020-04-16 9:41 ` Pawel Wieczorkiewicz
2020-04-16 9:41 ` [XTF 2/4] lib: always append CR after LF in vsnprintf() Pawel Wieczorkiewicz
` (2 subsequent siblings)
3 siblings, 0 replies; 16+ messages in thread
From: Pawel Wieczorkiewicz @ 2020-04-16 9:41 UTC (permalink / raw)
To: xen-devel
Cc: julien, paul, semelpaul, andrew.cooper3, Pawel Wieczorkiewicz, nmanthey
These are just a simple macros obtaining major, minor values as
returned by xen_version hypercall.
Signed-off-by: Pawel Wieczorkiewicz <wipawel@amazon.de>
---
include/xtf/lib.h | 3 +++
tests/xsa-213/main.c | 4 ++--
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/include/xtf/lib.h b/include/xtf/lib.h
index 3348464..40e5731 100644
--- a/include/xtf/lib.h
+++ b/include/xtf/lib.h
@@ -20,6 +20,9 @@
#define ACCESS_ONCE(x) (*(volatile typeof(x) *)&(x))
+#define XEN_MAJOR(v) (((v) >> 16) & 0xFFFF)
+#define XEN_MINOR(v) ((v) & 0xFFFF)
+
void __noreturn panic(const char *fmt, ...) __printf(1, 2);
#define ASSERT(cond) \
diff --git a/tests/xsa-213/main.c b/tests/xsa-213/main.c
index 64e7065..0353168 100644
--- a/tests/xsa-213/main.c
+++ b/tests/xsa-213/main.c
@@ -121,8 +121,8 @@ void test_main(void)
{
long rc, xen_version = hypercall_xen_version(XENVER_version, NULL);
- printk("Found Xen %ld.%ld\n",
- (xen_version >> 16) & 0xffff, xen_version & 0xffff);
+ printk("Found Xen %ld.%ld\n", XEN_MAJOR(xen_version),
+ XEN_MINOR(xen_version));
xtf_set_idte(X86_VEC_AVAIL, &idte);
--
2.16.6
Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879
^ permalink raw reply related [flat|nested] 16+ messages in thread* [XTF 2/4] lib: always append CR after LF in vsnprintf()
2020-04-16 9:41 [XTF 0/4] Small fixes and improvements Pawel Wieczorkiewicz
2020-04-16 9:41 ` [XTF 1/4] lib: Add XEN_MAJOR() and XEN_MINOR() macros Pawel Wieczorkiewicz
@ 2020-04-16 9:41 ` Pawel Wieczorkiewicz
2020-04-16 10:18 ` Andrew Cooper
2020-04-16 9:41 ` [XTF 3/4] Enabled serial writing for hvm guests Pawel Wieczorkiewicz
2020-04-16 9:41 ` [XTF 4/4] setup: Setup PV console for HVM guests on xen >4.2 Pawel Wieczorkiewicz
3 siblings, 1 reply; 16+ messages in thread
From: Pawel Wieczorkiewicz @ 2020-04-16 9:41 UTC (permalink / raw)
To: xen-devel
Cc: julien, paul, semelpaul, andrew.cooper3, Pawel Wieczorkiewicz, nmanthey
The explicit LFCR sequence guarantees proper line by line formatting
in the output.
The '\n' character alone on some terminals is not automatically
converted to LFCR.
Signed-off-by: Pawel Wieczorkiewicz <wipawel@amazon.de>
---
common/libc/vsnprintf.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/common/libc/vsnprintf.c b/common/libc/vsnprintf.c
index a49fd30..3202137 100644
--- a/common/libc/vsnprintf.c
+++ b/common/libc/vsnprintf.c
@@ -285,6 +285,16 @@ int vsnprintf(char *buf, size_t size, const char *fmt, va_list args)
if ( *fmt != '%' )
{
PUT(*fmt);
+
+ /*
+ * The '\n' character alone on some terminals is not automatically
+ * converted to LFCR.
+ * The explicit LFCR sequence guarantees proper line by line
+ * formatting in the output.
+ */
+ if ( *fmt == '\n' && str < end )
+ PUT('\r');
+
continue;
}
--
2.16.6
Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879
^ permalink raw reply related [flat|nested] 16+ messages in thread* Re: [XTF 2/4] lib: always append CR after LF in vsnprintf()
2020-04-16 9:41 ` [XTF 2/4] lib: always append CR after LF in vsnprintf() Pawel Wieczorkiewicz
@ 2020-04-16 10:18 ` Andrew Cooper
2020-04-16 11:36 ` Wieczorkiewicz, Pawel
0 siblings, 1 reply; 16+ messages in thread
From: Andrew Cooper @ 2020-04-16 10:18 UTC (permalink / raw)
To: Pawel Wieczorkiewicz, xen-devel; +Cc: semelpaul, julien, nmanthey, paul
On 16/04/2020 10:41, Pawel Wieczorkiewicz wrote:
> The explicit LFCR sequence guarantees proper line by line formatting
> in the output.
> The '\n' character alone on some terminals is not automatically
> converted to LFCR.
>
> Signed-off-by: Pawel Wieczorkiewicz <wipawel@amazon.de>
Up until now, all console destinations have expected POSIX text semantics.
I presume this is due to the COM1 use presented in the next patch?
Unfortunately, this comes with collateral damage.
# ./xtf-runner hvm64 example
Executing 'xl create -p tests/example/test-hvm64-example.cfg'
Executing 'xl console test-hvm64-example'
Executing 'xl unpause test-hvm64-example'
--- Xen Test Framework ---
Found Xen: 4.14
Environment: HVM 64bit (Long mode 4 levels)
Hello World
Test result: SUCCESS
Combined test results:
test-hvm64-example CRASH
which I believe is due to xenconsoled (or the intervening pty) also
expanding \n to \r\n (and "Test result:" no longer being on the final
line from xtf-runner's point of view). Xen also expands \n to \r\n for
the console, so ends up emitting \r\r\n.
Would it be better to have the com1 console handler do the expansion
locally, to avoid interfering with the semantics of every other
destination? That said...
> ---
> common/libc/vsnprintf.c | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/common/libc/vsnprintf.c b/common/libc/vsnprintf.c
> index a49fd30..3202137 100644
> --- a/common/libc/vsnprintf.c
> +++ b/common/libc/vsnprintf.c
> @@ -285,6 +285,16 @@ int vsnprintf(char *buf, size_t size, const char *fmt, va_list args)
> if ( *fmt != '%' )
> {
> PUT(*fmt);
> +
> + /*
> + * The '\n' character alone on some terminals is not automatically
> + * converted to LFCR.
> + * The explicit LFCR sequence guarantees proper line by line
> + * formatting in the output.
> + */
> + if ( *fmt == '\n' && str < end )
> + PUT('\r');
... doesn't this end up putting out \n\r ?
~Andrew
> +
> continue;
> }
>
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: [XTF 2/4] lib: always append CR after LF in vsnprintf()
2020-04-16 10:18 ` Andrew Cooper
@ 2020-04-16 11:36 ` Wieczorkiewicz, Pawel
2020-04-20 19:26 ` Andrew Cooper
0 siblings, 1 reply; 16+ messages in thread
From: Wieczorkiewicz, Pawel @ 2020-04-16 11:36 UTC (permalink / raw)
To: Andrew Cooper
Cc: Julien Grall, paul, semelpaul, xen-devel, Wieczorkiewicz, Pawel,
Manthey, Norbert
> On 16. Apr 2020, at 12:18, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
>
>
>
> On 16/04/2020 10:41, Pawel Wieczorkiewicz wrote:
>> The explicit LFCR sequence guarantees proper line by line formatting
>> in the output.
>> The '\n' character alone on some terminals is not automatically
>> converted to LFCR.
>>
>> Signed-off-by: Pawel Wieczorkiewicz <wipawel@amazon.de>
>
> Up until now, all console destinations have expected POSIX text semantics.
>
> I presume this is due to the COM1 use presented in the next patch?
>
No, this is not about that.
> Unfortunately, this comes with collateral damage.
>
> # ./xtf-runner hvm64 example
> Executing 'xl create -p tests/example/test-hvm64-example.cfg'
> Executing 'xl console test-hvm64-example'
> Executing 'xl unpause test-hvm64-example'
> --- Xen Test Framework ---
>
> Found Xen: 4.14
>
> Environment: HVM 64bit (Long mode 4 levels)
>
> Hello World
>
> Test result: SUCCESS
>
>
> Combined test results:
> test-hvm64-example CRASH
>
I never use xtf-runner script to execute tests. I do it the old fashion way:
# xl create -c test-hvm64-example.cfg
Parsing config from test-hvm64-example.cfg
Guest cpuid information
Native cpuid:
00000000:ffffffff -> 0000000d:756e6547:6c65746e:49656e69
00000001:ffffffff -> 000306e4:00400800:f7ba2203:1fcbfbff
00000002:ffffffff -> 76036301:00f0b2ff:00000000:00ca0000
00000003:ffffffff -> 00000000:00000000:00000000:00000000
00000004:00000000 -> 7c000121:01c0003f:0000003f:00000000
00000004:00000001 -> 7c000122:01c0003f:0000003f:00000000
00000004:00000002 -> 7c000143:01c0003f:000001ff:00000000
00000004:00000003 -> 7c000163:04c0003f:00004fff:00000006
00000004:00000004 -> 00000000:00000000:00000000:00000000
00000005:ffffffff -> 00000040:00000040:00000003:00001120
00000006:ffffffff -> 00000077:00000002:00000009:00000000
00000007:00000000 -> 00000000:00000281:00000000:9c000400
00000008:ffffffff -> 00000000:00000000:00000000:00000000
00000009:ffffffff -> 00000000:00000000:00000000:00000000
0000000a:ffffffff -> 07300403:00000000:00000000:00000603
0000000b:ffffffff -> 00000000:00000000:00000000:00000000
0000000c:ffffffff -> 00000000:00000000:00000000:00000000
0000000d:00000000 -> 00000007:00000240:00000340:00000000
0000000d:00000001 -> 00000001:00000000:00000000:00000000
0000000d:00000002 -> 00000100:00000240:00000000:00000000
40000000:ffffffff -> 40000005:566e6558:65584d4d:4d4d566e
40000001:ffffffff -> 0004000b:00000000:00000000:00000000
40000002:ffffffff -> 00000001:40000000:00000000:00000000
40000003:00000000 -> 00000006:00000000:002625a2:00000001
40000003:00000001 -> 57b3c4d2:00030755:ccccc210:ffffffff
40000003:00000002 -> 002625a2:00000000:00000000:00000000
40000004:00000000 -> 0000001c:00000000:00000ac9:00000000
40000005:ffffffff -> 00000000:00000000:00000000:00000000
40000100:ffffffff -> 00000000:00000000:00000000:00000000
80000000:ffffffff -> 80000008:00000000:00000000:00000000
80000001:ffffffff -> 00000000:00000000:00000001:2c100800
80000002:ffffffff -> 20202020:6e492020:286c6574:58202952
80000003:ffffffff -> 286e6f65:43202952:45205550:36322d35
80000004:ffffffff -> 76203037:20402032:30352e32:007a4847
80000005:ffffffff -> 00000000:00000000:00000000:00000000
80000006:ffffffff -> 00000000:00000000:01006040:00000000
80000007:ffffffff -> 00000000:00000000:00000000:00000000
80000008:ffffffff -> 0000302e:00001000:00000000:00000000
Test result: SUCCESS
There is no \r added to the console. I am not using serial console for this example.
Also, qemu seems to do the right thing and appends \r when it is not there.
> which I believe is due to xenconsoled (or the intervening pty) also
> expanding \n to \r\n (and "Test result:" no longer being on the final
> line from xtf-runner's point of view). Xen also expands \n to \r\n for
> the console, so ends up emitting \r\r\n.
>
> Would it be better to have the com1 console handler do the expansion
> locally, to avoid interfering with the semantics of every other
> destination? That said...
com1 handler works fine even without this patch
>
>> ---
>> common/libc/vsnprintf.c | 10 ++++++++++
>> 1 file changed, 10 insertions(+)
>>
>> diff --git a/common/libc/vsnprintf.c b/common/libc/vsnprintf.c
>> index a49fd30..3202137 100644
>> --- a/common/libc/vsnprintf.c
>> +++ b/common/libc/vsnprintf.c
>> @@ -285,6 +285,16 @@ int vsnprintf(char *buf, size_t size, const char *fmt, va_list args)
>> if ( *fmt != '%' )
>> {
>> PUT(*fmt);
>> +
>> + /*
>> + * The '\n' character alone on some terminals is not automatically
>> + * converted to LFCR.
>> + * The explicit LFCR sequence guarantees proper line by line
>> + * formatting in the output.
>> + */
>> + if ( *fmt == '\n' && str < end )
>> + PUT('\r');
>
> ... doesn't this end up putting out \n\r ?
yes, it does
>
> ~Andrew
>
>> +
>> continue;
>> }
>>
>
Best Regards,
Pawel Wieczorkiewicz
wipawel@amazon.com
Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: [XTF 2/4] lib: always append CR after LF in vsnprintf()
2020-04-16 11:36 ` Wieczorkiewicz, Pawel
@ 2020-04-20 19:26 ` Andrew Cooper
2020-04-20 19:42 ` Andrew Cooper
2020-04-21 6:29 ` Wieczorkiewicz, Pawel
0 siblings, 2 replies; 16+ messages in thread
From: Andrew Cooper @ 2020-04-20 19:26 UTC (permalink / raw)
To: Wieczorkiewicz, Pawel
Cc: semelpaul, paul, Julien Grall, Manthey, Norbert, xen-devel
On 16/04/2020 12:36, Wieczorkiewicz, Pawel wrote:
>> Unfortunately, this comes with collateral damage.
>>
>> # ./xtf-runner hvm64 example
>> Executing 'xl create -p tests/example/test-hvm64-example.cfg'
>> Executing 'xl console test-hvm64-example'
>> Executing 'xl unpause test-hvm64-example'
>> --- Xen Test Framework ---
>>
>> Found Xen: 4.14
>>
>> Environment: HVM 64bit (Long mode 4 levels)
>>
>> Hello World
>>
>> Test result: SUCCESS
>>
>>
>> Combined test results:
>> test-hvm64-example CRASH
>>
> I never use xtf-runner script to execute tests. I do it the old fashion way:
>
> # xl create -c test-hvm64-example.cfg
> Parsing config from test-hvm64-example.cfg
I presume you mean hvm64-cpuid here, but...
> Guest cpuid information
> Native cpuid:
> 00000000:ffffffff -> 0000000d:756e6547:6c65746e:49656e69
> 00000001:ffffffff -> 000306e4:00400800:f7ba2203:1fcbfbff
> 00000002:ffffffff -> 76036301:00f0b2ff:00000000:00ca0000
> 00000003:ffffffff -> 00000000:00000000:00000000:00000000
> 00000004:00000000 -> 7c000121:01c0003f:0000003f:00000000
> 00000004:00000001 -> 7c000122:01c0003f:0000003f:00000000
> 00000004:00000002 -> 7c000143:01c0003f:000001ff:00000000
> 00000004:00000003 -> 7c000163:04c0003f:00004fff:00000006
> 00000004:00000004 -> 00000000:00000000:00000000:00000000
> 00000005:ffffffff -> 00000040:00000040:00000003:00001120
> 00000006:ffffffff -> 00000077:00000002:00000009:00000000
> 00000007:00000000 -> 00000000:00000281:00000000:9c000400
> 00000008:ffffffff -> 00000000:00000000:00000000:00000000
> 00000009:ffffffff -> 00000000:00000000:00000000:00000000
> 0000000a:ffffffff -> 07300403:00000000:00000000:00000603
> 0000000b:ffffffff -> 00000000:00000000:00000000:00000000
> 0000000c:ffffffff -> 00000000:00000000:00000000:00000000
> 0000000d:00000000 -> 00000007:00000240:00000340:00000000
> 0000000d:00000001 -> 00000001:00000000:00000000:00000000
> 0000000d:00000002 -> 00000100:00000240:00000000:00000000
> 40000000:ffffffff -> 40000005:566e6558:65584d4d:4d4d566e
> 40000001:ffffffff -> 0004000b:00000000:00000000:00000000
> 40000002:ffffffff -> 00000001:40000000:00000000:00000000
> 40000003:00000000 -> 00000006:00000000:002625a2:00000001
> 40000003:00000001 -> 57b3c4d2:00030755:ccccc210:ffffffff
> 40000003:00000002 -> 002625a2:00000000:00000000:00000000
> 40000004:00000000 -> 0000001c:00000000:00000ac9:00000000
> 40000005:ffffffff -> 00000000:00000000:00000000:00000000
> 40000100:ffffffff -> 00000000:00000000:00000000:00000000
> 80000000:ffffffff -> 80000008:00000000:00000000:00000000
> 80000001:ffffffff -> 00000000:00000000:00000001:2c100800
> 80000002:ffffffff -> 20202020:6e492020:286c6574:58202952
> 80000003:ffffffff -> 286e6f65:43202952:45205550:36322d35
> 80000004:ffffffff -> 76203037:20402032:30352e32:007a4847
> 80000005:ffffffff -> 00000000:00000000:00000000:00000000
> 80000006:ffffffff -> 00000000:00000000:01006040:00000000
> 80000007:ffffffff -> 00000000:00000000:00000000:00000000
> 80000008:ffffffff -> 0000302e:00001000:00000000:00000000
> Test result: SUCCESS
... I have reproduced this locally.
However, I'd argue that this it is a bug in xenconsoled rather than
XTF. In particular, modifying XTF would result in xenconsoled writing
out the logfile with windows line endings, which surely isn't intended.
>>> ---
>>> common/libc/vsnprintf.c | 10 ++++++++++
>>> 1 file changed, 10 insertions(+)
>>>
>>> diff --git a/common/libc/vsnprintf.c b/common/libc/vsnprintf.c
>>> index a49fd30..3202137 100644
>>> --- a/common/libc/vsnprintf.c
>>> +++ b/common/libc/vsnprintf.c
>>> @@ -285,6 +285,16 @@ int vsnprintf(char *buf, size_t size, const char *fmt, va_list args)
>>> if ( *fmt != '%' )
>>> {
>>> PUT(*fmt);
>>> +
>>> + /*
>>> + * The '\n' character alone on some terminals is not automatically
>>> + * converted to LFCR.
>>> + * The explicit LFCR sequence guarantees proper line by line
>>> + * formatting in the output.
>>> + */
>>> + if ( *fmt == '\n' && str < end )
>>> + PUT('\r');
>> ... doesn't this end up putting out \n\r ?
> yes, it does
So the one type of line ending which isn't in common use?
~Andrew
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: [XTF 2/4] lib: always append CR after LF in vsnprintf()
2020-04-20 19:26 ` Andrew Cooper
@ 2020-04-20 19:42 ` Andrew Cooper
2020-04-21 6:29 ` Wieczorkiewicz, Pawel
1 sibling, 0 replies; 16+ messages in thread
From: Andrew Cooper @ 2020-04-20 19:42 UTC (permalink / raw)
To: Wieczorkiewicz, Pawel
Cc: semelpaul, xen-devel, Julien Grall, Manthey, Norbert, paul
On 20/04/2020 20:26, Andrew Cooper wrote:
>>>> ---
>>>> common/libc/vsnprintf.c | 10 ++++++++++
>>>> 1 file changed, 10 insertions(+)
>>>>
>>>> diff --git a/common/libc/vsnprintf.c b/common/libc/vsnprintf.c
>>>> index a49fd30..3202137 100644
>>>> --- a/common/libc/vsnprintf.c
>>>> +++ b/common/libc/vsnprintf.c
>>>> @@ -285,6 +285,16 @@ int vsnprintf(char *buf, size_t size, const char *fmt, va_list args)
>>>> if ( *fmt != '%' )
>>>> {
>>>> PUT(*fmt);
>>>> +
>>>> + /*
>>>> + * The '\n' character alone on some terminals is not automatically
>>>> + * converted to LFCR.
>>>> + * The explicit LFCR sequence guarantees proper line by line
>>>> + * formatting in the output.
>>>> + */
>>>> + if ( *fmt == '\n' && str < end )
>>>> + PUT('\r');
>>> ... doesn't this end up putting out \n\r ?
>> yes, it does
> So the one type of line ending which isn't in common use?
Switching this to do \r\n does seem to fix the raw `xl create` problem
you were seeing before, doesn't cause the double newlines as far as
`./xtf-runner` is concerned, and doesn't appear to cause xenconsoled to
write windows file endings.
I'm still a little hesitant to do this unilaterally. Do we know what
Linux usually emits via the console, because that will get us closer to
whatever people actually test.
~Andrew
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: [XTF 2/4] lib: always append CR after LF in vsnprintf()
2020-04-20 19:26 ` Andrew Cooper
2020-04-20 19:42 ` Andrew Cooper
@ 2020-04-21 6:29 ` Wieczorkiewicz, Pawel
1 sibling, 0 replies; 16+ messages in thread
From: Wieczorkiewicz, Pawel @ 2020-04-21 6:29 UTC (permalink / raw)
To: Andrew Cooper
Cc: Julien Grall, paul, semelpaul, xen-devel, Wieczorkiewicz, Pawel,
Manthey, Norbert
> On 20. Apr 2020, at 21:26, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
>
>
>
> On 16/04/2020 12:36, Wieczorkiewicz, Pawel wrote:
>>> Unfortunately, this comes with collateral damage.
>>>
>>> # ./xtf-runner hvm64 example
>>> Executing 'xl create -p tests/example/test-hvm64-example.cfg'
>>> Executing 'xl console test-hvm64-example'
>>> Executing 'xl unpause test-hvm64-example'
>>> --- Xen Test Framework ---
>>>
>>> Found Xen: 4.14
>>>
>>> Environment: HVM 64bit (Long mode 4 levels)
>>>
>>> Hello World
>>>
>>> Test result: SUCCESS
>>>
>>>
>>> Combined test results:
>>> test-hvm64-example CRASH
>>>
>> I never use xtf-runner script to execute tests. I do it the old fashion way:
>>
>> # xl create -c test-hvm64-example.cfg
>> Parsing config from test-hvm64-example.cfg
>
> I presume you mean hvm64-cpuid here, but...
>
>> Guest cpuid information
>> Native cpuid:
>> 00000000:ffffffff -> 0000000d:756e6547:6c65746e:49656e69
>> 00000001:ffffffff -> 000306e4:00400800:f7ba2203:1fcbfbff
>> 00000002:ffffffff -> 76036301:00f0b2ff:00000000:00ca0000
>> 00000003:ffffffff -> 00000000:00000000:00000000:00000000
>> 00000004:00000000 -> 7c000121:01c0003f:0000003f:00000000
>> 00000004:00000001 -> 7c000122:01c0003f:0000003f:00000000
>> 00000004:00000002 -> 7c000143:01c0003f:000001ff:00000000
>> 00000004:00000003 -> 7c000163:04c0003f:00004fff:00000006
>> 00000004:00000004 -> 00000000:00000000:00000000:00000000
>> 00000005:ffffffff -> 00000040:00000040:00000003:00001120
>> 00000006:ffffffff -> 00000077:00000002:00000009:00000000
>> 00000007:00000000 -> 00000000:00000281:00000000:9c000400
>> 00000008:ffffffff -> 00000000:00000000:00000000:00000000
>> 00000009:ffffffff -> 00000000:00000000:00000000:00000000
>> 0000000a:ffffffff -> 07300403:00000000:00000000:00000603
>> 0000000b:ffffffff -> 00000000:00000000:00000000:00000000
>> 0000000c:ffffffff -> 00000000:00000000:00000000:00000000
>> 0000000d:00000000 -> 00000007:00000240:00000340:00000000
>> 0000000d:00000001 -> 00000001:00000000:00000000:00000000
>> 0000000d:00000002 -> 00000100:00000240:00000000:00000000
>> 40000000:ffffffff -> 40000005:566e6558:65584d4d:4d4d566e
>> 40000001:ffffffff -> 0004000b:00000000:00000000:00000000
>> 40000002:ffffffff -> 00000001:40000000:00000000:00000000
>> 40000003:00000000 -> 00000006:00000000:002625a2:00000001
>> 40000003:00000001 -> 57b3c4d2:00030755:ccccc210:ffffffff
>> 40000003:00000002 -> 002625a2:00000000:00000000:00000000
>> 40000004:00000000 -> 0000001c:00000000:00000ac9:00000000
>> 40000005:ffffffff -> 00000000:00000000:00000000:00000000
>> 40000100:ffffffff -> 00000000:00000000:00000000:00000000
>> 80000000:ffffffff -> 80000008:00000000:00000000:00000000
>> 80000001:ffffffff -> 00000000:00000000:00000001:2c100800
>> 80000002:ffffffff -> 20202020:6e492020:286c6574:58202952
>> 80000003:ffffffff -> 286e6f65:43202952:45205550:36322d35
>> 80000004:ffffffff -> 76203037:20402032:30352e32:007a4847
>> 80000005:ffffffff -> 00000000:00000000:00000000:00000000
>> 80000006:ffffffff -> 00000000:00000000:01006040:00000000
>> 80000007:ffffffff -> 00000000:00000000:00000000:00000000
>> 80000008:ffffffff -> 0000302e:00001000:00000000:00000000
>> Test result: SUCCESS
>
> ... I have reproduced this locally.
>
Cool!
> However, I'd argue that this it is a bug in xenconsoled rather than
> XTF. In particular, modifying XTF would result in xenconsoled writing
> out the logfile with windows line endings, which surely isn't intended.
>
We can’t fix xenconsoled retrospectively, so I’d argue that we have to have
a workaround in XTF (or somewhere else, I do not care much where). I plan to
keep using XTF with various Xen versions.
>>>> ---
>>>> common/libc/vsnprintf.c | 10 ++++++++++
>>>> 1 file changed, 10 insertions(+)
>>>>
>>>> diff --git a/common/libc/vsnprintf.c b/common/libc/vsnprintf.c
>>>> index a49fd30..3202137 100644
>>>> --- a/common/libc/vsnprintf.c
>>>> +++ b/common/libc/vsnprintf.c
>>>> @@ -285,6 +285,16 @@ int vsnprintf(char *buf, size_t size, const char *fmt, va_list args)
>>>> if ( *fmt != '%' )
>>>> {
>>>> PUT(*fmt);
>>>> +
>>>> + /*
>>>> + * The '\n' character alone on some terminals is not automatically
>>>> + * converted to LFCR.
>>>> + * The explicit LFCR sequence guarantees proper line by line
>>>> + * formatting in the output.
>>>> + */
>>>> + if ( *fmt == '\n' && str < end )
>>>> + PUT('\r');
>>> ... doesn't this end up putting out \n\r ?
>> yes, it does
>
> So the one type of line ending which isn't in common use?
>
As long as it works… additional benefit is simplicity.
I did not want to mess with the stream and potentially cause more harm.
> ~Andrew
Best Regards,
Pawel Wieczorkiewicz
wipawel@amazon.com
Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879
^ permalink raw reply [flat|nested] 16+ messages in thread
* [XTF 3/4] Enabled serial writing for hvm guests
2020-04-16 9:41 [XTF 0/4] Small fixes and improvements Pawel Wieczorkiewicz
2020-04-16 9:41 ` [XTF 1/4] lib: Add XEN_MAJOR() and XEN_MINOR() macros Pawel Wieczorkiewicz
2020-04-16 9:41 ` [XTF 2/4] lib: always append CR after LF in vsnprintf() Pawel Wieczorkiewicz
@ 2020-04-16 9:41 ` Pawel Wieczorkiewicz
2020-04-16 10:32 ` Andrew Cooper
2020-04-16 9:41 ` [XTF 4/4] setup: Setup PV console for HVM guests on xen >4.2 Pawel Wieczorkiewicz
3 siblings, 1 reply; 16+ messages in thread
From: Pawel Wieczorkiewicz @ 2020-04-16 9:41 UTC (permalink / raw)
To: xen-devel
Cc: Paul Semel, julien, paul, semelpaul, andrew.cooper3,
Pawel Wieczorkiewicz, nmanthey
From: Paul Semel <phentex@amazon.de>
setup.c: PV console writing is not working in Xen 4.2 for hvm
guests, so we make xtf write to COM1 serial port to get its output
Signed-off-by: Paul Semel <phentex@amazon.de>
Signed-off-by: Pawel Wieczorkiewicz <wipawel@amazon.de>
---
arch/x86/setup.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/arch/x86/setup.c b/arch/x86/setup.c
index 3c84e96..f6fa4df 100644
--- a/arch/x86/setup.c
+++ b/arch/x86/setup.c
@@ -238,6 +238,13 @@ static void qemu_console_write(const char *buf, size_t len)
: "d" (0x12));
}
+static void com1_write(const char *buf, size_t len)
+{
+ asm volatile("rep; outsb"
+ : "+S" (buf), "+c" (len)
+ : "d" (0x3f8));
+}
+
static void xen_console_write(const char *buf, size_t len)
{
hypercall_console_write(buf, len);
@@ -246,7 +253,14 @@ static void xen_console_write(const char *buf, size_t len)
void arch_setup(void)
{
if ( IS_DEFINED(CONFIG_HVM) && !pvh_start_info )
+ {
register_console_callback(qemu_console_write);
+ }
+
+ if ( IS_DEFINED(CONFIG_HVM) )
+ {
+ register_console_callback(com1_write);
+ }
register_console_callback(xen_console_write);
--
2.16.6
Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879
^ permalink raw reply related [flat|nested] 16+ messages in thread* Re: [XTF 3/4] Enabled serial writing for hvm guests
2020-04-16 9:41 ` [XTF 3/4] Enabled serial writing for hvm guests Pawel Wieczorkiewicz
@ 2020-04-16 10:32 ` Andrew Cooper
2020-04-16 11:44 ` Wieczorkiewicz, Pawel
0 siblings, 1 reply; 16+ messages in thread
From: Andrew Cooper @ 2020-04-16 10:32 UTC (permalink / raw)
To: Pawel Wieczorkiewicz, xen-devel
Cc: semelpaul, Paul Semel, julien, nmanthey, paul
On 16/04/2020 10:41, Pawel Wieczorkiewicz wrote:
> From: Paul Semel <phentex@amazon.de>
>
> setup.c: PV console writing is not working in Xen 4.2 for hvm
> guests,
What is not working about it?
> so we make xtf write to COM1 serial port to get its output
>
> Signed-off-by: Paul Semel <phentex@amazon.de>
> Signed-off-by: Pawel Wieczorkiewicz <wipawel@amazon.de>
> ---
> arch/x86/setup.c | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
>
> diff --git a/arch/x86/setup.c b/arch/x86/setup.c
> index 3c84e96..f6fa4df 100644
> --- a/arch/x86/setup.c
> +++ b/arch/x86/setup.c
> @@ -238,6 +238,13 @@ static void qemu_console_write(const char *buf, size_t len)
> : "d" (0x12));
> }
>
> +static void com1_write(const char *buf, size_t len)
> +{
> + asm volatile("rep; outsb"
> + : "+S" (buf), "+c" (len)
> + : "d" (0x3f8));
Despite being 0x3f8, this really isn't uart-compatible COM1. I presume
it only works because Qemu doesn't have any real THR delays in its
emulation.
> +}
> +
> static void xen_console_write(const char *buf, size_t len)
> {
> hypercall_console_write(buf, len);
> @@ -246,7 +253,14 @@ static void xen_console_write(const char *buf, size_t len)
> void arch_setup(void)
> {
> if ( IS_DEFINED(CONFIG_HVM) && !pvh_start_info )
> + {
> register_console_callback(qemu_console_write);
> + }
> +
> + if ( IS_DEFINED(CONFIG_HVM) )
> + {
> + register_console_callback(com1_write);
This wires up 0x3f8 even for PVH guests, which I'm guessing isn't
intentional? This should be part of the previous if(), but does beg the
question what is wrong with the existing qemu console?
~Andrew
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: [XTF 3/4] Enabled serial writing for hvm guests
2020-04-16 10:32 ` Andrew Cooper
@ 2020-04-16 11:44 ` Wieczorkiewicz, Pawel
2020-04-20 19:54 ` Andrew Cooper
0 siblings, 1 reply; 16+ messages in thread
From: Wieczorkiewicz, Pawel @ 2020-04-16 11:44 UTC (permalink / raw)
To: Andrew Cooper
Cc: Paul Semel, Julien Grall, paul, semelpaul, xen-devel,
Wieczorkiewicz, Pawel, Manthey, Norbert
> On 16. Apr 2020, at 12:32, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
>
>
>
> On 16/04/2020 10:41, Pawel Wieczorkiewicz wrote:
>> From: Paul Semel <phentex@amazon.de>
>>
>> setup.c: PV console writing is not working in Xen 4.2 for hvm
>> guests,
>
> What is not working about it?
>
Honestly I am little short on details here, I would have to ask Paul or refresh my memory.
>> so we make xtf write to COM1 serial port to get its output
>>
>> Signed-off-by: Paul Semel <phentex@amazon.de>
>> Signed-off-by: Pawel Wieczorkiewicz <wipawel@amazon.de>
>> ---
>> arch/x86/setup.c | 14 ++++++++++++++
>> 1 file changed, 14 insertions(+)
>>
>> diff --git a/arch/x86/setup.c b/arch/x86/setup.c
>> index 3c84e96..f6fa4df 100644
>> --- a/arch/x86/setup.c
>> +++ b/arch/x86/setup.c
>> @@ -238,6 +238,13 @@ static void qemu_console_write(const char *buf, size_t len)
>> : "d" (0x12));
>> }
>>
>> +static void com1_write(const char *buf, size_t len)
>> +{
>> + asm volatile("rep; outsb"
>> + : "+S" (buf), "+c" (len)
>> + : "d" (0x3f8));
>
> Despite being 0x3f8, this really isn't uart-compatible COM1. I presume
> it only works because Qemu doesn't have any real THR delays in its
> emulation.
>
That can be. Nevertheless, it works for me[tm].
>> +}
>> +
>> static void xen_console_write(const char *buf, size_t len)
>> {
>> hypercall_console_write(buf, len);
>> @@ -246,7 +253,14 @@ static void xen_console_write(const char *buf, size_t len)
>> void arch_setup(void)
>> {
>> if ( IS_DEFINED(CONFIG_HVM) && !pvh_start_info )
>> + {
>> register_console_callback(qemu_console_write);
>> + }
>> +
>> + if ( IS_DEFINED(CONFIG_HVM) )
>> + {
>> + register_console_callback(com1_write);
>
> This wires up 0x3f8 even for PVH guests, which I'm guessing isn't
> intentional? This should be part of the previous if(), but does beg the
> question what is wrong with the existing qemu console?
>
It turns out that both PVH and HVM guests are PVH ABI compatible,
but PVH does not need qemu console. As per:
01e16ceb arch/x86/hvm/head.S (Andrew Cooper 2018-01-26 16:39:15 +0000 36) /* All HVM XTF guests are compatible with the PVH ABI. */
In order to get serial console via qemu working, I always register com1
handler for both HVM and PVH. Register qemu console only for HVM guests.
> ~Andrew
I use the com1 to make qemu write console output to a file via: serial=“file:/tmp/…”
Best Regards,
Pawel Wieczorkiewicz
wipawel@amazon.com
Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: [XTF 3/4] Enabled serial writing for hvm guests
2020-04-16 11:44 ` Wieczorkiewicz, Pawel
@ 2020-04-20 19:54 ` Andrew Cooper
0 siblings, 0 replies; 16+ messages in thread
From: Andrew Cooper @ 2020-04-20 19:54 UTC (permalink / raw)
To: Wieczorkiewicz, Pawel
Cc: semelpaul, paul, Julien Grall, Manthey, Norbert, xen-devel
On 16/04/2020 12:44, Wieczorkiewicz, Pawel wrote:
>>> +}
>>> +
>>> static void xen_console_write(const char *buf, size_t len)
>>> {
>>> hypercall_console_write(buf, len);
>>> @@ -246,7 +253,14 @@ static void xen_console_write(const char *buf, size_t len)
>>> void arch_setup(void)
>>> {
>>> if ( IS_DEFINED(CONFIG_HVM) && !pvh_start_info )
>>> + {
>>> register_console_callback(qemu_console_write);
>>> + }
>>> +
>>> + if ( IS_DEFINED(CONFIG_HVM) )
>>> + {
>>> + register_console_callback(com1_write);
>> This wires up 0x3f8 even for PVH guests, which I'm guessing isn't
>> intentional? This should be part of the previous if(), but does beg the
>> question what is wrong with the existing qemu console?
>>
> It turns out that both PVH and HVM guests are PVH ABI compatible,
Correct
> but PVH does not need qemu console.
Its not that. PVH guests are intended to run without qemu so there is
nothing listening on port 0x12.
> In order to get serial console via qemu working, I always register com1
> handler for both HVM and PVH. Register qemu console only for HVM guests.
> I use the com1 to make qemu write console output to a file via: serial=“file:/tmp/…”
Right, but this is a local configuration issue.
I'm happy to make console selection more flexible, but there is
absolutely no need to two separate IO ports throwing the same text
string at Qemu.
~Andrew
^ permalink raw reply [flat|nested] 16+ messages in thread
* [XTF 4/4] setup: Setup PV console for HVM guests on xen >4.2
2020-04-16 9:41 [XTF 0/4] Small fixes and improvements Pawel Wieczorkiewicz
` (2 preceding siblings ...)
2020-04-16 9:41 ` [XTF 3/4] Enabled serial writing for hvm guests Pawel Wieczorkiewicz
@ 2020-04-16 9:41 ` Pawel Wieczorkiewicz
2020-04-16 10:36 ` Andrew Cooper
3 siblings, 1 reply; 16+ messages in thread
From: Pawel Wieczorkiewicz @ 2020-04-16 9:41 UTC (permalink / raw)
To: xen-devel
Cc: Paul Semel, julien, paul, semelpaul, andrew.cooper3,
Pawel Wieczorkiewicz, nmanthey
From: Paul Semel <phentex@amazon.de>
Xen 4.2 requires a workaround that does not setup PV console
for HVM guests. However, newer Xen versions do not have that
limitation and should always have the PV console setup.
In arch_setup() detects Xen version by issuing xen_version hypercall
and optionally passes the version to main_xtf().
Signed-off-by: Paul Semel <phentex@amazon.de>
Signed-off-by: Pawel Wieczorkiewicz <wipawel@amazon.de>
---
arch/x86/setup.c | 20 ++++++++++++++++++--
common/setup.c | 6 +++++-
include/xtf/framework.h | 2 +-
3 files changed, 24 insertions(+), 4 deletions(-)
diff --git a/arch/x86/setup.c b/arch/x86/setup.c
index f6fa4df..e3f74e6 100644
--- a/arch/x86/setup.c
+++ b/arch/x86/setup.c
@@ -250,8 +250,10 @@ static void xen_console_write(const char *buf, size_t len)
hypercall_console_write(buf, len);
}
-void arch_setup(void)
+void arch_setup(int *version)
{
+ int xen_version;
+
if ( IS_DEFINED(CONFIG_HVM) && !pvh_start_info )
{
register_console_callback(qemu_console_write);
@@ -272,9 +274,23 @@ void arch_setup(void)
init_hypercalls();
- if ( !is_initdomain() )
+ xen_version = hypercall_xen_version(XENVER_version, NULL);
+ if ( version )
+ *version = xen_version;
+
+ /*
+ * The setup_pv_console function registers a writing function
+ * that makes hvm guests crash on Xen 4.2
+ */
+ if ( (!IS_DEFINED(CONFIG_HVM) ||
+ (XEN_MAJOR(xen_version) >= 4 && XEN_MINOR(xen_version) > 2)) &&
+ !is_initdomain() )
{
setup_pv_console();
+ }
+
+ if ( !is_initdomain() )
+ {
setup_xenbus();
}
diff --git a/common/setup.c b/common/setup.c
index 932fc09..1d3da15 100644
--- a/common/setup.c
+++ b/common/setup.c
@@ -19,9 +19,13 @@
*/
void __noreturn xtf_main(void)
{
- arch_setup();
+ int xen_version;
+
+ arch_setup(&xen_version);
printk("--- Xen Test Framework ---\n");
+ printk("Found Xen: %d.%d\n", XEN_MAJOR(xen_version),
+ XEN_MINOR(xen_version));
printk("Environment: %s\n", environment_description);
printk("%s\n", test_title);
diff --git a/include/xtf/framework.h b/include/xtf/framework.h
index a71bf39..6664733 100644
--- a/include/xtf/framework.h
+++ b/include/xtf/framework.h
@@ -2,7 +2,7 @@
#define XTF_FRAMEWORK_H
/* To be implemented by each arch */
-void arch_setup(void);
+void arch_setup(int *);
void test_setup(void);
/* Single line summary of execution environment. */
--
2.16.6
Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879
^ permalink raw reply related [flat|nested] 16+ messages in thread* Re: [XTF 4/4] setup: Setup PV console for HVM guests on xen >4.2
2020-04-16 9:41 ` [XTF 4/4] setup: Setup PV console for HVM guests on xen >4.2 Pawel Wieczorkiewicz
@ 2020-04-16 10:36 ` Andrew Cooper
2020-04-16 11:51 ` Wieczorkiewicz, Pawel
0 siblings, 1 reply; 16+ messages in thread
From: Andrew Cooper @ 2020-04-16 10:36 UTC (permalink / raw)
To: Pawel Wieczorkiewicz, xen-devel
Cc: semelpaul, Paul Semel, julien, nmanthey, paul
On 16/04/2020 10:41, Pawel Wieczorkiewicz wrote:
> @@ -272,9 +274,23 @@ void arch_setup(void)
>
> init_hypercalls();
>
> - if ( !is_initdomain() )
> + xen_version = hypercall_xen_version(XENVER_version, NULL);
> + if ( version )
> + *version = xen_version;
> +
> + /*
> + * The setup_pv_console function registers a writing function
> + * that makes hvm guests crash on Xen 4.2
This comment in particular is rather concerning. Even if there is a
configuration issue in 4.2 stopping the PV console from being wired up
properly, nothing involved in transmitting on the console should crash
the guest.
~Andrew
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [XTF 4/4] setup: Setup PV console for HVM guests on xen >4.2
2020-04-16 10:36 ` Andrew Cooper
@ 2020-04-16 11:51 ` Wieczorkiewicz, Pawel
2020-04-20 13:43 ` Andrew Cooper
0 siblings, 1 reply; 16+ messages in thread
From: Wieczorkiewicz, Pawel @ 2020-04-16 11:51 UTC (permalink / raw)
To: Andrew Cooper
Cc: Paul Semel, julien, paul, semelpaul, xen-devel, Wieczorkiewicz,
Pawel, Manthey, Norbert
> On 16. Apr 2020, at 12:36, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
>
>
>
> On 16/04/2020 10:41, Pawel Wieczorkiewicz wrote:
>> @@ -272,9 +274,23 @@ void arch_setup(void)
>>
>> init_hypercalls();
>>
>> - if ( !is_initdomain() )
>> + xen_version = hypercall_xen_version(XENVER_version, NULL);
>> + if ( version )
>> + *version = xen_version;
>> +
>> + /*
>> + * The setup_pv_console function registers a writing function
>> + * that makes hvm guests crash on Xen 4.2
>
> This comment in particular is rather concerning. Even if there is a
> configuration issue in 4.2 stopping the PV console from being wired up
> properly, nothing involved in transmitting on the console should crash
> the guest.
>
I am again a little short on details here. Maybe Paul could chime in.
But, I vagualy remember it was something about the init_pv_console()’s:
if ( port >= (sizeof(shared_info.evtchn_pending) * CHAR_BIT) )
panic("evtchn %u out of evtchn_pending[] range\n", port);
> ~Andrew
Best Regards,
Pawel Wieczorkiewicz
wipawel@amazon.com
Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: [XTF 4/4] setup: Setup PV console for HVM guests on xen >4.2
2020-04-16 11:51 ` Wieczorkiewicz, Pawel
@ 2020-04-20 13:43 ` Andrew Cooper
0 siblings, 0 replies; 16+ messages in thread
From: Andrew Cooper @ 2020-04-20 13:43 UTC (permalink / raw)
To: Wieczorkiewicz, Pawel
Cc: semelpaul, paul, julien, Manthey, Norbert, xen-devel
On 16/04/2020 12:51, Wieczorkiewicz, Pawel wrote:
>> On 16. Apr 2020, at 12:36, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>>
>> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
>>
>>
>>
>> On 16/04/2020 10:41, Pawel Wieczorkiewicz wrote:
>>> @@ -272,9 +274,23 @@ void arch_setup(void)
>>>
>>> init_hypercalls();
>>>
>>> - if ( !is_initdomain() )
>>> + xen_version = hypercall_xen_version(XENVER_version, NULL);
>>> + if ( version )
>>> + *version = xen_version;
>>> +
>>> + /*
>>> + * The setup_pv_console function registers a writing function
>>> + * that makes hvm guests crash on Xen 4.2
>> This comment in particular is rather concerning. Even if there is a
>> configuration issue in 4.2 stopping the PV console from being wired up
>> properly, nothing involved in transmitting on the console should crash
>> the guest.
>>
> I am again a little short on details here. Maybe Paul could chime in.
> But, I vagualy remember it was something about the init_pv_console()’s:
>
> if ( port >= (sizeof(shared_info.evtchn_pending) * CHAR_BIT) )
> panic("evtchn %u out of evtchn_pending[] range\n", port);
This is a sanity check about not overrunning the evtchn_pending array.
However, the check is still correct AFAICT.
port will either be 0 (if not configured by the toolstack), or strictly
less than 8 if configured properly.
What value are you seeing here?
~Andrew
^ permalink raw reply [flat|nested] 16+ messages in thread