I noticed that Mohammed Gamal just posted a series for better
KVM behaviour in cases where the guest size is smaller than the host:
https://lore.kernel.org/lkml/20200619153925.79106-1-mga...@redhat.com/
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
On 06/17/20 19:02, Eduardo Habkost wrote:
> On Wed, Jun 17, 2020 at 06:43:20PM +0200, Laszlo Ersek wrote:
>> On 06/17/20 18:14, Laszlo Ersek wrote:
>>> Consider assigning a single device with a 32G BAR -- right now that's
>>> supposed to work, without the X-PciMmio64Mb OVMF knob, on even the "most
On 06/17/20 18:33, 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 something like that?
>> OVMF could rely on that - if such property is available, we use it
On 06/17/20 18:01, Guilherme Piccoli wrote:
> 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
* Daniel P. Berrangé (berra...@redhat.com) wrote:
> On Wed, Jun 17, 2020 at 05:41:41PM +0100, Dr. David Alan Gilbert wrote:
> > * Eduardo Habkost (ehabk...@redhat.com) wrote:
> > > On Wed, Jun 17, 2020 at 05:17:17PM +0100, Daniel P. Berrang̮̩ wrote:
> > > > On Wed, Jun 17, 2020 at 05:04:12PM
On Wed, Jun 17, 2020 at 05:41:41PM +0100, Dr. David Alan Gilbert wrote:
> * Eduardo Habkost (ehabk...@redhat.com) wrote:
> > On Wed, Jun 17, 2020 at 05:17:17PM +0100, Daniel P. Berrangé wrote:
> > > On Wed, Jun 17, 2020 at 05:04:12PM +0100, Dr. David Alan Gilbert wrote:
> > > > * Eduardo Habkost
On Wed, Jun 17, 2020 at 06:43:20PM +0200, Laszlo Ersek wrote:
> On 06/17/20 18:14, Laszlo Ersek wrote:
> > On 06/17/20 15:46, 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 p
On 06/17/20 18:14, Laszlo Ersek wrote:
> On 06/17/20 15:46, 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 understand that when we use "-host-phys
* Eduardo Habkost (ehabk...@redhat.com) wrote:
> On Wed, Jun 17, 2020 at 05:17:17PM +0100, Daniel P. Berrangé wrote:
> > On Wed, Jun 17, 2020 at 05:04:12PM +0100, Dr. David Alan Gilbert wrote:
> > > * Eduardo Habkost (ehabk...@redhat.com) wrote:
> > > > On Wed, Jun 17, 2020 at 02:46:52PM +0100, Dr
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 something like that?
> > OVMF could rel
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 something like that?
> OVMF could rely on that - if such property is available, we use it to
> extend the PCI64 aperture.
Giving a exact
+libvir-list
On Wed, Jun 17, 2020 at 05:04:12PM +0100, Dr. David Alan Gilbert wrote:
> * Eduardo Habkost (ehabk...@redhat.com) wrote:
> > On Wed, 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 Pic
On Wed, Jun 17, 2020 at 10:17:55AM +0200, Christophe de Dinechin wrote:
>
>
> > Le 16 Jun 2020 à 19:10, Eduardo Habkost a écrit :
> >
> > On Tue, Jun 16, 2020 at 05:57:46PM +0100, Dr. David Alan Gilbert wrote:
> >> * Gerd Hoffmann (kra...@redhat.com) wrote:
> >>> Hi,
> >>>
> (a) We cou
On Wed, Jun 17, 2020 at 05:17:17PM +0100, Daniel P. Berrangé wrote:
> On Wed, Jun 17, 2020 at 05:04:12PM +0100, Dr. David Alan Gilbert wrote:
> > * Eduardo Habkost (ehabk...@redhat.com) wrote:
> > > On Wed, Jun 17, 2020 at 02:46:52PM +0100, Dr. David Alan Gilbert wrote:
> > > > * Laszlo Ersek (ler
On Wed, Jun 17, 2020 at 05:04:12PM +0100, Dr. David Alan Gilbert wrote:
> * Eduardo Habkost (ehabk...@redhat.com) wrote:
> > On Wed, 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:
>
On 06/17/20 15:46, 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 understand that when we use "-host-physical-bits", we are
>>> passing the *real* numb
* Eduardo Habkost (ehabk...@redhat.com) wrote:
> On Wed, 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!
> > > >
> > > > S
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.
>
>
On 06/17/20 15:43, Guilherme Piccoli wrote:
> So, the only problem with that refactor you're proposing is the
> retrocompatibility with qemu versions, as I can anticipate cases in
> which newer OVMF runs with older qemu, which does not provide such
> trustworth physbits info.
I don't necessarily
Can't qemu reads the host physical bits and pass that as fw_cfg as
"real_host_physbits" or something like that?
OVMF could rely on that - if such property is available, we use it to
extend the PCI64 aperture.
On Wed, Jun 17, 2020 at 12:50 PM Eduardo Habkost wrote:
>
> On Wed, Jun 17, 2020 at 02:4
On Wed, 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 understand that when we use "-host-physical-bits", we
On Wed, Jun 17, 2020 at 09:50:33AM +0100, Daniel P. Berrangé wrote:
> On Tue, Jun 16, 2020 at 01:10:21PM -0400, Eduardo Habkost wrote:
> > On Tue, Jun 16, 2020 at 05:57:46PM +0100, Dr. David Alan Gilbert wrote:
> > > * Gerd Hoffmann (kra...@redhat.com) wrote:
> > > > Hi,
> > > >
> > > > > (a) W
* 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 understand that when we use "-host-physical-bits", we are
> > passing the *real* number for the guest, correct? So, in this case we
> >
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.
On 06/17/20 08:40, Gerd Hoffmann wrote:
> Hi,
>
>> What if then we have OVMF relying in the physbits *iff*
>> "-host-phys-bits" is used
>
> How can the guest know?
Exactly!
> Adding "you can trust physbits" bits somewhere (as suggested by Eduardo)
> would work for sure, but would depend on a
On 06/17/20 08:40, Gerd Hoffmann wrote:
> Hi,
>
>> What if then we have OVMF relying in the physbits *iff*
>> "-host-phys-bits" is used
>
> How can the guest know?
Exactly!
> Adding "you can trust physbits" bits somewhere (as suggested by Eduardo)
> would work for sure, but would depend on a
On 06/16/20 19:14, Guilherme Piccoli wrote:
> 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 hos
* Daniel P. Berrangé (berra...@redhat.com) wrote:
> On Tue, Jun 16, 2020 at 01:10:21PM -0400, Eduardo Habkost wrote:
> > On Tue, Jun 16, 2020 at 05:57:46PM +0100, Dr. David Alan Gilbert wrote:
> > > * Gerd Hoffmann (kra...@redhat.com) wrote:
> > > > Hi,
> > > >
> > > > > (a) We could rely in th
On Wed, Jun 17, 2020 at 10:16:55AM +0200, Christophe de Dinechin wrote:
>
>
> > Le 16 Jun 2020 à 18:50, Gerd Hoffmann a écrit :
> >
> > Hi,
> >
> >> (a) We could rely in the guest physbits to calculate the PCI64 aperture.
> >
> > I'd love to do that. Move the 64-bit I/O window as high as
On Tue, Jun 16, 2020 at 01:10:21PM -0400, Eduardo Habkost wrote:
> On Tue, Jun 16, 2020 at 05:57:46PM +0100, Dr. David Alan Gilbert wrote:
> > * Gerd Hoffmann (kra...@redhat.com) wrote:
> > > Hi,
> > >
> > > > (a) We could rely in the guest physbits to calculate the PCI64 aperture.
> > >
> > >
> Le 16 Jun 2020 à 19:10, Eduardo Habkost a écrit :
>
> On Tue, Jun 16, 2020 at 05:57:46PM +0100, Dr. David Alan Gilbert wrote:
>> * Gerd Hoffmann (kra...@redhat.com) wrote:
>>> Hi,
>>>
(a) We could rely in the guest physbits to calculate the PCI64 aperture.
>>>
>>> I'd love to do that.
> Le 16 Jun 2020 à 18:50, Gerd Hoffmann a écrit :
>
> Hi,
>
>> (a) We could rely in the guest physbits to calculate the PCI64 aperture.
>
> I'd love to do that. Move the 64-bit I/O window as high as possible and
> use -- say -- 25% of the physical address space for it.
>
> Problem is we c
Hi,
> What if then we have OVMF relying in the physbits *iff*
> "-host-phys-bits" is used
How can the guest know?
Adding "you can trust physbits" bits somewhere (as suggested by Eduardo)
would work for sure, but would depend on a qemu update.
Maybe a "don't trust physbits in case it is 40" he
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
* Gerd Hoffmann (kra...@redhat.com) wrote:
> Hi,
>
> > > If we can somehow make a *trustable* physbits value available to the
> > > guest, then yes, we can go that route. But the guest physbits we have
> > > today unfortunately don't cut it.
> >
> > In downstream RH qemu, we run with host-phys
On Tue, Jun 16, 2020 at 05:57:46PM +0100, Dr. David Alan Gilbert wrote:
> * Gerd Hoffmann (kra...@redhat.com) wrote:
> > Hi,
> >
> > > (a) We could rely in the guest physbits to calculate the PCI64 aperture.
> >
> > I'd love to do that. Move the 64-bit I/O window as high as possible and
> > us
Hi,
> > If we can somehow make a *trustable* physbits value available to the
> > guest, then yes, we can go that route. But the guest physbits we have
> > today unfortunately don't cut it.
>
> In downstream RH qemu, we run with host-physbits as default; so it's
> reasonably
> trustworthy;
Ca
* Gerd Hoffmann (kra...@redhat.com) wrote:
> Hi,
>
> > (a) We could rely in the guest physbits to calculate the PCI64 aperture.
>
> I'd love to do that. Move the 64-bit I/O window as high as possible and
> use -- say -- 25% of the physical address space for it.
>
> Problem is we can't.
>
> >
Hi,
> (a) We could rely in the guest physbits to calculate the PCI64 aperture.
I'd love to do that. Move the 64-bit I/O window as high as possible and
use -- say -- 25% of the physical address space for it.
Problem is we can't.
> failure. Also, if the users are not setting the physbits in th
Hello folks, I'd like to start a discussion (or bump it, in case it was
already discussed) about an "issue", or better saying, a limitation
we've been observing (and receiving reports) on qemu/ovmf with regards
to the PCI passthrough of large BAR devices.
After OVMF commit 7e5b1b670c38 ("OvmfPkg:
40 matches
Mail list logo
