On 03/03/2023 00:19, Joao Martins wrote:
> On 02/03/2023 18:42, Alex Williamson wrote:
>> On Thu, 2 Mar 2023 00:07:35 +0000
>> Joao Martins wrote:
>>> @@ -426,6 +427,11 @@ void vfio_unblock_multiple_devices_migration(void)
>>> multiple_devices_migration_block
On 02/03/2023 18:42, Alex Williamson wrote:
> On Thu, 2 Mar 2023 00:07:35 +
> Joao Martins wrote:
>> On 28/02/2023 20:36, Alex Williamson wrote:
>>> On Tue, 28 Feb 2023 12:11:06 +
>>> Joao Martins wrote:
>>>> On 23/02/2023 21:50, Alex Williamso
On 02/03/2023 14:52, Cédric Le Goater wrote:
> Hello Joao,
> On 3/2/23 14:24, Joao Martins wrote:
>> On 27/02/2023 14:09, Cédric Le Goater wrote:
>>> On 2/22/23 18:49, Avihai Horon wrote:
>>>> --- a/hw/vfio/common.c
>>>> +++ b/hw/vfio/common.c
&g
On 27/02/2023 14:09, Cédric Le Goater wrote:
> On 2/22/23 18:49, Avihai Horon wrote:
>> --- a/hw/vfio/common.c
>> +++ b/hw/vfio/common.c
>> @@ -320,6 +320,41 @@ const MemoryRegionOps vfio_region_ops = {
>> * Device state interfaces
>> */
>> +typedef struct {
>> + unsigned long *bitmap;
>
On 02/03/2023 00:07, Joao Martins wrote:
> On 28/02/2023 20:36, Alex Williamson wrote:
[...]
>> Can we make the same argument that the overhead is negligible if a VM
>> makes use of 10s of GB of virtio-mem with 2MB block size?
>>
>> But then on a 4KB host we're
On 28/02/2023 20:36, Alex Williamson wrote:
> On Tue, 28 Feb 2023 12:11:06 +
> Joao Martins wrote:
>> On 23/02/2023 21:50, Alex Williamson wrote:
>>> On Thu, 23 Feb 2023 21:19:12 +
>>> Joao Martins wrote:
>>>> On 23/02/2023 21:05, Alex Willia
On 23/02/2023 21:50, Alex Williamson wrote:
> On Thu, 23 Feb 2023 21:19:12 +
> Joao Martins wrote:
>> On 23/02/2023 21:05, Alex Williamson wrote:
>>> On Thu, 23 Feb 2023 10:37:10 +
>>> Joao Martins wrote:
>>>> On 22/02/2023 22:10, Alex Willia
On 24/02/2023 15:56, Alex Williamson wrote:
> On Fri, 24 Feb 2023 12:53:26 +
> Joao Martins wrote:
>
>> On 24/02/2023 11:25, Joao Martins wrote:
>>> On 23/02/2023 23:26, Jason Gunthorpe wrote:
>>>> On Thu, Feb 23, 2023 at 03:33:09PM -0700, Alex Williamso
On 23/02/2023 14:56, Avihai Horon wrote:
> On 22/02/2023 22:55, Alex Williamson wrote:
>> There are various errors running this through the CI on gitlab.
>>
>> This one seems bogus but needs to be resolved regardless:
>>
>> https://gitlab.com/alex.williamson/qemu/-/jobs/3817940731
>> FAILED: lib
On 24/02/2023 11:25, Joao Martins wrote:
> On 23/02/2023 23:26, Jason Gunthorpe wrote:
>> On Thu, Feb 23, 2023 at 03:33:09PM -0700, Alex Williamson wrote:
>>> On Thu, 23 Feb 2023 16:55:54 -0400
>>> Jason Gunthorpe wrote:
>>>> On Thu, Feb 23, 2023 at
On 23/02/2023 23:26, Jason Gunthorpe wrote:
> On Thu, Feb 23, 2023 at 03:33:09PM -0700, Alex Williamson wrote:
>> On Thu, 23 Feb 2023 16:55:54 -0400
>> Jason Gunthorpe wrote:
>>> On Thu, Feb 23, 2023 at 01:06:33PM -0700, Alex Williamson wrote:
>>> Or even better figure out how to get interrupt rem
On 23/02/2023 21:50, Alex Williamson wrote:
> On Thu, 23 Feb 2023 21:19:12 +
> Joao Martins wrote:
>
>> On 23/02/2023 21:05, Alex Williamson wrote:
>>> On Thu, 23 Feb 2023 10:37:10 +
>>> Joao Martins wrote:
>>>> On 22/02/2023 22:10, Alex
On 23/02/2023 20:55, Jason Gunthorpe wrote:
> On Thu, Feb 23, 2023 at 01:06:33PM -0700, Alex Williamson wrote:
>>> #2 is the presumption that the guest is using an identity map.
>> Isn't it reasonable to require that a device support dirty tracking for
>> the entire extent if its DMA address width
On 23/02/2023 21:05, Alex Williamson wrote:
> On Thu, 23 Feb 2023 10:37:10 +
> Joao Martins wrote:
>> On 22/02/2023 22:10, Alex Williamson wrote:
>>> On Wed, 22 Feb 2023 19:49:05 +0200
>>> Avihai Horon wrote:
>>>> From: Joao Martins
>>
On 22/02/2023 22:10, Alex Williamson wrote:
> On Wed, 22 Feb 2023 19:49:05 +0200
> Avihai Horon wrote:
>> From: Joao Martins
>> @@ -612,6 +665,16 @@ static int vfio_dma_map(VFIOContainer *container,
>> hwaddr iova,
>> .iova = iova,
>> .siz
On 10/01/2023 16:52, David Woodhouse wrote:
> On Tue, 2023-01-10 at 15:43 +0000, Joao Martins wrote:
>> On 10/01/2023 12:37, David Woodhouse wrote:
>> The only user of multi-gref mapping is the block xen driver ... and only for
>> mapping the shared ring if I understood corr
On 10/01/2023 15:43, Joao Martins wrote:
> On 10/01/2023 12:37, David Woodhouse wrote:
>> So for now we'll limit the
>> back ends to mapping a single grant ref at a time.
>>
> Which is not a practical limitation right now.
Gah, no. xen-usb and 9p do use poss
On 10/01/2023 12:37, David Woodhouse wrote:
> Some parts of it are relatively straightforward; others less so. In
> particular, it looks really hard to provide a contiguous virtual mapping
> of multiple potentially discontiguous pages granted by the guest. To
> fix that we might actually need the g
On 14/10/2022 12:28, Juan Quintela wrote:
> Joao Martins wrote:
>> On 13/10/2022 17:08, Juan Quintela wrote:
>>> Oops. My understanding was that once the guest is stopped you can say
>>> how big is it.
>
> Hi
>
>> It's worth keeping in mind tha
On 13/10/2022 17:08, Juan Quintela wrote:
> Oops. My understanding was that once the guest is stopped you can say
> how big is it.
It's worth keeping in mind that conceptually a VF won't stop (e.g. DMA) until
really told through VFIO. So, stopping CPUs (guest) just means that guest code
does not
+Avihai, +Jason
On 03/10/2022 04:16, Juan Quintela wrote:
> HACK ahead.
>
> There are devices that require the guest to be stopped to tell us what
> is the size of its state.
"... and have transferred said device state" if we are talking current vfio.
We can't query size of the data_fd right n
On 8/9/22 19:06, David Hildenbrand wrote:
> On 09.08.22 12:56, Joao Martins wrote:
>> On 7/21/22 13:07, David Hildenbrand wrote:
>>> This is a follow-up on "util: NUMA aware memory preallocation" [1] by
>>> Michal.
>>>
>>> Setting the
On 7/21/22 13:07, David Hildenbrand wrote:
> This is a follow-up on "util: NUMA aware memory preallocation" [1] by
> Michal.
>
> Setting the CPU affinity of threads from inside QEMU usually isn't
> easily possible, because we don't want QEMU -- once started and running
> guest code -- to be able t
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
Acked-by: Igor Mammedov
---
hw/i386/pc.c | 46 +++---
1 file changed, 31 insertions(+), 15
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
Acked-by: Igor Mammedov
---
hw/i386/pc.c | 27 +++
1 file changed,
older 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
#x27;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
Acked-by: Igor Mammedov
---
hw/i386/pc.c | 54
0104532.9816-1-joao.m.mart...@oracle.com/
[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/
[9]
https://lore.kernel.org/qemu-devel/20220715171628.21437-1-joao.m.mart..
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
Acked-by
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
Acked-by: Igor Mammedov
---
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 6c898a86cb89..3fc3e985086a 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -825,6 +825,25 @@ static
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
+++
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 dele
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
>> the start
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
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
+++
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
older 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
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
#x27;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 in
420201138.23854-1-joao.m.mart...@oracle.com/
[6]
https://lore.kernel.org/qemu-devel/20220520104532.9816-1-joao.m.mart...@oracle.com/
[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.c
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 dele
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
older 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
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
l.org/qemu-devel/20220420201138.23854-1-joao.m.mart...@oracle.com/
[6]
https://lore.kernel.org/qemu-devel/20220520104532.9816-1-joao.m.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
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 dele
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
#x27;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
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
+++
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 preparation to
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.
> + */
> +if (IS
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
>> range is uni
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.
>>
>> Sign
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
t 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 inser
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
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
#x27;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
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
1-joao.m.mart...@oracle.com/
[5]
https://lore.kernel.org/qemu-devel/20220420201138.23854-1-joao.m.mart...@oracle.com/
[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 p
-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
401 - 500 of 609 matches
Mail list logo
