kvm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Zixuan Wang <zxwang42@gmail.com>
To: Andrew Jones <drjones@redhat.com>
Cc: kvm@vger.kernel.org, Paolo Bonzini <pbonzini@redhat.com>,
	Marc Orr <marcorr@google.com>,
	"Hyunwook (Wooky) Baek" <baekhw@google.com>,
	Tom Roeder <tmroeder@google.com>,
	erdemaktas@google.com, rientjes@google.com, seanjc@google.com,
	brijesh.singh@amd.com, Thomas.Lendacky@amd.com,
	varad.gautam@suse.com, jroedel@suse.de, bp@suse.de
Subject: Re: [kvm-unit-tests PATCH v2 08/17] x86 UEFI: Set up RSDP after UEFI boot up
Date: Mon, 4 Oct 2021 14:58:29 -0700	[thread overview]
Message-ID: <CAEDJ5ZRy8ywXjujoMVHem8igBq-2s0HzN2Gt6f76cLbZzCkr9g@mail.gmail.com> (raw)
In-Reply-To: <20211004132102.lfsyabk2daeiejkx@gator>

On Mon, Oct 4, 2021 at 6:23 AM Andrew Jones <drjones@redhat.com> wrote:
>
> On Fri, Aug 27, 2021 at 03:12:13AM +0000, Zixuan Wang wrote:
> > Root system description pointer (RSDP) is a data structure used in the
> > ACPI programming interface. In BIOS, RSDP is located within a
> > predefined memory area, so a program can scan the memory area and find
> > RSDP. But in UEFI, RSDP may not appear in that memory area, instead, a
> > program should find it in the EFI system table.
> >
> > +typedef union {
> > +     struct {
> > +             efi_guid_t guid;
> > +             void *table;
> > +     };
> > +     efi_config_table_32_t mixed_mode;
>
> Can't we drop all the mixed_mode stuff? Or do we really want to support
> 32-bit UEFI kvm-unit-tests?

We are currently not considering the 32-bit UEFI support. I will drop
the mixed_mode code in the next version.

> > +void setup_efi_rsdp(struct rsdp_descriptor *rsdp) {
> > +     efi_rsdp = rsdp;
> > +}
>
> { on its own line please

Got it! I will fix it in the next version.

> > +
> > +static struct rsdp_descriptor *get_rsdp(void) {
> > +     if (efi_rsdp == NULL) {
> > +             printf("Can't find RSDP from UEFI, maybe setup_efi_rsdp() was not called\n");
> > +     }
> > +     return efi_rsdp;
> > +}
> > +#else
> > +static struct rsdp_descriptor *get_rsdp(void) {
> > +    struct rsdp_descriptor *rsdp;
> > +    unsigned long addr;
> > +    for(addr = 0xf0000; addr < 0x100000; addr += 16) {
> > +     rsdp = (void*)addr;
> > +     if (rsdp->signature == RSDP_SIGNATURE_8BYTE)
> > +          break;
> > +    }
>
> When moving code please take the opportunity to clean up its style.

Got it! I will fix this in the next version.

> > +#ifdef TARGET_EFI
> > +void setup_efi_rsdp(struct rsdp_descriptor *rsdp);
> > +#endif /* TARGET_EFI */
>
> Unnecessary ifdef.

I previously thought it's safer to use ifdef here, as the function is
only defined in the UEFI kvm-unit-tests.

I will drop it in the next version. Dropping it does not affect the
compilation of Multiboot kvm-unit-tests.

> > @@ -255,6 +267,7 @@ void setup_efi(efi_bootinfo_t *efi_bootinfo)
> >       enable_x2apic();
> >       smp_init();
> >       phys_alloc_init(efi_bootinfo->free_mem_start, efi_bootinfo->free_mem_size);
> > +     setup_efi_rsdp(efi_bootinfo->rsdp);
>
> What memory region is this table in? We should make sure it's reserved or
> copy the table out to somewhere that is reserved.

I will double-check it in the next version. I will add a comment to
this line if it's already in reserved memory. Otherwise, I will copy
it to a reserved location.

> >  }
> >
> >  #endif /* TARGET_EFI */
> > --
> > 2.33.0.259.gc128427fd7-goog
> >
>
> I'd much prefer we avoid too much of this split setup where we have a bit
> of setup in a common efi lib and then an x86 specific part that populates
> an x86 specific info structure before exiting boot services and then more
> x86 specific setup that uses that later...
>
> Can't we do almost everything in lib/efi.c and only call out once into an
> arch_efi_setup function after exiting boot services?
>
> Thanks,
> drew
>

Indeed, I will refactor this part in the next version. I will move the
arch-neutral functions to lib/efi.c and pass an EFI system info data
structure to the arch-specific function for additional setup.

Best regards,
Zixuan

  reply	other threads:[~2021-10-04 21:59 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-27  3:12 [kvm-unit-tests PATCH v2 00/17] x86_64 UEFI and AMD SEV/SEV-ES support Zixuan Wang
2021-08-27  3:12 ` [kvm-unit-tests PATCH v2 01/17] x86 UEFI: Copy code from Linux Zixuan Wang
2021-09-20 14:33   ` Paolo Bonzini
2021-09-21  3:58     ` Zixuan Wang
2021-09-21  6:37       ` Varad Gautam
2021-09-21 16:33   ` Andrew Jones
2021-09-22 20:10     ` Zixuan Wang
2021-08-27  3:12 ` [kvm-unit-tests PATCH v2 02/17] x86 UEFI: Implement UEFI function calls Zixuan Wang
2021-09-21 16:43   ` Andrew Jones
2021-09-22 20:17     ` Zixuan Wang
2021-08-27  3:12 ` [kvm-unit-tests PATCH v2 03/17] x86 UEFI: Copy code from GNU-EFI Zixuan Wang
2021-10-04 12:44   ` Andrew Jones
2021-10-04 22:09     ` Zixuan Wang
2021-10-05  5:58       ` Andrew Jones
2021-08-27  3:12 ` [kvm-unit-tests PATCH v2 04/17] x86 UEFI: Boot from UEFI Zixuan Wang
2021-10-04 12:55   ` Andrew Jones
2021-10-04 21:30     ` Zixuan Wang
2021-08-27  3:12 ` [kvm-unit-tests PATCH v2 05/17] x86 UEFI: Load IDT after UEFI boot up Zixuan Wang
2021-08-27  3:12 ` [kvm-unit-tests PATCH v2 06/17] x86 UEFI: Load GDT and TSS " Zixuan Wang
2021-09-20 15:40   ` Paolo Bonzini
2021-09-21  4:15     ` Zixuan Wang
2021-08-27  3:12 ` [kvm-unit-tests PATCH v2 07/17] x86 UEFI: Set up memory allocator Zixuan Wang
2021-10-04 13:06   ` Andrew Jones
2021-10-04 21:43     ` Zixuan Wang
2021-10-05  6:05       ` Andrew Jones
2021-08-27  3:12 ` [kvm-unit-tests PATCH v2 08/17] x86 UEFI: Set up RSDP after UEFI boot up Zixuan Wang
2021-10-04 13:21   ` Andrew Jones
2021-10-04 21:58     ` Zixuan Wang [this message]
2021-08-27  3:12 ` [kvm-unit-tests PATCH v2 09/17] x86 UEFI: Set up page tables Zixuan Wang
2021-09-20 15:43   ` Paolo Bonzini
2021-09-21  4:31     ` Zixuan Wang
2021-08-27  3:12 ` [kvm-unit-tests PATCH v2 10/17] x86 UEFI: Convert x86 test cases to PIC Zixuan Wang
2021-08-27  3:12 ` [kvm-unit-tests PATCH v2 11/17] x86 AMD SEV: Initial support Zixuan Wang
2021-08-27 14:51   ` Tom Lendacky
2021-08-31 19:36     ` Zixuan Wang
2021-08-27  3:12 ` [kvm-unit-tests PATCH v2 12/17] x86 AMD SEV: Page table with c-bit Zixuan Wang
2021-08-27  3:12 ` [kvm-unit-tests PATCH v2 13/17] x86 AMD SEV-ES: Check SEV-ES status Zixuan Wang
2021-08-27 14:55   ` Tom Lendacky
2021-08-31 19:38     ` Zixuan Wang
2021-08-27  3:12 ` [kvm-unit-tests PATCH v2 14/17] x86 AMD SEV-ES: Load GDT with UEFI segments Zixuan Wang
2021-09-20 16:00   ` Paolo Bonzini
2021-09-21  4:41     ` Zixuan Wang
2021-08-27  3:12 ` [kvm-unit-tests PATCH v2 15/17] x86 AMD SEV-ES: Copy UEFI #VC IDT entry Zixuan Wang
2021-08-27  3:12 ` [kvm-unit-tests PATCH v2 16/17] x86 AMD SEV-ES: Set up GHCB page Zixuan Wang
2021-08-27  3:12 ` [kvm-unit-tests PATCH v2 17/17] x86 AMD SEV-ES: Add test cases Zixuan Wang
2021-10-04 13:27 ` [kvm-unit-tests PATCH v2 00/17] x86_64 UEFI and AMD SEV/SEV-ES support Andrew Jones
2021-10-04 20:54   ` Zixuan Wang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAEDJ5ZRy8ywXjujoMVHem8igBq-2s0HzN2Gt6f76cLbZzCkr9g@mail.gmail.com \
    --to=zxwang42@gmail.com \
    --cc=Thomas.Lendacky@amd.com \
    --cc=baekhw@google.com \
    --cc=bp@suse.de \
    --cc=brijesh.singh@amd.com \
    --cc=drjones@redhat.com \
    --cc=erdemaktas@google.com \
    --cc=jroedel@suse.de \
    --cc=kvm@vger.kernel.org \
    --cc=marcorr@google.com \
    --cc=pbonzini@redhat.com \
    --cc=rientjes@google.com \
    --cc=seanjc@google.com \
    --cc=tmroeder@google.com \
    --cc=varad.gautam@suse.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).