EFI shell with microvm

EFI shell with microvm

[Boeuf, Sebastien]

Hi Gerd,

I was looking at a way to add support for EFI shell interaction with Cloud Hypervisor when
I realized you added the support for microvm with commit 55f47d22998.
I have been able to hack OvmfPkgX64 similarly to get it to work, but here are two follow up
questions:

1. Is it possible to support it as well from OvmfPkgX64 without breaking the current support
for QEMU?

2. I can see the shell but I can't interact with it, do you have a similar behavior with microvm
or is it because I'm missing the interrupt support?

Thanks,
Sebastien
---------------------------------------------------------------------
Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: "Les Montalets"- 2, rue de Paris, 
92196 Meudon Cedex, France
Registration Number:  302 456 199 R.C.S. NANTERRE
Capital: 4,572,000 Euros

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

Re: EFI shell with microvm

[Gerd Hoffmann]

On Thu, Jan 06, 2022 at 11:25:37AM +0000, Boeuf, Sebastien wrote:
> Hi Gerd,
> 
> I was looking at a way to add support for EFI shell interaction with Cloud Hypervisor when
> I realized you added the support for microvm with commit 55f47d22998.
> I have been able to hack OvmfPkgX64 similarly to get it to work, but here are two follow up
> questions:

How do you want interact?  Serial console?  That should work just fine
with OvmfPkgX64.

qemu-system-x86_64 -nographic -bios Build/OvmfX64/DEBUG_GCC5/FV/OVMF.fd -net none

Possibly you have to add the cloud hypervisor pci id somewhere so isa
lpc and serial line driver are initialized properly.  SioBusDxe looks
like a hot candidate.

microvm has no lpc bridge, so I had to do it in a different way ...

> 2. I can see the shell but I can't interact with it, do you have a similar behavior with microvm
> or is it because I'm missing the interrupt support?

Works fine for me.

qemu-system-x86_64 -nographic -machine microvm,rtc=on -bios Build/MicrovmX64/DEBUG_GCC5/FV/MICROVM.fd

HTH,
  Gerd

Re: EFI shell with microvm

[Boeuf, Sebastien]

On Thu, 2022-01-06 at 13:44 +0100, kraxel@redhat.com wrote:
> On Thu, Jan 06, 2022 at 11:25:37AM +0000, Boeuf, Sebastien wrote:
> > Hi Gerd,
> > 
> > I was looking at a way to add support for EFI shell interaction
> > with Cloud Hypervisor when
> > I realized you added the support for microvm with commit
> > 55f47d22998.
> > I have been able to hack OvmfPkgX64 similarly to get it to work,
> > but here are two follow up
> > questions:
> 
> How do you want interact?  Serial console?  That should work just
> fine
> with OvmfPkgX64.

Yes I'd like to use the serial console (available on PIO 0x3f8) to
interact with the EFI shell.

> 
> qemu-system-x86_64 -nographic -bios
> Build/OvmfX64/DEBUG_GCC5/FV/OVMF.fd -net none
> 
> Possibly you have to add the cloud hypervisor pci id somewhere so isa
> lpc and serial line driver are initialized properly.  SioBusDxe looks
> like a hot candidate.
> 
> microvm has no lpc bridge, so I had to do it in a different way ...

Cloud Hypervisor doesn't emulate any LPC bridge or ISA bus.

> 
> > 2. I can see the shell but I can't interact with it, do you have a
> > similar behavior with microvm
> > or is it because I'm missing the interrupt support?
> 
> Works fine for me.
> 
> qemu-system-x86_64 -nographic -machine microvm,rtc=on -bios
> Build/MicrovmX64/DEBUG_GCC5/FV/MICROVM.fd

Thanks for the confirmation, something might be wrong with the
interrupt used for my serial device.
Cloud Hypervisor only has an IOAPIC, it doesn't rely on any PIC, which
is why I'm not sure what might be missing to get the EFI shell to
receive the interrupts.

> 
> HTH,
>   Gerd
> 

---------------------------------------------------------------------
Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: "Les Montalets"- 2, rue de Paris, 
92196 Meudon Cedex, France
Registration Number:  302 456 199 R.C.S. NANTERRE
Capital: 4,572,000 Euros

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

Re: EFI shell with microvm

[Gerd Hoffmann]

  Hi,

> > microvm has no lpc bridge, so I had to do it in a different way ...
> 
> Cloud Hypervisor doesn't emulate any LPC bridge or ISA bus.

Ok, doing it microvm-style makes sense then.

> > Works fine for me.
> > 
> > qemu-system-x86_64 -nographic -machine microvm,rtc=on -bios
> > Build/MicrovmX64/DEBUG_GCC5/FV/MICROVM.fd
> 
> Thanks for the confirmation, something might be wrong with the
> interrupt used for my serial device.

tianocore doesn't use interrupts (other than timer).

> Cloud Hypervisor only has an IOAPIC, it doesn't rely on any PIC, which
> is why I'm not sure what might be missing to get the EFI shell to
> receive the interrupts.

PIC is optional for microvm too, and everything works fine for me with
"-machine microvm,rtc=on,pic=off,pit=off"

take care,
  Gerd

Re: EFI shell with microvm

[Boeuf, Sebastien]

On Fri, 2022-01-07 at 13:07 +0100, kraxel@redhat.com wrote:
>   Hi,
> 
> > > microvm has no lpc bridge, so I had to do it in a different way
> > > ...
> > 
> > Cloud Hypervisor doesn't emulate any LPC bridge or ISA bus.
> 
> Ok, doing it microvm-style makes sense then.

Ok thanks for the confirmation. Hopefully it won't conflict with what
QEMU uses/needs.

> 
> > > Works fine for me.
> > > 
> > > qemu-system-x86_64 -nographic -machine microvm,rtc=on -bios
> > > Build/MicrovmX64/DEBUG_GCC5/FV/MICROVM.fd
> > 
> > Thanks for the confirmation, something might be wrong with the
> > interrupt used for my serial device.
> 
> tianocore doesn't use interrupts (other than timer).

Yes I realized that by diving into the code. I can see microvm using
the Xen timer while OvmfPkgX64 uses 8254 PIT.

> 
> > Cloud Hypervisor only has an IOAPIC, it doesn't rely on any PIC,
> > which
> > is why I'm not sure what might be missing to get the EFI shell to
> > receive the interrupts.
> 
> PIC is optional for microvm too, and everything works fine for me
> with
> "-machine microvm,rtc=on,pic=off,pit=off"

Yes that's interesting and after some investigations I think the
problem is that I don't get TerminalConInTimerHandler handler to be
triggered. I can see the handler is correctly registered but for some
reasons, it's never used. I'm wondering if that might be an issue
related to a lack of timer support. Especially I see the UEFI service
SetTimer() is being used for the polling mechanism, so I wonder what is
the backend for it.

> 
> take care,
>   Gerd
> 

---------------------------------------------------------------------
Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: "Les Montalets"- 2, rue de Paris, 
92196 Meudon Cedex, France
Registration Number:  302 456 199 R.C.S. NANTERRE
Capital: 4,572,000 Euros

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

Re: EFI shell with microvm

[Gerd Hoffmann]

  Hi,

> > tianocore doesn't use interrupts (other than timer).
> 
> Yes I realized that by diving into the code. I can see microvm using
> the Xen timer while OvmfPkgX64 uses 8254 PIT.

Min, what happened to the patch series changing that?

(the plan is to always use the lapci except when compiling with csm
 enabled because pit/pic support is needed for backward compatibility
 reasons then).

take care,
  Gerd

Re: EFI shell with microvm

[Boeuf, Sebastien]

I finally got it to work by using the XenTimerDxe. The reason why it
works is because the UEFI service SetTimer() needs one Timer
Architectural Protocol to be installed. In case of standard QEMU, the
8254 PIT is the one registering the service, while for microvm the Xen
timer does the job.

It's interesting to notice that XenTimerDxe is not specific to Xen as
it simply relies on the local APIC timer that generates an interrupt on
IRQ0, which is eventually the local APIC vector 32.

So now I'm wondering how I'm gonna make OvmfPkgX64 work for both QEMU
and Cloud Hypervisor since only one Timer Architectural Protocol can be
registered.

Do you think it would be acceptable to move OvmfPkgX64 to XenTimerDxe
instead of 8254 legacy PIT?

Thanks,
Sebastien

On Fri, 2022-01-07 at 14:06 +0100, Sebastien Boeuf wrote:
> On Fri, 2022-01-07 at 13:07 +0100, kraxel@redhat.com wrote:
> >   Hi,
> > 
> > > > microvm has no lpc bridge, so I had to do it in a different way
> > > > ...
> > > 
> > > Cloud Hypervisor doesn't emulate any LPC bridge or ISA bus.
> > 
> > Ok, doing it microvm-style makes sense then.
> 
> Ok thanks for the confirmation. Hopefully it won't conflict with what
> QEMU uses/needs.
> 
> > 
> > > > Works fine for me.
> > > > 
> > > > qemu-system-x86_64 -nographic -machine microvm,rtc=on -bios
> > > > Build/MicrovmX64/DEBUG_GCC5/FV/MICROVM.fd
> > > 
> > > Thanks for the confirmation, something might be wrong with the
> > > interrupt used for my serial device.
> > 
> > tianocore doesn't use interrupts (other than timer).
> 
> Yes I realized that by diving into the code. I can see microvm using
> the Xen timer while OvmfPkgX64 uses 8254 PIT.
> 
> > 
> > > Cloud Hypervisor only has an IOAPIC, it doesn't rely on any PIC,
> > > which
> > > is why I'm not sure what might be missing to get the EFI shell to
> > > receive the interrupts.
> > 
> > PIC is optional for microvm too, and everything works fine for me
> > with
> > "-machine microvm,rtc=on,pic=off,pit=off"
> 
> Yes that's interesting and after some investigations I think the
> problem is that I don't get TerminalConInTimerHandler handler to be
> triggered. I can see the handler is correctly registered but for some
> reasons, it's never used. I'm wondering if that might be an issue
> related to a lack of timer support. Especially I see the UEFI service
> SetTimer() is being used for the polling mechanism, so I wonder what
> is
> the backend for it.
> 
> > 
> > take care,
> >   Gerd
> > 
> 

---------------------------------------------------------------------
Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: "Les Montalets"- 2, rue de Paris, 
92196 Meudon Cedex, France
Registration Number:  302 456 199 R.C.S. NANTERRE
Capital: 4,572,000 Euros

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

Re: EFI shell with microvm

[Min Xu]

On January 7, 2022 9:37 PM, Gerd Hoffmann wrote:
> 
> > > tianocore doesn't use interrupts (other than timer).
> >
> > Yes I realized that by diving into the code. I can see microvm using
> > the Xen timer while OvmfPkgX64 uses 8254 PIT.
> 
> Min, what happened to the patch series changing that?
Hi Gerd, What do you mean "the patch series"? Is this one? https://edk2.groups.io/g/devel/message/83488
It is still in review and hasn't been merged.
> 
> (the plan is to always use the lapci except when compiling with csm  enabled
> because pit/pic support is needed for backward compatibility  reasons then).
Yes, we use CSM_ENABLE to switch the lapic timer or 8254 timer in build time.
This is the v3 which has been reviewed. https://github.com/tianocore/edk2/pull/2167
> 
Thanks
Min

Re: EFI shell with microvm

[Boeuf, Sebastien]

On Mon, 2022-01-10 at 00:16 +0000, Xu, Min M wrote:
> On January 7, 2022 9:37 PM, Gerd Hoffmann wrote:
> > 
> > > > tianocore doesn't use interrupts (other than timer).
> > > 
> > > Yes I realized that by diving into the code. I can see microvm
> > > using
> > > the Xen timer while OvmfPkgX64 uses 8254 PIT.
> > 
> > Min, what happened to the patch series changing that?
> Hi Gerd, What do you mean "the patch series"? Is this one?  
> https://edk2.groups.io/g/devel/message/83488
> It is still in review and hasn't been merged.
> > 
> > (the plan is to always use the lapci except when compiling with
> > csm  enabled
> > because pit/pic support is needed for backward compatibility 
> > reasons then).
> Yes, we use CSM_ENABLE to switch the lapic timer or 8254 timer in
> build time.
> This is the v3 which has been reviewed.  
> https://github.com/tianocore/edk2/pull/2167

Oh I see, that's great actually because as I mentioned earlier this is
not Xen specific, therefore I really think the renaming you're doing is
important.

> > 
> Thanks
> Min

---------------------------------------------------------------------
Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: "Les Montalets"- 2, rue de Paris, 
92196 Meudon Cedex, France
Registration Number:  302 456 199 R.C.S. NANTERRE
Capital: 4,572,000 Euros

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.