On 10/07/20 18:02, Eduardo Habkost wrote:
> On Fri, Jul 10, 2020 at 09:22:42AM +0200, Paolo Bonzini wrote:
>> On 09/07/20 21:13, Eduardo Habkost wrote:
Doesn't this require intercepting MOV-to-CR3 when the guest is in PAE
mode, so that the hypervisor can validate the high bits in the
On Fri, Jul 10, 2020 at 09:22:42AM +0200, Paolo Bonzini wrote:
> On 09/07/20 21:13, Eduardo Habkost wrote:
> >> Doesn't this require intercepting MOV-to-CR3 when the guest is in PAE
> >> mode, so that the hypervisor can validate the high bits in the PDPTEs?
> > If the fix has additional overhead,
On 09/07/20 21:13, Eduardo Habkost wrote:
>> Doesn't this require intercepting MOV-to-CR3 when the guest is in PAE
>> mode, so that the hypervisor can validate the high bits in the PDPTEs?
> If the fix has additional overhead, is the additional overhead
> bad enough to warrant making it optional?
On 09/07/20 19:00, Jim Mattson wrote:
>>
>> Mostly fine. Some edge cases, like different page fault errors for
>> addresses above GUEST_MAXPHYADDR and below HOST_MAXPHYADDR. Which I
>> think Mohammed fixed in the kernel recently.
> Doesn't this require intercepting MOV-to-CR3 when
On Thu, Jul 09, 2020 at 10:00:59AM -0700, Jim Mattson wrote:
> On Thu, Jul 9, 2020 at 2:44 AM Gerd Hoffmann wrote:
>
> > (2) GUEST_MAXPHYADDR < HOST_MAXPHYADDR
> >
> > Mostly fine. Some edge cases, like different page fault errors for
> > addresses above GUEST_MAXPHYADDR and below
On Thu, Jul 9, 2020 at 2:44 AM Gerd Hoffmann wrote:
> (2) GUEST_MAXPHYADDR < HOST_MAXPHYADDR
>
> Mostly fine. Some edge cases, like different page fault errors for
> addresses above GUEST_MAXPHYADDR and below HOST_MAXPHYADDR. Which I
> think Mohammed fixed in the kernel recently.
On 09/07/20 11:55, Mohammed Gamal wrote:
>> Ideally we would simply outlaw (3), but it's hard for backward
>> compatibility reasons. Second best solution is a flag somewhere
>> (msr, cpuid, ...) telling the guest firmware "you can use
>> GUEST_MAXPHYADDR, we guarantee it is <= HOST_MAXPHYADDR".
>
On Thu, 2020-07-09 at 11:44 +0200, Gerd Hoffmann wrote:
> Hi,
>
> > > (CCing libvir-list, and people who were included in the OVMF
> > > thread[1])
> > >
> > > [1]
> > > https://lore.kernel.org/qemu-devel/99779e9c-f05f-501b-b4be-ff719f140...@canonical.com/
> > > Also, it's important that we
Hi,
> > (CCing libvir-list, and people who were included in the OVMF
> > thread[1])
> >
> > [1]
> > https://lore.kernel.org/qemu-devel/99779e9c-f05f-501b-b4be-ff719f140...@canonical.com/
> > Also, it's important that we work with libvirt and management
> > software to ensure they have
(CCing libvir-list, and people who were included in the OVMF
thread[1])
[1]
https://lore.kernel.org/qemu-devel/99779e9c-f05f-501b-b4be-ff719f140...@canonical.com/
On Fri, Jun 19, 2020 at 05:53:44PM +0200, Mohammed Gamal wrote:
> If the CPU doesn't support GUEST_MAXPHYADDR < HOST_MAXPHYADDR we
>
On Wed, Jul 08, 2020 at 01:16:21PM -0400, Eduardo Habkost wrote:
> (CCing libvir-list, and people who were included in the OVMF
> thread[1])
>
> [1]
> https://lore.kernel.org/qemu-devel/99779e9c-f05f-501b-b4be-ff719f140...@canonical.com/
>
> On Fri, Jun 19, 2020 at 05:53:44PM +0200, Mohammed
On 19/06/20 17:53, Mohammed Gamal wrote:
> If the CPU doesn't support GUEST_MAXPHYADDR < HOST_MAXPHYADDR we
> let QEMU choose to use the host MAXPHYADDR and print a warning to the
> user.
>
> Signed-off-by: Mohammed Gamal
> ---
> target/i386/cpu.c | 11 +++
> 1 file changed, 11
12 matches
Mail list logo
