Awesome, thanks a bunch Eduardo!
On Wed, Jun 17, 2020 at 1:33 PM Eduardo Habkost wrote:
>
> On Wed, Jun 17, 2020 at 12:57:52PM -0300, Guilherme Piccoli wrote:
> > Can't qemu reads the host physical bits and pass that as fw_cfg as
> > "real_host_physbits" or so
On Wed, Jun 17, 2020 at 12:57 PM Laszlo Ersek wrote:
> [...]
> I don't necessarily see compat issues -- large-BAR PCI device assignment
> might simply stop working under those circumstances, because you could
> no longer use X-PciMmio64Mb, and the new way wouldn't be supported by
> (old) QEMU.
>
>
d, Jun 17, 2020 at 02:46:52PM +0100, Dr. David Alan Gilbert wrote:
> > * Laszlo Ersek (ler...@redhat.com) wrote:
> > > On 06/16/20 19:14, Guilherme Piccoli wrote:
> > > > Thanks Gerd, Dave and Eduardo for the prompt responses!
> > > >
> > > > So, I u
Thanks a lot for all the responses here! Very constructive discussion =)
Comments inline!
On Wed, Jun 17, 2020 at 10:22 AM Laszlo Ersek wrote:
> [...]
> If QEMU can provide a *reliable* GPA width, in some info channel (CPUID
> or even fw_cfg), then the above calculation could be reversed in OVMF.
Thanks Gerd, Dave and Eduardo for the prompt responses!
So, I understand that when we use "-host-physical-bits", we are
passing the *real* number for the guest, correct? So, in this case we
can trust that the guest physbits matches the true host physbits.
What if then we have OVMF relying in the
