qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Philippe Mathieu-Daudé" <philmd@linaro.org>
To: Ani Sinha <anisinha@redhat.com>, David Hildenbrand <david@redhat.com>
Cc: "Michael S. Tsirkin" <mst@redhat.com>,
	Marcel Apfelbaum <marcel.apfelbaum@gmail.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Richard Henderson <richard.henderson@linaro.org>,
	Eduardo Habkost <eduardo@habkost.net>,
	Igor Mammedov <imammedo@redhat.com>,
	Xiao Guangrong <xiaoguangrong.eric@gmail.com>,
	Yanan Wang <wangyanan55@huawei.com>,
	qemu-devel <qemu-devel@nongnu.org>
Subject: Re: [PATCH] mem/x86: add processor address space check for VM memory
Date: Fri, 8 Sep 2023 18:04:36 +0200	[thread overview]
Message-ID: <cef1a2f6-47d0-7fc5-5ca6-303930684f67@linaro.org> (raw)
In-Reply-To: <1574DF3A-7E1F-4C4F-9087-6E8DEE456906@redhat.com>

On 8/9/23 17:13, Ani Sinha wrote:
> 
> 
>> On 08-Sep-2023, at 7:46 PM, David Hildenbrand <david@redhat.com> wrote:
>>
>> On 08.09.23 16:12, Ani Sinha wrote:
>>>> On 08-Sep-2023, at 3:58 PM, David Hildenbrand <david@redhat.com> wrote:
>>>>
>>>> On 08.09.23 11:50, Ani Sinha wrote:
>>>>> Depending on the number of available address bits of the current processor, a
>>>>> VM can only use a certain maximum amount of memory and no more. This change
>>>>> makes sure that a VM is not configured to have more memory than what it can use
>>>>> with the current processor settings when started. Additionally, the change adds
>>>>> checks during memory hotplug to ensure that the VM does not end up getting more
>>>>> memory than what it can actually use after hotplug.
>>>>> Currently, both the above checks are only for pc (x86) platform.
>>>>> Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1235403
>>>>> CC: imammedo@redhat.com
>>>>> Signed-off-by: Ani Sinha <anisinha@redhat.com>
>>>>> ---
>>>>>   hw/i386/pc.c           | 45 ++++++++++++++++++++++++++++++++++++++++++
>>>>>   hw/mem/memory-device.c |  6 ++++++
>>>>>   include/hw/boards.h    |  9 +++++++++
>>>>>   3 files changed, 60 insertions(+)
>>>>> diff --git a/hw/i386/pc.c b/hw/i386/pc.c
>>>>> index 54838c0c41..f84e4c4916 100644
>>>>> --- a/hw/i386/pc.c
>>>>> +++ b/hw/i386/pc.c
>>>>> @@ -31,6 +31,7 @@
>>>>>   #include "hw/i386/topology.h"
>>>>>   #include "hw/i386/fw_cfg.h"
>>>>>   #include "hw/i386/vmport.h"
>>>>> +#include "hw/mem/memory-device.h"
>>>>>   #include "sysemu/cpus.h"
>>>>>   #include "hw/block/fdc.h"
>>>>>   #include "hw/ide/internal.h"
>>>>> @@ -1006,6 +1007,17 @@ void pc_memory_init(PCMachineState *pcms,
>>>>>           exit(EXIT_FAILURE);
>>>>>       }
>>>>>   +    /*
>>>>> +     * check if the VM started with more ram configured than max physical
>>>>> +     * address available with the current processor.
>>>>> +     */
>>>>> +    if (machine->ram_size > maxphysaddr + 1) {
>>>>> +        error_report("Address space limit 0x%"PRIx64" < 0x%"PRIx64
>>>>> +                     " (max configured memory), phys-bits too low (%u)",
>>>>> +                     maxphysaddr, machine->ram_size, cpu->phys_bits);
>>>>> +        exit(EXIT_FAILURE);
>>>>> +    }
>>>>
>>>> ... I know that this used to be a problem in the past, but nowadays we already do have similar checks in place?
>>>>
>>>> $ ./build/qemu-system-x86_64 -m 4T -machine q35,memory-backend=mem0 -object memory-backend-ram,id=mem0,size=4T,reserve=off
>>>> qemu-system-x86_64: Address space limit 0xffffffffff < 0x5077fffffff phys-bits too low (40)
>>> So you are saying that this is OK and should be allowed? On a 32 bit processor that can access only 4G memory, I am spinning up a 10G VM.
>>
>> Would that 32bit process have PAE (Physical Address Extension) and still be able to access that memory?
> 
> 
> You are sidestepping my point. Sure, we can improve the condition check by checking for PAE CPUID etc but that is not the issue I am trying too point out. What if the processor did not have PAE? Would we allow a VM to have memory size which the processor can’t access? There is no such check today it would seem.

Which processor, the host or the guest?

Even if the guest CPU can't access all the VM memory, this memory can be
used by devices without interaction with the CPU (see i.e. PCI).


      parent reply	other threads:[~2023-09-08 16:05 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-08  9:50 [PATCH] mem/x86: add processor address space check for VM memory Ani Sinha
2023-09-08 10:28 ` David Hildenbrand
2023-09-08 14:12   ` Ani Sinha
2023-09-08 14:16     ` David Hildenbrand
2023-09-08 15:13       ` Ani Sinha
2023-09-08 16:02         ` David Hildenbrand
2023-09-08 16:04           ` David Hildenbrand
2023-09-12 10:41           ` Ani Sinha
2023-09-12 15:34             ` David Hildenbrand
2023-09-14  5:53               ` Ani Sinha
2023-09-14  8:37                 ` David Hildenbrand
2023-09-14 11:21                   ` Ani Sinha
2023-09-14 11:49                     ` David Hildenbrand
2023-09-15 10:38                       ` Ani Sinha
2023-09-18  9:33                         ` David Hildenbrand
2023-09-18 10:07                           ` Ani Sinha
2023-09-18 10:09                             ` David Hildenbrand
2023-09-18 10:11                               ` Ani Sinha
2023-09-18 10:14                                 ` Ani Sinha
2023-09-18 10:19                                 ` David Hildenbrand
2023-09-18 10:54                                   ` Ani Sinha
2023-09-18 10:58                                     ` David Hildenbrand
2023-09-18 11:00                                       ` Ani Sinha
2023-09-18 11:02                                         ` Ani Sinha
2023-09-18 11:02                                         ` David Hildenbrand
2023-09-18 11:04                                           ` Ani Sinha
2023-09-14 17:11                   ` Ani Sinha
2023-09-16  5:17                   ` Ani Sinha
2023-09-08 16:04         ` Philippe Mathieu-Daudé [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=cef1a2f6-47d0-7fc5-5ca6-303930684f67@linaro.org \
    --to=philmd@linaro.org \
    --cc=anisinha@redhat.com \
    --cc=david@redhat.com \
    --cc=eduardo@habkost.net \
    --cc=imammedo@redhat.com \
    --cc=marcel.apfelbaum@gmail.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=richard.henderson@linaro.org \
    --cc=wangyanan55@huawei.com \
    --cc=xiaoguangrong.eric@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).