2 CPU Conformance Issue in KVM/x86

2 CPU Conformance Issue in KVM/x86

[Nadav Amit]

I got two conformance issues in x86/KVM. For the first one I have no
solution. For the latter, my solution is not “great”. Ideas and feedback
would be appreciated.

The first problem is caused by the deprecating of FPU CS/DS in new Intel
CPUs. Assume the VM executes a floating point instruction in real mode (when
CS != 0), and later KVM exits to userspace, causing XSAVE/XRSTOR to save and
restore the FPU state. At this point FPU CS/DS in new CPUs are zero. If the
VM then executes FSAVE in real-mode the save FPU IP would be wrong, since it
is actually calculated by the CPU as [FPU CS] * 4 + [FPU IP].

The second problem occurs when the maximum physical address width that KVM
reports to the VM is different than the real one. Assume the real one is
greater than the reported one (which in KVM is not greater than 40). In this
case, the VM might expect exceptions when PTE bits which are higher than the
maximum (reported) address width are set, and it would not get such
exceptions. This problem can easily be experienced by small change to the
existing KVM unit-tests.

There are many variants to this problem, and the only solution which I
consider complete is to report to the VM the maximum (52) physical address
width to the VM, configure the VM to exit on #PF with reserved-bit
error-codes, and then emulate these faulting instructions.

Thoughts/ideas?

Regards,
Nadav

Re: 2 CPU Conformance Issue in KVM/x86

[Paolo Bonzini]

On 03/03/2015 09:34, Nadav Amit wrote:
> I got two conformance issues in x86/KVM. For the first one I have no
> solution. For the latter, my solution is not “great”. Ideas and feedback
> would be appreciated.
> 
> The first problem is caused by the deprecating of FPU CS/DS in new Intel
> CPUs. Assume the VM executes a floating point instruction in real mode (when
> CS != 0), and later KVM exits to userspace, causing XSAVE/XRSTOR to save and
> restore the FPU state. At this point FPU CS/DS in new CPUs are zero. If the
> VM then executes FSAVE in real-mode the save FPU IP would be wrong, since it
> is actually calculated by the CPU as [FPU CS] * 4 + [FPU IP].

I think this was analyzed a couple years ago and we decided that this
bit was not virtualizable.

> The second problem occurs when the maximum physical address width that KVM
> reports to the VM is different than the real one. Assume the real one is
> greater than the reported one (which in KVM is not greater than 40).

In RHEL we patched QEMU to report the host physical address width in
0x80000008.  This is less than perfect when you involve migration, which
is why it's not upstream, but it avoids the problem you are reporting.

> In this
> case, the VM might expect exceptions when PTE bits which are higher than the
> maximum (reported) address width are set, and it would not get such
> exceptions. This problem can easily be experienced by small change to the
> existing KVM unit-tests.
> 
> There are many variants to this problem, and the only solution which I
> consider complete is to report to the VM the maximum (52) physical address
> width to the VM, configure the VM to exit on #PF with reserved-bit
> error-codes, and then emulate these faulting instructions.

Not even that would be a definitive solution.  If the guest tries to map
RAM (e.g. a PCI BAR that is backed by RAM) above the host MAXPHYADDR,
you would get EPT misconfiguration vmexits.

I think there is no way to emulate physical address width correctly,
except by disabling EPT.

Paolo

Re: 2 CPU Conformance Issue in KVM/x86

[Nadav Amit]

Paolo,

Thanks for the feedback. One small comment below.

Paolo Bonzini <pbonzini@redhat.com> wrote:

> 
> 
> On 03/03/2015 09:34, Nadav Amit wrote:
>> I got two conformance issues in x86/KVM. For the first one I have no
>> solution. For the latter, my solution is not “great”. Ideas and feedback
>> would be appreciated.
>> 
>> The first problem is caused by the deprecating of FPU CS/DS in new Intel
>> CPUs. Assume the VM executes a floating point instruction in real mode (when
>> CS != 0), and later KVM exits to userspace, causing XSAVE/XRSTOR to save and
>> restore the FPU state. At this point FPU CS/DS in new CPUs are zero. If the
>> VM then executes FSAVE in real-mode the save FPU IP would be wrong, since it
>> is actually calculated by the CPU as [FPU CS] * 4 + [FPU IP].
> 
> I think this was analyzed a couple years ago and we decided that this bit
> was not virtualizable.

I am fully aware of the previous reports ( https://lkml.org/lkml/2013/10/16/258 ).

However, one might have expected the conformance problem to be fully
resolved now, since [FPU CS] and [FPU DS] are deprecated in new CPUs.
Indeed, the problem is resolved in all modes, but not in real-mode.

Regards,
Nadav

Re: 2 CPU Conformance Issue in KVM/x86

[Radim Krčmář]

2015-03-03 12:18+0200, Nadav Amit:
> Paolo Bonzini <pbonzini@redhat.com> wrote:
> > On 03/03/2015 09:34, Nadav Amit wrote:
> >> I got two conformance issues in x86/KVM. For the first one I have no
> >> solution. For the latter, my solution is not “great”. Ideas and feedback
> >> would be appreciated.
> >> 
> >> The first problem is caused by the deprecating of FPU CS/DS in new Intel
> >> CPUs. Assume the VM executes a floating point instruction in real mode (when
> >> CS != 0), and later KVM exits to userspace, causing XSAVE/XRSTOR to save and
> >> restore the FPU state. At this point FPU CS/DS in new CPUs are zero. If the
> >> VM then executes FSAVE in real-mode the save FPU IP would be wrong, since it
> >> is actually calculated by the CPU as [FPU CS] * 4 + [FPU IP].
> > 
> > I think this was analyzed a couple years ago and we decided that this bit
> > was not virtualizable.
> 
> I am fully aware of the previous reports ( https://lkml.org/lkml/2013/10/16/258 ).
> 
> However, one might have expected the conformance problem to be fully
> resolved now, since [FPU CS] and [FPU DS] are deprecated in new CPUs.
> Indeed, the problem is resolved in all modes, but not in real-mode.

Since we can't get the CS/DS from real FPUs, we'd have to do ugly and
slow hacks to virtualize it (checking all possible changes of FPU
pointers and code segments).

I think that forcing the deprecation bit to guest CPUID, if set on host,
would be the best compromise between correctness and sanity.

Re: 2 CPU Conformance Issue in KVM/x86

[Avi Kivity]

On 03/03/2015 11:52 AM, Paolo Bonzini wrote:
>> In this
>> case, the VM might expect exceptions when PTE bits which are higher than the
>> maximum (reported) address width are set, and it would not get such
>> exceptions. This problem can easily be experienced by small change to the
>> existing KVM unit-tests.
>>
>> There are many variants to this problem, and the only solution which I
>> consider complete is to report to the VM the maximum (52) physical address
>> width to the VM, configure the VM to exit on #PF with reserved-bit
>> error-codes, and then emulate these faulting instructions.
> Not even that would be a definitive solution.  If the guest tries to map
> RAM (e.g. a PCI BAR that is backed by RAM) above the host MAXPHYADDR,
> you would get EPT misconfiguration vmexits.
>
> I think there is no way to emulate physical address width correctly,
> except by disabling EPT.
>

Is the issue emulating a higher MAXPHYADDR on the guest than is 
available on the host? I don't think there's any need to support that.

Emulating a lower setting on the guest than is available on the host is, 
I think, desirable. Whether it would work depends on the relative 
priority of EPT misconfiguration exits vs. page table permission faults.

Re: 2 CPU Conformance Issue in KVM/x86

[Nadav Amit]

Avi Kivity <avi.kivity@gmail.com> wrote:

> On 03/03/2015 11:52 AM, Paolo Bonzini wrote:
>>> In this
>>> case, the VM might expect exceptions when PTE bits which are higher than the
>>> maximum (reported) address width are set, and it would not get such
>>> exceptions. This problem can easily be experienced by small change to the
>>> existing KVM unit-tests.
>>> 
>>> There are many variants to this problem, and the only solution which I
>>> consider complete is to report to the VM the maximum (52) physical address
>>> width to the VM, configure the VM to exit on #PF with reserved-bit
>>> error-codes, and then emulate these faulting instructions.
>> Not even that would be a definitive solution.  If the guest tries to map
>> RAM (e.g. a PCI BAR that is backed by RAM) above the host MAXPHYADDR,
>> you would get EPT misconfiguration vmexits.
>> 
>> I think there is no way to emulate physical address width correctly,
>> except by disabling EPT.
> 
> Is the issue emulating a higher MAXPHYADDR on the guest than is available
> on the host? I don't think there's any need to support that.
> 
> Emulating a lower setting on the guest than is available on the host is, I
> think, desirable. Whether it would work depends on the relative priority
> of EPT misconfiguration exits vs. page table permission faults.

Thanks for the feedback.

Guest page-table permissions faults got priority over EPT misconfiguration.
KVM can even be set to trap page-table permission faults, at least in VT-x.
Anyhow, I don’t think it is enough. Here is an example

My machine has MAXPHYADDR of 46. I modified kvm-unit-tests access test to
set pte.45 instead of pte.51, which from the VM point-of-view should cause
the #PF error-code indicate the reserved bits are set (just as pte.51 does).
Here is one error from the log:

test pte.p pte.45 pde.p user: FAIL: error code 5 expected d
Dump mapping: address: 123400000000
------L4: 304b007
------L3: 304c007
------L2: 304d001
------L1: 200002000001

As you can see, the #PF should have had two reasons: reserved bits, and user
access to supervisor only page. The error-code however does not indicate the
reserved-bits are set.

Note that KVM did not trap any exit on that faulting instruction, as
otherwise it would try to emulate the instruction and assuming it is
supported (and that the #PF was not on an instruction fetch), should be able
to emulate the #PF correctly. 
[ The test actually crashes soon after this error due to these reasons. ]

Anyhow, that is the reason for me to assume that having the maximum
MAXPHYADDR is better.

Nadav

Re: 2 CPU Conformance Issue in KVM/x86

[Avi Kivity]

On 03/09/2015 07:51 PM, Nadav Amit wrote:
> Avi Kivity <avi.kivity@gmail.com> wrote:
>
>> On 03/03/2015 11:52 AM, Paolo Bonzini wrote:
>>>> In this
>>>> case, the VM might expect exceptions when PTE bits which are higher than the
>>>> maximum (reported) address width are set, and it would not get such
>>>> exceptions. This problem can easily be experienced by small change to the
>>>> existing KVM unit-tests.
>>>>
>>>> There are many variants to this problem, and the only solution which I
>>>> consider complete is to report to the VM the maximum (52) physical address
>>>> width to the VM, configure the VM to exit on #PF with reserved-bit
>>>> error-codes, and then emulate these faulting instructions.
>>> Not even that would be a definitive solution.  If the guest tries to map
>>> RAM (e.g. a PCI BAR that is backed by RAM) above the host MAXPHYADDR,
>>> you would get EPT misconfiguration vmexits.
>>>
>>> I think there is no way to emulate physical address width correctly,
>>> except by disabling EPT.
>> Is the issue emulating a higher MAXPHYADDR on the guest than is available
>> on the host? I don't think there's any need to support that.
>>
>> Emulating a lower setting on the guest than is available on the host is, I
>> think, desirable. Whether it would work depends on the relative priority
>> of EPT misconfiguration exits vs. page table permission faults.
> Thanks for the feedback.
>
> Guest page-table permissions faults got priority over EPT misconfiguration.
> KVM can even be set to trap page-table permission faults, at least in VT-x.
> Anyhow, I don’t think it is enough.

Why is it not enough? If you trap a permission fault, you can inject any 
exception error code you like.

>   Here is an example
>
> My machine has MAXPHYADDR of 46. I modified kvm-unit-tests access test to
> set pte.45 instead of pte.51, which from the VM point-of-view should cause
> the #PF error-code indicate the reserved bits are set (just as pte.51 does).
> Here is one error from the log:
>
> test pte.p pte.45 pde.p user: FAIL: error code 5 expected d
> Dump mapping: address: 123400000000
> ------L4: 304b007
> ------L3: 304c007
> ------L2: 304d001
> ------L1: 200002000001

This is with an ept misconfig programmed into that address, yes?

> As you can see, the #PF should have had two reasons: reserved bits, and user
> access to supervisor only page. The error-code however does not indicate the
> reserved-bits are set.
>
> Note that KVM did not trap any exit on that faulting instruction, as
> otherwise it would try to emulate the instruction and assuming it is
> supported (and that the #PF was not on an instruction fetch), should be able
> to emulate the #PF correctly.
> [ The test actually crashes soon after this error due to these reasons. ]
>
> Anyhow, that is the reason for me to assume that having the maximum
> MAXPHYADDR is better.
>

Well, that doesn't work for the reasons Paolo noted.  The guest can have 
a ivshmem device attached, and map it above a host-supported virtual 
address, and suddenly it goes slow.

Re: 2 CPU Conformance Issue in KVM/x86

[Nadav Amit]

Avi Kivity <avi.kivity@gmail.com> wrote:

> On 03/09/2015 07:51 PM, Nadav Amit wrote:
>> Avi Kivity <avi.kivity@gmail.com> wrote:
>> 
>>> On 03/03/2015 11:52 AM, Paolo Bonzini wrote:
>>>>> In this
>>>>> case, the VM might expect exceptions when PTE bits which are higher than the
>>>>> maximum (reported) address width are set, and it would not get such
>>>>> exceptions. This problem can easily be experienced by small change to the
>>>>> existing KVM unit-tests.
>>>>> 
>>>>> There are many variants to this problem, and the only solution which I
>>>>> consider complete is to report to the VM the maximum (52) physical address
>>>>> width to the VM, configure the VM to exit on #PF with reserved-bit
>>>>> error-codes, and then emulate these faulting instructions.
>>>> Not even that would be a definitive solution.  If the guest tries to map
>>>> RAM (e.g. a PCI BAR that is backed by RAM) above the host MAXPHYADDR,
>>>> you would get EPT misconfiguration vmexits.
>>>> 
>>>> I think there is no way to emulate physical address width correctly,
>>>> except by disabling EPT.
>>> Is the issue emulating a higher MAXPHYADDR on the guest than is available
>>> on the host? I don't think there's any need to support that.
>>> 
>>> Emulating a lower setting on the guest than is available on the host is, I
>>> think, desirable. Whether it would work depends on the relative priority
>>> of EPT misconfiguration exits vs. page table permission faults.
>> Thanks for the feedback.
>> 
>> Guest page-table permissions faults got priority over EPT misconfiguration.
>> KVM can even be set to trap page-table permission faults, at least in VT-x.
>> Anyhow, I don’t think it is enough.
> 
> Why is it not enough? If you trap a permission fault, you can inject any exception error code you like.

Because there is no real permission fault. In the following example, the VM
expects one (VM’s MAXPHYADDR=40), but there isn’t (Host’s MAXPHYADDR=46), so
the hypervisor cannot trap it. It can only trap all #PF, which is obviously
too intrusive.

>>  Here is an example
>> 
>> My machine has MAXPHYADDR of 46. I modified kvm-unit-tests access test to
>> set pte.45 instead of pte.51, which from the VM point-of-view should cause
>> the #PF error-code indicate the reserved bits are set (just as pte.51 does).
>> Here is one error from the log:
>> 
>> test pte.p pte.45 pde.p user: FAIL: error code 5 expected d
>> Dump mapping: address: 123400000000
>> ------L4: 304b007
>> ------L3: 304c007
>> ------L2: 304d001
>> ------L1: 200002000001
> 
> This is with an ept misconfig programmed into that address, yes?
A reserved bit in the PTE is set - from the VM point-of-view. If there
wasn’t another cause for #PF, it would lead to EPT violation/misconfig.

>> As you can see, the #PF should have had two reasons: reserved bits, and user
>> access to supervisor only page. The error-code however does not indicate the
>> reserved-bits are set.
>> 
>> Note that KVM did not trap any exit on that faulting instruction, as
>> otherwise it would try to emulate the instruction and assuming it is
>> supported (and that the #PF was not on an instruction fetch), should be able
>> to emulate the #PF correctly.
>> [ The test actually crashes soon after this error due to these reasons. ]
>> 
>> Anyhow, that is the reason for me to assume that having the maximum
>> MAXPHYADDR is better.
> 
> Well, that doesn't work for the reasons Paolo noted.  The guest can have a ivshmem device attached, and map it above a host-supported virtual address, and suddenly it goes slow.

I fully understand. That’s the reason I don’t have a reasonable solution.

Regards,
Nadav

Re: 2 CPU Conformance Issue in KVM/x86

[Avi Kivity]

On 03/09/2015 09:07 PM, Nadav Amit wrote:
> Avi Kivity <avi.kivity@gmail.com> wrote:
>
>> On 03/09/2015 07:51 PM, Nadav Amit wrote:
>>> Avi Kivity <avi.kivity@gmail.com> wrote:
>>>
>>>> On 03/03/2015 11:52 AM, Paolo Bonzini wrote:
>>>>>> In this
>>>>>> case, the VM might expect exceptions when PTE bits which are higher than the
>>>>>> maximum (reported) address width are set, and it would not get such
>>>>>> exceptions. This problem can easily be experienced by small change to the
>>>>>> existing KVM unit-tests.
>>>>>>
>>>>>> There are many variants to this problem, and the only solution which I
>>>>>> consider complete is to report to the VM the maximum (52) physical address
>>>>>> width to the VM, configure the VM to exit on #PF with reserved-bit
>>>>>> error-codes, and then emulate these faulting instructions.
>>>>> Not even that would be a definitive solution.  If the guest tries to map
>>>>> RAM (e.g. a PCI BAR that is backed by RAM) above the host MAXPHYADDR,
>>>>> you would get EPT misconfiguration vmexits.
>>>>>
>>>>> I think there is no way to emulate physical address width correctly,
>>>>> except by disabling EPT.
>>>> Is the issue emulating a higher MAXPHYADDR on the guest than is available
>>>> on the host? I don't think there's any need to support that.
>>>>
>>>> Emulating a lower setting on the guest than is available on the host is, I
>>>> think, desirable. Whether it would work depends on the relative priority
>>>> of EPT misconfiguration exits vs. page table permission faults.
>>> Thanks for the feedback.
>>>
>>> Guest page-table permissions faults got priority over EPT misconfiguration.
>>> KVM can even be set to trap page-table permission faults, at least in VT-x.
>>> Anyhow, I don’t think it is enough.
>> Why is it not enough? If you trap a permission fault, you can inject any exception error code you like.
> Because there is no real permission fault. In the following example, the VM
> expects one (VM’s MAXPHYADDR=40), but there isn’t (Host’s MAXPHYADDR=46), so
> the hypervisor cannot trap it. It can only trap all #PF, which is obviously
> too intrusive.

There are three cases:

1) The guest has marked the page as not present.  In this case, no 
reserved bits are set and the guest should receive its #PF.
2) The page is present and the permissions are sufficient.  In this 
case, you will get an EPT misconfiguration and can proceed to inject a 
#PF with the reserved bit flag set.
3) The page is present but permissions are not sufficient.  In this case 
you can trap the fault via the PFEC_MASK register and inject a #PF to 
the guest.

So you can emulate it and only trap permission faults.  It's still too 
expensive though.


>>>   Here is an example
>>>
>>> My machine has MAXPHYADDR of 46. I modified kvm-unit-tests access test to
>>> set pte.45 instead of pte.51, which from the VM point-of-view should cause
>>> the #PF error-code indicate the reserved bits are set (just as pte.51 does).
>>> Here is one error from the log:
>>>
>>> test pte.p pte.45 pde.p user: FAIL: error code 5 expected d
>>> Dump mapping: address: 123400000000
>>> ------L4: 304b007
>>> ------L3: 304c007
>>> ------L2: 304d001
>>> ------L1: 200002000001
>> This is with an ept misconfig programmed into that address, yes?
> A reserved bit in the PTE is set - from the VM point-of-view. If there
> wasn’t another cause for #PF, it would lead to EPT violation/misconfig.
>
>>> As you can see, the #PF should have had two reasons: reserved bits, and user
>>> access to supervisor only page. The error-code however does not indicate the
>>> reserved-bits are set.
>>>
>>> Note that KVM did not trap any exit on that faulting instruction, as
>>> otherwise it would try to emulate the instruction and assuming it is
>>> supported (and that the #PF was not on an instruction fetch), should be able
>>> to emulate the #PF correctly.
>>> [ The test actually crashes soon after this error due to these reasons. ]
>>>
>>> Anyhow, that is the reason for me to assume that having the maximum
>>> MAXPHYADDR is better.
>> Well, that doesn't work for the reasons Paolo noted.  The guest can have a ivshmem device attached, and map it above a host-supported virtual address, and suddenly it goes slow.
> I fully understand. That’s the reason I don’t have a reasonable solution.

I can't think of one with reasonable performance either.  Perhaps the 
maintainers could raise the issue with Intel.  It looks academic but it 
can happen in real life -- KVM for example used to rely on reserved bits 
faults (it set all bits in the PTE so it wouldn't have been caught by this).

Re: 2 CPU Conformance Issue in KVM/x86

[Paolo Bonzini]

On 09/03/2015 18:08, Avi Kivity wrote:
> Is the issue emulating a higher MAXPHYADDR on the guest than is
> available on the host? I don't think there's any need to support that.

No, indeed.  The only problem is that the failure mode is quite horrible
(you get a triple fault, possibly while the guest is running).

If you need that, disable EPT. :)

> Emulating a lower setting on the guest than is available on the host is,
> I think, desirable. Whether it would work depends on the relative
> priority of EPT misconfiguration exits vs. page table permission faults.

Yes, that's doable.

Paolo

Re: 2 CPU Conformance Issue in KVM/x86

[Paolo Bonzini]

On 09/03/2015 20:19, Avi Kivity wrote:
> I can't think of one with reasonable performance either.  Perhaps the
> maintainers could raise the issue with Intel.  It looks academic but it
> can happen in real life -- KVM for example used to rely on reserved bits
> faults (it set all bits in the PTE so it wouldn't have been caught by
> this).

Yes, and it checked that MAXPHYADDR != 52 before.  If you want to set
only one bit, making that bit 51 makes sense anyway for simplicity, so
it is still 99.9% academic.  Once processors appear with MAXPHYADDR =
52, the remaining 0.1% will become more relevant.

The current limit is IIRC 46 or 48 (on Haswell Xeons).

Paolo

Re: 2 CPU Conformance Issue in KVM/x86

[Avi Kivity]

On 03/09/2015 09:38 PM, Paolo Bonzini wrote:
>
> On 09/03/2015 20:19, Avi Kivity wrote:
>> I can't think of one with reasonable performance either.  Perhaps the
>> maintainers could raise the issue with Intel.  It looks academic but it
>> can happen in real life -- KVM for example used to rely on reserved bits
>> faults (it set all bits in the PTE so it wouldn't have been caught by
>> this).
> Yes, and it checked that MAXPHYADDR != 52 before.  If you want to set
> only one bit, making that bit 51 makes sense anyway for simplicity, so
> it is still 99.9% academic.  Once processors appear with MAXPHYADDR =
> 52, the remaining 0.1% will become more relevant.
>
> The current limit is IIRC 46 or 48 (on Haswell Xeons).
>

It will be interesting to have processors with 52 bits of physical 
address and 48 bits of virtual address. HIGHMEM for x86_64?  Or 5-level 
page tables?

50 bits == 1 PiB.  That's quite an amount of RAM.

Re: 2 CPU Conformance Issue in KVM/x86

[Avi Kivity]

On 03/09/2015 09:33 PM, Paolo Bonzini wrote:
>
> On 09/03/2015 18:08, Avi Kivity wrote:
>> Is the issue emulating a higher MAXPHYADDR on the guest than is
>> available on the host? I don't think there's any need to support that.
> No, indeed.  The only problem is that the failure mode is quite horrible
> (you get a triple fault, possibly while the guest is running).

Can't qemu simply check for it?

> If you need that, disable EPT. :)
>

Re: 2 CPU Conformance Issue in KVM/x86

[Paolo Bonzini]

On 09/03/2015 20:50, Avi Kivity wrote:
>>> Is the issue emulating a higher MAXPHYADDR on the guest than is
>>> available on the host? I don't think there's any need to support that.
>> No, indeed.  The only problem is that the failure mode is quite horrible
>> (you get a triple fault, possibly while the guest is running).
> 
> Can't qemu simply check for it?

Yes.  But right now it doesn't even try to do something sensible with
MAXPHYADDR. :/

Paolo

Re: 2 CPU Conformance Issue in KVM/x86

[Paolo Bonzini]

On 09/03/2015 20:49, Avi Kivity wrote:
>>>
>> Yes, and it checked that MAXPHYADDR != 52 before.  If you want to set
>> only one bit, making that bit 51 makes sense anyway for simplicity, so
>> it is still 99.9% academic.  Once processors appear with MAXPHYADDR =
>> 52, the remaining 0.1% will become more relevant.
>>
>> The current limit is IIRC 46 or 48 (on Haswell Xeons).
> 
> It will be interesting to have processors with 52 bits of physical
> address and 48 bits of virtual address. HIGHMEM for x86_64?  Or 5-level
> page tables?

I wonder why Intel chose exactly 52...  HIGHMEM seems more likely than
5-level page tables.  Certainly it wouldn't need hacks like Ingo's 4G-4G.

> 50 bits == 1 PiB.  That's quite an amount of RAM.

Not that 64 TiB is not "quite an amount of RAM". :)

Paolo

Re: 2 CPU Conformance Issue in KVM/x86

[Avi Kivity]

On 03/10/2015 12:47 PM, Paolo Bonzini wrote:
>
> On 09/03/2015 20:49, Avi Kivity wrote:
>>> Yes, and it checked that MAXPHYADDR != 52 before.  If you want to set
>>> only one bit, making that bit 51 makes sense anyway for simplicity, so
>>> it is still 99.9% academic.  Once processors appear with MAXPHYADDR =
>>> 52, the remaining 0.1% will become more relevant.
>>>
>>> The current limit is IIRC 46 or 48 (on Haswell Xeons).
>> It will be interesting to have processors with 52 bits of physical
>> address and 48 bits of virtual address. HIGHMEM for x86_64?  Or 5-level
>> page tables?
> I wonder why Intel chose exactly 52...  HIGHMEM seems more likely than
> 5-level page tables.  Certainly it wouldn't need hacks like Ingo's 4G-4G.

My bitcoins are on 5-level page tables.  HIGHMEM is too much pain.

>> 50 bits == 1 PiB.  That's quite an amount of RAM.
> Not that 64 TiB is not "quite an amount of RAM". :)
>
>

Depends on how many browser tabs you have open, I guess.