diff mbox series

[XTF,3/4] Enabled serial writing for hvm guests

Message ID 20200416094141.65120-4-wipawel@amazon.de (mailing list archive)
State Superseded
Headers show
Series Small fixes and improvements | expand

Commit Message

Wieczorkiewicz, Pawel April 16, 2020, 9:41 a.m. UTC
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(+)

Comments

Andrew Cooper April 16, 2020, 10:32 a.m. UTC | #1
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
Wieczorkiewicz, Pawel April 16, 2020, 11:44 a.m. UTC | #2
> 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
Andrew Cooper April 20, 2020, 7:54 p.m. UTC | #3
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
diff mbox series

Patch

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);