All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Beulich <jbeulich@suse.com>
To: Igor Druzhinin <igor.druzhinin@citrix.com>
Cc: andrew.cooper3@citrix.com, roger.pau@citrix.com, wl@xen.org,
	iwj@xenproject.org, anthony.perard@citrix.com,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH] hvmloader: pass PCI MMIO layout to OVMF as an info table
Date: Mon, 11 Jan 2021 10:27:29 +0100	[thread overview]
Message-ID: <b2ac8d2c-2c63-67e1-6b2b-14afefb2090a@suse.com> (raw)
In-Reply-To: <1610340812-24397-1-git-send-email-igor.druzhinin@citrix.com>

On 11.01.2021 05:53, Igor Druzhinin wrote:
> We faced a problem with passing through a PCI device with 64GB BAR to
> UEFI guest. The BAR is expectedly programmed into 64-bit PCI aperture at
> 64G address which pushes physical address space to 37 bits. OVMF uses
> address width early in PEI phase to make DXE identity pages covering
> the whole addressable space so it needs to know the last address it needs
> to cover but at the same time not overdo the mappings.
> 
> As there is seemingly no other way to pass or get this information in
> OVMF at this early phase (ACPI is not yet available, PCI is not yet enumerated,
> xenstore is not yet initialized) - extend the info structure with a new
> table. Since the structure was initially created to be extendable -
> the change is backward compatible.

How does UEFI handle the same situation on baremetal? I'd guess it is
in even more trouble there, as it couldn't even read addresses from
BARs, but would first need to assign them (or at least calculate
their intended positions).

> --- a/tools/firmware/hvmloader/ovmf.c
> +++ b/tools/firmware/hvmloader/ovmf.c
> @@ -61,6 +61,14 @@ struct ovmf_info {
>      uint32_t e820_nr;
>  } __attribute__ ((packed));
>  
> +#define OVMF_INFO_PCI_TABLE 0
> +struct ovmf_pci_info {
> +    uint64_t low_start;
> +    uint64_t low_end;
> +    uint64_t hi_start;
> +    uint64_t hi_end;
> +} __attribute__ ((packed));

Forming part of ABI, I believe this belongs in a public header,
which consumers could at least in principle use verbatim if
they wanted to.

> @@ -74,9 +82,21 @@ static void ovmf_setup_bios_info(void)
>  static void ovmf_finish_bios_info(void)
>  {
>      struct ovmf_info *info = (void *)OVMF_INFO_PHYSICAL_ADDRESS;
> +    struct ovmf_pci_info *pci_info;
> +    uint64_t *tables = scratch_alloc(sizeof(uint64_t)*OVMF_INFO_MAX_TABLES, 0);

I wasn't able to locate OVMF_INFO_MAX_TABLES in either
xen/include/public/ or tools/firmware/. Where does it get
defined?

Also (nit) missing blanks around * .

>      uint32_t i;
>      uint8_t checksum;
>  
> +    pci_info = scratch_alloc(sizeof(struct ovmf_pci_info), 0);

Is "scratch" correct here and above? I guess intended usage /
scope will want spelling out somewhere.

> +    pci_info->low_start = pci_mem_start;
> +    pci_info->low_end = pci_mem_end;
> +    pci_info->hi_start = pci_hi_mem_start;
> +    pci_info->hi_end = pci_hi_mem_end;
> +
> +    tables[OVMF_INFO_PCI_TABLE] = (uint32_t)pci_info;
> +    info->tables = (uint32_t)tables;
> +    info->tables_nr = 1;

In how far is this problem (and hence solution / workaround) OVMF
specific? IOW don't we need a more generic approach here?

Jan


  reply	other threads:[~2021-01-11  9:27 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-11  4:53 [PATCH] hvmloader: pass PCI MMIO layout to OVMF as an info table Igor Druzhinin
2021-01-11  9:27 ` Jan Beulich [this message]
2021-01-11 14:00   ` Igor Druzhinin
2021-01-11 14:14     ` Jan Beulich
2021-01-11 14:43       ` Igor Druzhinin
2021-01-11 14:49     ` Laszlo Ersek
2021-01-11 15:21       ` Jan Beulich
2021-01-11 15:26         ` Igor Druzhinin
2021-01-11 15:31           ` Jan Beulich
2021-01-11 15:35           ` Laszlo Ersek
2021-01-11 16:31             ` Igor Druzhinin
2021-01-11 16:35               ` Laszlo Ersek
2021-01-11 15:30         ` Laszlo Ersek

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=b2ac8d2c-2c63-67e1-6b2b-14afefb2090a@suse.com \
    --to=jbeulich@suse.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=anthony.perard@citrix.com \
    --cc=igor.druzhinin@citrix.com \
    --cc=iwj@xenproject.org \
    --cc=roger.pau@citrix.com \
    --cc=wl@xen.org \
    --cc=xen-devel@lists.xenproject.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.