On Wed, 23 Feb 2022 09:16:51 +
"Dr. David Alan Gilbert" wrote:
> * Igor Mammedov (imamm...@redhat.com) wrote:
> > On Tue, 22 Feb 2022 10:42:55 +0100
> > Gerd Hoffmann wrote:
> >
> > > Hi,
> > >
> > > > > And the upstream code is now pretty much identical except for the
> > > > >
* Igor Mammedov (imamm...@redhat.com) wrote:
> On Tue, 22 Feb 2022 10:42:55 +0100
> Gerd Hoffmann wrote:
>
> > Hi,
> >
> > > > And the upstream code is now pretty much identical except for the
> > > > default; note that for TCG you do need to keep to 40 I think.
> > >
> > > will TCG work
On Tue, 22 Feb 2022 10:42:55 +0100
Gerd Hoffmann wrote:
> Hi,
>
> > > And the upstream code is now pretty much identical except for the
> > > default; note that for TCG you do need to keep to 40 I think.
> >
> > will TCG work with 40bits on host that supports less than that?
>
> When I
On Tue, 22 Feb 2022 11:00:55 +
Joao Martins wrote:
> On 2/21/22 15:28, Joao Martins wrote:
> > On 2/21/22 06:58, Igor Mammedov wrote:
> >> On Fri, 18 Feb 2022 17:12:21 +
> >> Joao Martins wrote:
> >>
> >>> On 2/14/22 15:31, Igor Mammedov wrote:
> On Mon, 14 Feb 2022 15:05:00
On 2/21/22 15:28, Joao Martins wrote:
> On 2/21/22 06:58, Igor Mammedov wrote:
>> On Fri, 18 Feb 2022 17:12:21 +
>> Joao Martins wrote:
>>
>>> On 2/14/22 15:31, Igor Mammedov wrote:
On Mon, 14 Feb 2022 15:05:00 +
Joao Martins wrote:
> On 2/14/22 14:53, Igor Mammedov
Hi,
> > And the upstream code is now pretty much identical except for the
> > default; note that for TCG you do need to keep to 40 I think.
>
> will TCG work with 40bits on host that supports less than that?
When I understand things correctly the problem is that the phys-bits
limit applies
* Igor Mammedov (imamm...@redhat.com) wrote:
> On Mon, 21 Feb 2022 13:15:40 +
> "Dr. David Alan Gilbert" wrote:
>
> > * Daniel P. Berrangé (berra...@redhat.com) wrote:
> > > On Tue, Feb 15, 2022 at 10:53:58AM +0100, Gerd Hoffmann wrote:
> > > > Hi,
> > > >
> > > > > I don't know what
On Mon, 21 Feb 2022 13:15:40 +
"Dr. David Alan Gilbert" wrote:
> * Daniel P. Berrangé (berra...@redhat.com) wrote:
> > On Tue, Feb 15, 2022 at 10:53:58AM +0100, Gerd Hoffmann wrote:
> > > Hi,
> > >
> > > > I don't know what behavior should be if firmware tries to program
> > > > PCI64
On 2/21/22 06:58, Igor Mammedov wrote:
> On Fri, 18 Feb 2022 17:12:21 +
> Joao Martins wrote:
>
>> On 2/14/22 15:31, Igor Mammedov wrote:
>>> On Mon, 14 Feb 2022 15:05:00 +
>>> Joao Martins wrote:
On 2/14/22 14:53, Igor Mammedov wrote:
> On Mon, 7 Feb 2022 20:24:20
* Daniel P. Berrangé (berra...@redhat.com) wrote:
> On Tue, Feb 15, 2022 at 10:53:58AM +0100, Gerd Hoffmann wrote:
> > Hi,
> >
> > > I don't know what behavior should be if firmware tries to program
> > > PCI64 hole beyond supported phys-bits.
> >
> > Well, you are basically f*cked.
> >
> >
On Fri, 18 Feb 2022 17:12:21 +
Joao Martins wrote:
> On 2/14/22 15:31, Igor Mammedov wrote:
> > On Mon, 14 Feb 2022 15:05:00 +
> > Joao Martins wrote:
> >> On 2/14/22 14:53, Igor Mammedov wrote:
> >>> On Mon, 7 Feb 2022 20:24:20 +
> >>> Joao Martins wrote:
> +{
> +
On 2/14/22 15:31, Igor Mammedov wrote:
> On Mon, 14 Feb 2022 15:05:00 +
> Joao Martins wrote:
>> On 2/14/22 14:53, Igor Mammedov wrote:
>>> On Mon, 7 Feb 2022 20:24:20 +
>>> Joao Martins wrote:
+{
+PCMachineClass *pcmc = PC_MACHINE_GET_CLASS(pcms);
+
Hi,
> What I overlooked was the emphasis you had on desktops (qemu default bigger
> than
> host-advertised), where I am thinking mostly in servers.
Yep, on servers you have the reverse problem that phys-bits=40 might be
too small for very large guests.
> > To make things even worse: The
On 2/16/22 08:19, Gerd Hoffmann wrote:
> On Tue, Feb 15, 2022 at 07:37:40PM +, Joao Martins wrote:
>> On 2/15/22 09:53, Gerd Hoffmann wrote:
>>> What is missing:
>>>
>>> * Some way for the firmware to get a phys-bits value it can actually
>>>use. One possible way would be to have a
On Tue, Feb 15, 2022 at 10:53:58AM +0100, Gerd Hoffmann wrote:
> Hi,
>
> > I don't know what behavior should be if firmware tries to program
> > PCI64 hole beyond supported phys-bits.
>
> Well, you are basically f*cked.
>
> Unfortunately there is no reliable way to figure what phys-bits
On Tue, Feb 15, 2022 at 07:37:40PM +, Joao Martins wrote:
> On 2/15/22 09:53, Gerd Hoffmann wrote:
> > What is missing:
> >
> > * Some way for the firmware to get a phys-bits value it can actually
> >use. One possible way would be to have a paravirtual bit somewhere
> >telling
On 2/15/22 09:53, Gerd Hoffmann wrote:
> What is missing:
>
> * Some way for the firmware to get a phys-bits value it can actually
>use. One possible way would be to have a paravirtual bit somewhere
>telling whenever host-phys-bits is enabled or not.
>
If we are not talking about *very
Hi,
> I don't know what behavior should be if firmware tries to program
> PCI64 hole beyond supported phys-bits.
Well, you are basically f*cked.
Unfortunately there is no reliable way to figure what phys-bits actually
is. Because of that the firmware (both seabios and edk2) tries to place
On Mon, 14 Feb 2022 15:05:00 +
Joao Martins wrote:
> On 2/14/22 14:53, Igor Mammedov wrote:
> > On Mon, 7 Feb 2022 20:24:20 +
> > Joao Martins wrote:
> >
> >> It is assumed that the whole GPA space is available to be DMA
> >> addressable, within a given address space limit, expect
On 2/14/22 14:53, Igor Mammedov wrote:
> On Mon, 7 Feb 2022 20:24:20 +
> Joao Martins wrote:
>
>> It is assumed that the whole GPA space is available to be DMA
>> addressable, within a given address space limit, expect for a
>> tiny region before the 4G. Since Linux v5.4, VFIO validates
On Mon, 7 Feb 2022 20:24:20 +
Joao Martins wrote:
> It is assumed that the whole GPA space is available to be DMA
> addressable, within a given address space limit, expect for a
> tiny region before the 4G. Since Linux v5.4, VFIO validates
> whether the selected GPA is indeed valid i.e. not
It is assumed that the whole GPA space is available to be DMA
addressable, within a given address space limit, expect for a
tiny region before the 4G. Since Linux v5.4, VFIO validates
whether the selected GPA is indeed valid i.e. not reserved by
IOMMU on behalf of some specific devices or
22 matches
Mail list logo
