Rather than hardcoding the 4G boundary everywhere, introduce a
X86MachineState field @above_4g_mem_start and use it
accordingly.
This is in preparation for relocating ram-above-4g to be
dynamically start at 1T on AMD platforms.
Signed-off-by: Joao Martins
Reviewed-by: Igor Mammedov
---
hw
estimations
on max used/phys addr.
This is in preparation to determine that host-phys-bits are
enough and also for pci-hole64-size to be considered to relocate
ram-above-4g to be at 1T (on AMD platforms).
Signed-off-by: Joao Martins
Reviewed-by: Igor Mammedov
---
hw/i386/pc_piix.c
underlying
memory region isn't yet initialized.
Cc: Jonathan Cameron
Signed-off-by: Joao Martins
---
hw/i386/pc.c | 18 --
1 file changed, 8 insertions(+), 10 deletions(-)
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 3fdcab4bb4f3..c654be6cf0bd 100644
--- a/hw/i386/pc.c
+++ b/hw
There's a couple of places that seem to duplicate this calculation
of RAM size above the 4G boundary. Move all those to a helper function.
Signed-off-by: Joao Martins
Reviewed-by: Igor Mammedov
---
hw/i386/pc.c | 29 ++---
1 file changed, 14 insertions(+), 15 deletions
On 7/18/22 14:56, Igor Mammedov wrote:
> On Mon, 18 Jul 2022 15:16:22 +0200
> Igor Mammedov wrote:
>
>> On Fri, 15 Jul 2022 18:16:26 +0100
>> Joao Martins wrote:
>>
>>> Calculate max *used* GPA against the CPU maximum possible address
>>> and
On 7/18/22 14:03, Igor Mammedov wrote:
> On Fri, 15 Jul 2022 18:16:25 +0100
> Joao Martins wrote:
>
>> Move obtaining hole64_start from device_memory memory region base/size
>> into an helper alongside correspondent getters in pc_memory_init() when
>> the hotplug
On 7/18/22 13:58, Igor Mammedov wrote:
> On Fri, 15 Jul 2022 18:16:24 +0100
> Joao Martins wrote:
>
>> Remove pc_get_cxl_range_end() dependency on the CXL memory region,
>> and replace with one that does not require the CXL host_mr to determine
>
On 7/18/22 13:52, Igor Mammedov wrote:
> On Fri, 15 Jul 2022 18:16:23 +0100
> Joao Martins wrote:
>
>> Factor out the calculation of the base address of the memory region.
>> It will be used later on for the cxl range end counterpart calculation
>> and as well in
On 7/18/22 14:10, Nikunj A. Dadhania wrote:
> On 7/18/2022 6:12 PM, Igor Mammedov wrote:
>> On Mon, 18 Jul 2022 13:47:34 +0530
>> Nikunj A Dadhania wrote:
>>
>>> Currently it is possible to start a guest with memory that is beyond
>>> the addressable range of CPU and QEMU does not even warn about
) or 1010G (0xfc ) in AMD hosts
with IOMMU.
This is preparation for AMD guests with >1010G, where it will want relocate
ram-above-4g to be after 1Tb instead of 4G.
Signed-off-by: Joao Martins
---
hw/i386/pc.c | 27 +++
1 file changed, 27 insertions(+)
diff --git a
underlying
memory region isn't yet initialized.
Cc: Jonathan Cameron
Signed-off-by: Joao Martins
---
hw/i386/pc.c | 18 --
1 file changed, 8 insertions(+), 10 deletions(-)
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 3fdcab4bb4f3..c654be6cf0bd 100644
--- a/hw/i386/pc.c
+++ b/hw
Factor out the calculation of the base address of the memory region.
It will be used later on for the cxl range end counterpart calculation
and as well in pc_memory_init() CXL memory region initialization, thus
avoiding duplication.
Cc: Jonathan Cameron
Signed-off-by: Joao Martins
---
hw/i386
ones.
Signed-off-by: Joao Martins
Acked-by: Dr. David Alan Gilbert
Acked-by: Igor Mammedov
---
hw/i386/pc.c | 6 --
hw/i386/pc_piix.c| 2 ++
hw/i386/pc_q35.c | 2 ++
include/hw/i386/pc.h | 1 +
4 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/hw/i386/pc.c b/hw
to be considered to relocate
ram-above-4g to be at 1T (on AMD platforms).
Signed-off-by: Joao Martins
Reviewed-by: Igor Mammedov
---
hw/i386/pc.c | 3 ++-
hw/i386/pc_piix.c| 7 ++-
hw/i386/pc_q35.c | 10 +-
include/hw/i386/pc.h | 3 ++-
4 files changed, 19 insertions(+), 4
-off-by: Joao Martins
---
hw/i386/pc.c | 31 +--
1 file changed, 21 insertions(+), 10 deletions(-)
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 216e38da938e..1f42f194d7b7 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -825,6 +825,25 @@ static hwaddr pc_above_4g_end
t configured
with a big enough phys-bits, an error message will be printed
due to the maxphysaddr vs maxusedaddr check previously added.
Suggested-by: Igor Mammedov
Signed-off-by: Joao Martins
---
hw/i386/pc.c | 54
1 file changed, 54 inserti
om/
[7]
https://lore.kernel.org/qemu-devel/20220701161014.3850-1-joao.m.mart...@oracle.com/
[8]
https://lore.kernel.org/qemu-devel/20220714182820.30970-1-joao.m.mart...@oracle.com/
Joao Martins (11):
hw/i386: add 4g boundary start to X86MachineState
i386/pc: create pci-host qdev prior to pc_memory_ini
There's a couple of places that seem to duplicate this calculation
of RAM size above the 4G boundary. Move all those to a helper function.
Signed-off-by: Joao Martins
Reviewed-by: Igor Mammedov
---
hw/i386/pc.c | 27 ++-
1 file changed, 14 insertions(+), 13 deletions
pc_pci_hole64_start() to be callable
at the beginning of pc_memory_init() before any memory regions are
initialized.
Cc: Jonathan Cameron
Signed-off-by: Joao Martins
---
hw/i386/pc.c | 47 ---
1 file changed, 32 insertions(+), 15 deletions(-)
diff
estimations
on max used/phys addr.
This is in preparation to determine that host-phys-bits are
enough and also for pci-hole64-size to be considered to relocate
ram-above-4g to be at 1T (on AMD platforms).
Signed-off-by: Joao Martins
Reviewed-by: Igor Mammedov
---
hw/i386/pc_piix.c
Rather than hardcoding the 4G boundary everywhere, introduce a
X86MachineState field @above_4g_mem_start and use it
accordingly.
This is in preparation for relocating ram-above-4g to be
dynamically start at 1T on AMD platforms.
Signed-off-by: Joao Martins
Reviewed-by: Igor Mammedov
---
hw
On 7/15/22 12:57, Igor Mammedov wrote:
> On Thu, 14 Jul 2022 19:28:19 +0100
> Joao Martins wrote:
>
>> It is assumed that the whole GPA space is available to be DMA
>> addressable, within a given address space limit, except for a
>> tiny region before the 4G. Since
ones.
Signed-off-by: Joao Martins
Acked-by: Dr. David Alan Gilbert
Acked-by: Igor Mammedov
---
hw/i386/pc.c | 6 --
hw/i386/pc_piix.c| 2 ++
hw/i386/pc_q35.c | 2 ++
include/hw/i386/pc.h | 1 +
4 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/hw/i386/pc.c b/hw
Factor out the calculation of the base address of the memory region.
It will be used later on for the cxl range end counterpart calculation
and as well in pc_memory_init() CXL memory region initialization, thus
avoiding duplication.
Cc: Jonathan Cameron
Signed-off-by: Joao Martins
---
hw/i386
-off-by: Joao Martins
---
hw/i386/pc.c | 31 +--
1 file changed, 21 insertions(+), 10 deletions(-)
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 216e38da938e..1f42f194d7b7 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -825,6 +825,25 @@ static hwaddr pc_above_4g_end
.mart...@oracle.com/
[7]
https://lore.kernel.org/qemu-devel/20220701161014.3850-1-joao.m.mart...@oracle.com/
Joao Martins (10):
hw/i386: add 4g boundary start to X86MachineState
i386/pc: create pci-host qdev prior to pc_memory_init()
i386/pc: pass pci_hole64_size to pc_memory_init()
i
There's a couple of places that seem to duplicate this calculation
of RAM size above the 4G boundary. Move all those to a helper function.
Signed-off-by: Joao Martins
Reviewed-by: Igor Mammedov
---
hw/i386/pc.c | 27 ++-
1 file changed, 14 insertions(+), 13 deletions
estimations
on max used/phys addr.
This is in preparation to determine that host-phys-bits are
enough and also for pci-hole64-size to be considered to relocate
ram-above-4g to be at 1T (on AMD platforms).
Signed-off-by: Joao Martins
Reviewed-by: Igor Mammedov
---
hw/i386/pc_piix.c
t configured
with a big enough phys-bits, print an error message to the user
and do not make the relocation of the above-4g-region if phys-bits
is too low.
Suggested-by: Igor Mammedov
Signed-off-by: Joao Martins
---
hw/i386/pc.c | 82
1 file
to be considered to relocate
ram-above-4g to be at 1T (on AMD platforms).
Signed-off-by: Joao Martins
Reviewed-by: Igor Mammedov
---
hw/i386/pc.c | 3 ++-
hw/i386/pc_piix.c| 7 ++-
hw/i386/pc_q35.c | 10 +-
include/hw/i386/pc.h | 3 ++-
4 files changed, 19 insertions(+), 4
pc_pci_hole64_start() to be callable
at the beginning of pc_memory_init() before any memory regions are
initialized.
Cc: Jonathan Cameron
Signed-off-by: Joao Martins
---
hw/i386/pc.c | 47 ---
1 file changed, 32 insertions(+), 15 deletions(-)
diff
Rather than hardcoding the 4G boundary everywhere, introduce a
X86MachineState field @above_4g_mem_start and use it
accordingly.
This is in preparation for relocating ram-above-4g to be
dynamically start at 1T on AMD platforms.
Signed-off-by: Joao Martins
Reviewed-by: Igor Mammedov
---
hw
underlying
memory region isn't yet initialized.
Cc: Jonathan Cameron
Signed-off-by: Joao Martins
---
hw/i386/pc.c | 18 --
1 file changed, 8 insertions(+), 10 deletions(-)
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 3fdcab4bb4f3..c654be6cf0bd 100644
--- a/hw/i386/pc.c
+++ b/hw
On 7/14/22 12:50, Igor Mammedov wrote:
> On Thu, 14 Jul 2022 11:47:19 +0100
> Joao Martins wrote:
>
>> On 7/14/22 10:54, Joao Martins wrote:
>>> On 7/14/22 10:28, Igor Mammedov wrote:
>>>> On Tue, 12 Jul 2022 12:35:49 +0100
>>>> Joao Martins wro
On 7/14/22 10:54, Joao Martins wrote:
> On 7/14/22 10:28, Igor Mammedov wrote:
>> On Tue, 12 Jul 2022 12:35:49 +0100
>> Joao Martins wrote:
>>> On 7/12/22 11:01, Joao Martins wrote:
>>>> On 7/12/22 10:06, Igor Mammedov wrote:
>>>>> On Mon, 1
On 7/14/22 10:28, Igor Mammedov wrote:
> On Tue, 12 Jul 2022 12:35:49 +0100
> Joao Martins wrote:
>
>> On 7/12/22 11:01, Joao Martins wrote:
>>> On 7/12/22 10:06, Igor Mammedov wrote:
>>>> On Mon, 11 Jul 2022 21:03:28 +0100
>>>> Joao Martins wro
On 7/12/22 11:01, Joao Martins wrote:
> On 7/12/22 10:06, Igor Mammedov wrote:
>> On Mon, 11 Jul 2022 21:03:28 +0100
>> Joao Martins wrote:
>>> On 7/11/22 16:31, Joao Martins wrote:
>>>> On 7/11/22 15:52, Joao Martins wrote:
>>>>> On 7/11/22
On 7/12/22 11:01, Joao Martins wrote:
> On 7/12/22 10:06, Igor Mammedov wrote:
>> On Mon, 11 Jul 2022 21:03:28 +0100
>> Joao Martins wrote:
>>> On 7/11/22 16:31, Joao Martins wrote:
>>>> On 7/11/22 15:52, Joao Martins wrote:
>>>>> On 7/11/22
On 7/12/22 10:06, Igor Mammedov wrote:
> On Mon, 11 Jul 2022 21:03:28 +0100
> Joao Martins wrote:
>
>> On 7/11/22 16:31, Joao Martins wrote:
>>> On 7/11/22 15:52, Joao Martins wrote:
>>>> On 7/11/22 13:56, Igor Mammedov wrote:
>>>>> On
On 7/11/22 23:17, B wrote:
> Am 11. Juli 2022 10:01:49 UTC schrieb Joao Martins
> :
>> On 7/9/22 21:51, B wrote:
>>> Am 1. Juli 2022 16:10:07 UTC schrieb Joao Martins
>>> :
>>>> Use the pre-initialized pci-host qdev and fetch the
>>>> pci-
On 7/11/22 16:31, Joao Martins wrote:
> On 7/11/22 15:52, Joao Martins wrote:
>> On 7/11/22 13:56, Igor Mammedov wrote:
>>> On Fri, 1 Jul 2022 17:10:13 +0100
>>> Joao Martins wrote:
>>>
>>>> diff --git a/hw/i386/pc.c b/hw/i386/pc.c
>>>>
On 7/11/22 15:52, Joao Martins wrote:
> On 7/11/22 13:56, Igor Mammedov wrote:
>> On Fri, 1 Jul 2022 17:10:13 +0100
>> Joao Martins wrote:
>>
>>> diff --git a/hw/i386/pc.c b/hw/i386/pc.c
>>> index a79fa1b6beeb..07025b510540 100644
>>> --- a/h
On 7/11/22 14:03, Igor Mammedov wrote:
> On Fri, 1 Jul 2022 17:10:14 +0100
> Joao Martins wrote:
>
>> The added enforcing is only relevant in the case of AMD where the
>> range right before the 1TB is restricted and cannot be DMA mapped
>> by the kernel co
On 7/11/22 13:56, Igor Mammedov wrote:
> On Fri, 1 Jul 2022 17:10:13 +0100
> Joao Martins wrote:
>
>> diff --git a/hw/i386/pc.c b/hw/i386/pc.c
>> index a79fa1b6beeb..07025b510540 100644
>> --- a/hw/i386/pc.c
>> +++ b/hw/i386/pc.c
>> @@ -907,6 +907,87
On 7/11/22 13:47, Igor Mammedov wrote:
> On Thu, 7 Jul 2022 16:18:43 +0100
> Joao Martins wrote:
>
>> On 7/7/22 14:00, Igor Mammedov wrote:
>>> On Fri, 1 Jul 2022 17:10:10 +0100
>>> Joao Martins wrote:
>>>
>>>> Factor out the calculati
On 7/11/22 13:58, Igor Mammedov wrote:
> On Thu, 7 Jul 2022 16:21:07 +0100
> Joao Martins wrote:
>
>> On 7/7/22 14:05, Igor Mammedov wrote:
>>> On Fri, 1 Jul 2022 17:10:11 +0100
>>> Joao Martins wrote:
>>>
>>>> This in prepara
On 7/9/22 21:51, B wrote:
> Am 1. Juli 2022 16:10:07 UTC schrieb Joao Martins :
>> Use the pre-initialized pci-host qdev and fetch the
>> pci-hole64-size into pc_memory_init() newly added argument.
>> piix needs a bit of care given all the !pci_enabled()
>> and that the
On 7/1/22 17:10, Joao Martins wrote:
> +/*
> + * The HyperTransport range close to the 1T boundary is unique to AMD
> + * hosts with IOMMUs enabled. Restrict the ram-above-4g relocation
> + * to above 1T to AMD vCPUs only.
> + */
> +i
On 7/7/22 14:15, Igor Mammedov wrote:
> On Fri, 1 Jul 2022 17:10:12 +0100
> Joao Martins wrote:
>
>> Move obtaining hole64_start from device_memory MR base/size into an helper
>> alongside correspondent getters in pc_memory_init() when the hotplug
&g
On 7/7/22 14:05, Igor Mammedov wrote:
> On Fri, 1 Jul 2022 17:10:11 +0100
> Joao Martins wrote:
>
>> This in preparation to allow pc_pci_hole64_start() to be called early
>> in pc_memory_init(), handle CXL memory region end when its underlying
>> memory region isn'
On 7/7/22 14:00, Igor Mammedov wrote:
> On Fri, 1 Jul 2022 17:10:10 +0100
> Joao Martins wrote:
>
>> Factor out the calculation of the base address of the MR. It will be
>> used later on for the cxl range end counterpart calculation and as
>> well in pc_memory_i
On 7/7/22 13:57, Igor Mammedov wrote:
> On Fri, 1 Jul 2022 17:10:09 +0100
> Joao Martins wrote:
>
>> Move calculation of CXL memory region end to separate helper in
>> preparation to allow pc_pci_hole64_start() to be called before
>> any mrs are initialized.
> s/m
On 7/7/22 13:42, Igor Mammedov wrote:
> On Fri, 1 Jul 2022 17:10:08 +0100
> Joao Martins wrote:
>
>> There's a couple of places that seem to duplicate this calculation
>> of RAM size above the 4G boundary. Move all those to a helper function.
>>
>> Signed-of
On 7/4/22 15:27, Dr. David Alan Gilbert wrote:
> * Joao Martins (joao.m.mart...@oracle.com) wrote:
>> The added enforcing is only relevant in the case of AMD where the
>> range right before the 1TB is restricted and cannot be DMA mapped
>> by the kernel conseque
but not older ones.
Signed-off-by: Joao Martins
---
hw/i386/pc.c | 6 --
hw/i386/pc_piix.c| 2 ++
hw/i386/pc_q35.c | 2 ++
include/hw/i386/pc.h | 1 +
4 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 07025b510540..f99e16a5db4b 100644
This in preparation to allow pc_pci_hole64_start() to be called early
in pc_memory_init(), handle CXL memory region end when its underlying
memory region isn't yet initialized.
Cc: Jonathan Cameron
Signed-off-by: Joao Martins
---
hw/i386/pc.c | 13 +
1 file changed, 13 insertions
Factor out the calculation of the base address of the MR. It will be
used later on for the cxl range end counterpart calculation and as
well in pc_memory_init() CXL mr initialization, thus avoiding
duplication.
Cc: Jonathan Cameron
Signed-off-by: Joao Martins
---
hw/i386/pc.c | 28
are initialized.
Cc: Jonathan Cameron
Signed-off-by: Joao Martins
---
hw/i386/pc.c | 55 +++-
1 file changed, 41 insertions(+), 14 deletions(-)
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index d6dff71012ab..a79fa1b6beeb 100644
--- a/hw/i386/pc.c
+++ b/hw
t configured
with a big enough phys-bits, print an error message to the user
and do not make the relocation of the above-4g-region if phys-bits
is too low.
Suggested-by: Igor Mammedov
Signed-off-by: Joao Martins
---
hw/i386/pc.c | 101 +++
1 file
Move calculation of CXL memory region end to separate helper in
preparation to allow pc_pci_hole64_start() to be called before
any mrs are initialized.
Cc: Jonathan Cameron
Signed-off-by: Joao Martins
---
hw/i386/pc.c | 31 +--
1 file changed, 21 insertions(+), 10
There's a couple of places that seem to duplicate this calculation
of RAM size above the 4G boundary. Move all those to a helper function.
Signed-off-by: Joao Martins
---
hw/i386/pc.c | 29 ++---
1 file changed, 14 insertions(+), 15 deletions(-)
diff --git a/hw/i386
om/
[6]
https://lore.kernel.org/qemu-devel/20220520104532.9816-1-joao.m.mart...@oracle.com/
Joao Martins (10):
hw/i386: add 4g boundary start to X86MachineState
i386/pc: create pci-host qdev prior to pc_memory_init()
i386/pc: pass pci_hole64_size to pc_memory_init()
i386/pc: factor out above-4g end to
-hole64-size to be considered to relocate
ram-above-4g to be at 1T (on AMD platforms).
Signed-off-by: Joao Martins
Reviewed-by: Igor Mammedov
---
hw/i386/pc.c | 3 ++-
hw/i386/pc_piix.c| 5 -
hw/i386/pc_q35.c | 8 +++-
hw/pci-host/i440fx.c
estimations
on max used/phys addr.
This is in preparation to determine that host-phys-bits are
enough and also for pci-hole64-size to be considered to relocate
ram-above-4g to be at 1T (on AMD platforms).
Signed-off-by: Joao Martins
Reviewed-by: Igor Mammedov
---
hw/i386/pc_piix.c
Rather than hardcoding the 4G boundary everywhere, introduce a
X86MachineState field @above_4g_mem_start and use it
accordingly.
This is in preparation for relocating ram-above-4g to be
dynamically start at 1T on AMD platforms.
Signed-off-by: Joao Martins
Reviewed-by: Igor Mammedov
---
hw
On 6/28/22 13:38, Igor Mammedov wrote:
> On Mon, 20 Jun 2022 19:13:46 +0100
> Joao Martins wrote:
>
>> On 6/20/22 17:36, Joao Martins wrote:
>>> On 6/20/22 15:27, Igor Mammedov wrote:
>>>> On Fri, 17 Jun 2022 14:33:02 +0100
>>>> Joao Martins
On 6/23/22 17:03, Alex Williamson wrote:
> On Thu, 23 Jun 2022 00:18:06 +0100
> Joao Martins wrote:
>> On 6/22/22 23:37, Alex Williamson wrote:
>>> On Fri, 20 May 2022 11:45:27 +0100
>>> Joao Martins wrote:
>>>> v4[5] -> v5:
>>>&
On 6/22/22 23:37, Alex Williamson wrote:
> On Fri, 20 May 2022 11:45:27 +0100
> Joao Martins wrote:
>> v4[5] -> v5:
>> * Fixed the 32-bit build(s) (patch 1, Michael Tsirkin)
>> * Fix wrong reference (patch 4) to TCG_PHYS_BITS in code comment and
>> commit message;
On 6/20/22 17:36, Joao Martins wrote:
> On 6/20/22 15:27, Igor Mammedov wrote:
>> On Fri, 17 Jun 2022 14:33:02 +0100
>> Joao Martins wrote:
>>> On 6/17/22 13:32, Igor Mammedov wrote:
>>>> On Fri, 17 Jun 2022 13:18:38 +0100
>>>> Joao Martins wrot
On 6/20/22 15:27, Igor Mammedov wrote:
> On Fri, 17 Jun 2022 14:33:02 +0100
> Joao Martins wrote:
>> On 6/17/22 13:32, Igor Mammedov wrote:
>>> On Fri, 17 Jun 2022 13:18:38 +0100
>>> Joao Martins wrote:
>>>> On 6/16/22 15:23, Igor Mammedov wrote:
On 6/17/22 13:18, Joao Martins wrote:
> On 6/16/22 15:23, Igor Mammedov wrote:
>> On Fri, 20 May 2022 11:45:31 +0100
>> Joao Martins wrote:
>>> +}
>>> +
>>> +if (pcmc->has_reserved_memory &&
>>> + (machine->ram_size
On 6/16/22 15:27, Igor Mammedov wrote:
> On Fri, 20 May 2022 11:45:32 +0100
> Joao Martins wrote:
>
>> The added enforcing is only relevant in the case of AMD where the
>> range right before the 1TB is restricted and cannot be DMA mapped
>> by the kernel co
On 6/17/22 13:32, Igor Mammedov wrote:
> On Fri, 17 Jun 2022 13:18:38 +0100
> Joao Martins wrote:
>> On 6/16/22 15:23, Igor Mammedov wrote:
>>> On Fri, 20 May 2022 11:45:31 +0100
>>> Joao Martins wrote:
>>>> +
On 6/16/22 15:23, Igor Mammedov wrote:
> On Fri, 20 May 2022 11:45:31 +0100
> 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
>
On 6/16/22 14:21, Reviewed-by: Igor Mammedov wrote:
> On Fri, 20 May 2022 11:45:29 +0100
> Joao Martins wrote:
>
>> At the start of pc_memory_init() we usually pass a range of
>> 0..UINT64_MAX as pci_memory, when really its 2G (i440fx) or
>> 32G (q35). To get the real
On 6/16/22 14:05, Igor Mammedov wrote:
> On Fri, 20 May 2022 11:45:28 +0100
> Joao Martins wrote:
>> Rather than hardcoding the 4G boundary everywhere, introduce a
>> X86MachineState property @above_4g_mem_start and use it
> so far it's just field not a property /fix com
On 6/16/22 14:30, Igor Mammedov wrote:
> On Fri, 20 May 2022 11:45:30 +0100
> Joao Martins wrote:
>
>> Use the pre-initialized pci-host qdev and fetch the
>> pci-hole64-size into pc_memory_init() newly added argument.
>> piix needs a bit of care
On 6/14/22 17:34, Avihai Horon wrote:
>
> On 6/14/2022 2:08 PM, Joao Martins wrote:
>> External email: Use caution opening links or attachments
>>
>>
>> On 5/30/22 18:07, Avihai Horon wrote:
>>> +static int vfio_save_complete_precopy(QEMUFile *f, v
On 5/30/22 18:07, Avihai Horon wrote:
> +static int vfio_save_complete_precopy(QEMUFile *f, void *opaque)
> +{
> +VFIODevice *vbasedev = opaque;
> +enum vfio_device_mig_state recover_state;
> +int ret;
> +
> +/* We reach here with device state STOP or STOP_COPY only */
> +
On 5/20/22 11:45, Joao Martins wrote:
> v4[5] -> v5:
> * Fixed the 32-bit build(s) (patch 1, Michael Tsirkin)
> * Fix wrong reference (patch 4) to TCG_PHYS_BITS in code comment and
> commit message;
>
> ---
>
> This series lets Qemu spawn i386 guests with >= 1010G
On 5/12/22 16:43, Avihai Horon wrote:
> Replace the current VFIO migration protocol v1 implementation with a new
> implementation corresponding to VFIO migration protocol v2.
>
> The main changes are:
> - VFIO device state is now represented as a finite state machine instead
> of a bitmap.
>
>
On 5/23/22 07:11, Avihai Horon wrote:
> On 5/20/2022 1:58 PM, Joao Martins wrote:
>>> +migrate_get_current()->skip_precopy = true;
>>> +}
>>> +
>> Perhaps it might be easier to reuse the existing knob to disable pre-copy
>> per devic
On 5/12/22 16:43, Avihai Horon wrote:
> diff --git a/hw/vfio/migration.c b/hw/vfio/migration.c
> index 21e8f9d4d4..d4b6653026 100644
> --- a/hw/vfio/migration.c
> +++ b/hw/vfio/migration.c
> @@ -863,10 +863,17 @@ int vfio_migration_probe(VFIODevice *vbasedev, Error
> **errp)
> struct
estimations
on max used/phys addr.
This is in preparation to determine that host-phys-bits are
enough and also for pci-hole64-size to be considered to relocate
ram-above-4g to be at 1T (on AMD platforms).
Signed-off-by: Joao Martins
---
hw/i386/pc_piix.c| 5 -
hw/i386/pc_q35.c
enough phys-bits, print an error message to the user
and do not make the relocation of the above-4g-region if phys-bits
is too low.
Suggested-by: Igor Mammedov
Signed-off-by: Joao Martins
---
hw/i386/pc.c | 111 +++
1 file changed, 111 insertions(+)
diff
-hole64-size to be considered to relocate
ram-above-4g to be at 1T (on AMD platforms).
Signed-off-by: Joao Martins
---
hw/i386/pc.c | 3 ++-
hw/i386/pc_piix.c| 5 -
hw/i386/pc_q35.c | 8 +++-
hw/pci-host/i440fx.c | 7 +++
include/hw/i386
8882_IOMMU.pdf
[2] https://developer.amd.com/wp-content/resources/56323-PUB_0.78.pdf
[3]
https://lore.kernel.org/qemu-devel/20220207202422.31582-1-joao.m.mart...@oracle.com/T/#u
[4] https://lore.kernel.org/all/20220223184455.9057-1-joao.m.mart...@oracle.com/
[5]
https://lore.kernel.org/qemu-devel/20
but not older ones.
Signed-off-by: Joao Martins
---
hw/i386/pc.c | 7 +--
hw/i386/pc_piix.c| 2 ++
hw/i386/pc_q35.c | 2 ++
include/hw/i386/pc.h | 1 +
4 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 652ae8ff9ccf..62f9af91f19f 100644
Rather than hardcoding the 4G boundary everywhere, introduce a
X86MachineState property @above_4g_mem_start and use it
accordingly.
This is in preparation for relocating ram-above-4g to be
dynamically start at 1T on AMD platforms.
Signed-off-by: Joao Martins
---
hw/i386/acpi-build.c | 2
On 5/13/22 16:06, Joao Martins wrote:
> On 5/13/22 13:33, Michael S. Tsirkin wrote:
>> On Wed, Apr 20, 2022 at 09:11:37PM +0100, Joao Martins wrote:
>>> It is assumed that the whole GPA space is available to be DMA
>>> addressable, within a given address space limit, e
On 5/13/22 13:33, Michael S. Tsirkin wrote:
> On Wed, Apr 20, 2022 at 09:11:37PM +0100, 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. S
On 4/20/22 21:11, Joao Martins wrote:
> v3[4] -> v4:
> (changes in patch 4 and 5 only)
> * Rebased to 7.1.0, hence move compat machine attribute to <= 7.0.0 versions
> * Check guest vCPU vendor rather than host CPU vendor (Michael Tsirkin)
> * Squash previous patch
On 5/4/22 21:11, Peter Xu wrote:
> Hi, Joao,
>
> On Thu, Apr 28, 2022 at 10:13:45PM +0100, Joao Martins wrote:
>> +/* Get the content of a spte located in @base_addr[@index] */
>> +static uint64_t vtd_set_slpte(dma_addr_t base_addr, uint32_t index,
>> +
On 5/5/22 08:41, Jason Wang wrote:
> On Wed, May 4, 2022 at 4:47 AM Joao Martins wrote:
>>
>> On 4/29/22 19:21, Peter Xu wrote:
>>> On Fri, Apr 29, 2022 at 10:12:01AM +0100, Joao Martins wrote:
>>>> On 4/29/22 03:26, Jason Wang wrote:
>>>&g
On 4/29/22 19:21, Peter Xu wrote:
> On Fri, Apr 29, 2022 at 10:12:01AM +0100, Joao Martins wrote:
>> On 4/29/22 03:26, Jason Wang wrote:
>>> On Fri, Apr 29, 2022 at 5:14 AM Joao Martins
>>> wrote:
>>>> @@ -3693,7 +3759,8 @@ static void vtd_init(IntelIOMM
On 5/2/22 13:54, Markus Armbruster wrote:
> Joao Martins writes:
>
>> Expand dirtyrate measurer that is accessible via HMP calc_dirty_rate
>> or QMP 'calc-dirty-rate' to receive a @scope argument. The scope
>> then restricts the dirty tracking to be done at device
On 4/29/22 03:26, Jason Wang wrote:
> On Fri, Apr 29, 2022 at 5:14 AM Joao Martins
> wrote:
>> @@ -3693,7 +3759,8 @@ static void vtd_init(IntelIOMMUState *s)
>>
>> /* TODO: read cap/ecap from host to decide which cap to be exposed. */
>> if (s->sca
attempting to fetch these bitmaps,
should the iommu tracker fail to start in a previous call
to HWPT_SET_DIRTY.
Signed-off-by: Joao Martins
---
hw/iommufd/iommufd.c | 24
hw/iommufd/trace-events | 1 +
hw/vfio/iommufd.c| 44
/ dirty-bitmap from KVM.
This is useful to test, exercise the IOMMU dirty tracker and observe
how much a given device is dirtying memory.
Signed-off-by: Joao Martins
---
accel/kvm/kvm-all.c | 12 +
hmp-commands.hx | 5 ++--
hw/vfio/container.c | 8 ++
hw/vfio/iommufd.c
was enabled
on the given scalable mode PASID Table entry.
Signed-off-by: Joao Martins
---
hw/i386/intel_iommu.c | 18 --
include/hw/i386/intel_iommu.h | 1 +
2 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/hw/i386/intel_iommu.c b/hw/i386/intel_iommu.c
index
301 - 400 of 478 matches
Mail list logo
