Hi Peter,
On 05/24/2018 04:16 PM, Peter Maydell wrote:
> On 24 May 2018 at 14:59, Auger Eric wrote:
>> Hi,
>>
>> On 05/24/2018 03:14 PM, Peter Maydell wrote:
>>> On 24 May 2018 at 10:04, Auger Eric wrote:
>>>> Now I am unclear about the semantics of
Hi Peter,
On 05/24/2018 04:56 PM, Peter Maydell wrote:
> On 24 May 2018 at 15:40, Auger Eric wrote:
>> Hi Peter,
>>
>> On 05/24/2018 04:16 PM, Peter Maydell wrote:
>>> Only for KVM, not for TCG, and it's the other way round: we
>>> end up with two
Hi Peter,
On 05/21/2018 04:03 PM, Peter Maydell wrote:
> Add support for multiple IOMMU indexes to the IOMMU notifier APIs.
> When initializing a notifier with iommu_notifier_init(), the caller
> must pass the IOMMU index that it is interested in. When a change
> happens, the IOMMU implementation
Hi Peter,
On 05/24/2018 07:03 PM, Peter Maydell wrote:
> On 24 May 2018 at 16:29, Auger Eric wrote:
>> On 05/21/2018 04:03 PM, Peter Maydell wrote:
>>> diff --git a/include/exec/memory.h b/include/exec/memory.h
>>> index f6226fb263..4e6b125add 100644
>>> -
On 05/24/2018 07:20 PM, Laszlo Ersek wrote:
> On 05/24/18 16:14, Ard Biesheuvel wrote:
>> On 24 May 2018 at 15:59, Laszlo Ersek wrote:
>>> On 05/24/18 15:07, Peter Maydell wrote:
On 24 May 2018 at 13:59, Laszlo Ersek wrote:
> On 05/24/18 11:11, Peter Maydell wrote:
>> Won't it also
Hi Peter,
On 05/23/2018 11:51 AM, Alex Bennée wrote:
>
> Peter Maydell writes:
>
>> Currently we don't support board configurations that put an IOMMU
>> in the path of the CPU's memory transactions, and instead just
>> assert() if the memory region fonud in address_space_translate_for_iotlb()
f
Hi Peter,
On 05/24/2018 12:54 PM, Peter Maydell wrote:
> On 24 May 2018 at 07:23, Peter Xu wrote:
>> On Wed, May 23, 2018 at 12:47:16PM +0100, Peter Maydell wrote:
>>> On 23 May 2018 at 02:06, Peter Xu wrote:
Could you elaborate a bit more on why IOMMU notifier failed to
corporate when
Hi Peter,
On 05/25/2018 10:52 AM, Peter Maydell wrote:
> On 24 May 2018 at 20:54, Auger Eric wrote:
>> Hi Peter,
>>
>> On 05/23/2018 11:51 AM, Alex Bennée wrote:
>>>
>>> Peter Maydell writes:
>>>
>>>> Currently we don't suppo
Hi,
On 09/06/2018 12:08 AM, Jonathan Marler wrote:
> Public bug reported:
>
> This occurs on qemu_v3.0.0 but not on qemu_v2.12.2 (built from
> qemu_v3.0.0 tag on github)
>
> Symptom: You'll see something like this in the kernel output:
>
> [1.285210] OF: PCI: host bridge /pcie@1000 rang
Hi David,
On 07/03/2018 08:25 PM, David Hildenbrand wrote:
> On 03.07.2018 09:19, Eric Auger wrote:
>> We define a new hotpluggable RAM region (aka. device memory).
>> Its base is 2TB GPA. This obviously requires 42b IPA support
>> in KVM/ARM, FW and guest kernel. At the moment the device
>> memory
Hi David,
On 07/03/2018 08:28 PM, David Hildenbrand wrote:
> On 03.07.2018 09:19, Eric Auger wrote:
>> From: Shameer Kolothum
>>
>> This patch adds the the memory hot-plug/hot-unplug infrastructure
>> in machvirt.
>>
>> Signed-off-by: Eric Auger
>> Signed-off-by: Shameer Kolothum
>> Signed-off-
Hi David,
On 07/03/2018 08:41 PM, David Hildenbrand wrote:
> On 03.07.2018 09:19, Eric Auger wrote:
>> When migrating a VM, we must make sure the destination host
>> supports as many IPA bits as the source. Otherwise the migration
>> must fail.
>>
>> We add a VMState infrastructure to machvirt. On
Hi David,
On 07/03/2018 08:44 PM, David Hildenbrand wrote:
> On 03.07.2018 09:19, Eric Auger wrote:
>> From: Shameer Kolothum
>>
>> This patch adds the the memory hot-plug/hot-unplug infrastructure
>> in machvirt.
>>
>> Signed-off-by: Eric Auger
>> Signed-off-by: Shameer Kolothum
>> Signed-off-
Hi Suzuki,
On 06/29/2018 01:15 PM, Suzuki K Poulose wrote:
> From: Kristina Martsenko
>
> Add support for handling 52bit guest physical address to the
> VGIC layer. So far we have limited the guest physical address
> to 48bits, by explicitly masking the upper bits. This patch
> removes the restr
Hi Suzuki,
On 07/03/2018 01:54 PM, Suzuki K Poulose wrote:
> Hi Eric,
>
> On 02/07/18 15:41, Auger Eric wrote:
>> Hi Suzuki,
>>
>> On 06/29/2018 01:15 PM, Suzuki K Poulose wrote:
>>> On arm64 VTTBR_EL2:BADDR holds the base address for the stage2
>>>
Hi David,
On 07/04/2018 01:53 PM, David Hildenbrand wrote:
> On 03.07.2018 21:32, Auger Eric wrote:
>> Hi David,
>> On 07/03/2018 08:41 PM, David Hildenbrand wrote:
>>> On 03.07.2018 09:19, Eric Auger wrote:
>>>> When migrating a VM, we must make sure the destin
Hi,
On 07/05/2018 09:51 AM, Peter Maydell wrote:
> On 4 July 2018 at 16:51, Will Deacon wrote:
>> On Wed, Jul 04, 2018 at 03:41:18PM +0100, Marc Zyngier wrote:
>>> Not really. Let's say I want my IPA space split in two: memory covers
>>> the low 47 bit, and I want MMIO spanning the top 47 bit. Wi
Hi David,
On 07/04/2018 02:05 PM, David Hildenbrand wrote:
> On 03.07.2018 21:27, Auger Eric wrote:
>> Hi David,
>> On 07/03/2018 08:25 PM, David Hildenbrand wrote:
>>> On 03.07.2018 09:19, Eric Auger wrote:
>>>> We define a new hotpluggable RAM region (aka.
Hi David,
On 07/05/2018 01:54 PM, David Hildenbrand wrote:
> On 05.07.2018 13:42, Auger Eric wrote:
>> Hi David,
>>
>> On 07/04/2018 02:05 PM, David Hildenbrand wrote:
>>> On 03.07.2018 21:27, Auger Eric wrote:
>>>> Hi David,
>>>> On
Hi David,
On 07/05/2018 02:09 PM, David Hildenbrand wrote:
> On 05.07.2018 14:00, Auger Eric wrote:
>> Hi David,
>>
>> On 07/05/2018 01:54 PM, David Hildenbrand wrote:
>>> On 05.07.2018 13:42, Auger Eric wrote:
>>>> Hi David,
>>>>
>>
Hi Peter,
On 07/05/2018 02:56 PM, Peter Maydell wrote:
> On 5 July 2018 at 08:27, Eric Auger wrote:
>> smmu_iommu_mr() aims at returning the IOMMUMemoryRegion corresponding
>> to a given sid. The function extracts both the PCIe bus number and
>> the devfn to return this data. Current computation
Hi Marc,
On 07/05/2018 03:20 PM, Marc Zyngier wrote:
> On 05/07/18 13:47, Julien Grall wrote:
>> Hi Will,
>>
>> On 04/07/18 16:52, Will Deacon wrote:
>>> On Wed, Jul 04, 2018 at 04:00:11PM +0100, Julien Grall wrote:
On 04/07/18 15:09, Will Deacon wrote:
> On Fri, Jun 29, 2018 at 12:15:42P
Hi Shameer,
On 07/05/2018 03:19 PM, Shameerali Kolothum Thodi wrote:
>
>> -Original Message-
>> From: Auger Eric [mailto:eric.au...@redhat.com]
>> Sent: 05 July 2018 13:18
>> To: David Hildenbrand ; eric.auger@gmail.com;
>> qemu-devel@nongnu.org
Hi Suzuki, Marc,
On 07/05/2018 04:15 PM, Marc Zyngier wrote:
> Hi Eric,
>
> On 05/07/18 14:46, Auger Eric wrote:
>> Hi Marc,
>>
>> On 07/05/2018 03:20 PM, Marc Zyngier wrote:
>>> On 05/07/18 13:47, Julien Grall wrote:
>>>> Hi Will,
>>>
Hi Thomas,
On 07/09/2018 07:26 PM, Thomas Huth wrote:
> On 03.07.2018 14:31, Auger Eric wrote:
>> Hi Drew,
>>
>> On 07/03/2018 01:55 PM, Andrew Jones wrote:
>>> On Wed, Jun 20, 2018 at 03:07:32PM +0200, Eric Auger wrote:
>>>> The kvm-type property curre
Hi Igor,
On 07/11/2018 03:17 PM, Igor Mammedov wrote:
> On Thu, 5 Jul 2018 16:27:05 +0200
> Auger Eric wrote:
>
>> Hi Shameer,
>>
>> On 07/05/2018 03:19 PM, Shameerali Kolothum Thodi wrote:
>>>
>>>> -Original Message-
>>>> F
Hi Drew,
On 07/12/2018 04:45 PM, Andrew Jones wrote:
> On Thu, Jul 12, 2018 at 04:22:05PM +0200, Auger Eric wrote:
>> Hi Igor,
>>
>> On 07/11/2018 03:17 PM, Igor Mammedov wrote:
>>> On Thu, 5 Jul 2018 16:27:05 +0200
>>> Auger Eric wrote:
>>>
&
Hi Peter,
On 04/16/2018 02:59 PM, Peter Maydell wrote:
> On 12 April 2018 at 08:37, Eric Auger wrote:
>> This patch implements the page table walk for VMSAv8-64.
>>
>> Signed-off-by: Eric Auger
>> Signed-off-by: Prem Mallappa
>
>> diff --git a/hw/arm/smmu-common.c b/hw/arm/smmu-common.c
>> ind
Hi Peter,
On 04/16/2018 03:08 PM, Peter Maydell wrote:
> On 12 April 2018 at 08:37, Eric Auger wrote:
>> From: Prem Mallappa
>>
>> This patch implements a skeleton for the smmuv3 device.
>> Datatypes and register definitions are introduced. The MMIO
>> region, the interrupts and the queue are ini
Hi Peter,
On 04/16/2018 06:51 PM, Peter Maydell wrote:
> On 12 April 2018 at 08:37, Eric Auger wrote:
>> Let's introduce a helper function aiming at recording an
>> event in the event queue.
>>
>> Signed-off-by: Eric Auger
>>
>> ---
>> v9 -> v10:
>> - rework SMMU_EVENT_STRING
>> - trigger a GERR
Hi Peter,
On 04/17/2018 01:02 PM, Peter Maydell wrote:
> On 12 April 2018 at 08:38, Eric Auger wrote:
>> In case the MSI is translated by an IOMMU we need to fixup the
>> MSI route with the translated address.
>>
>> Signed-off-by: Eric Auger
>> Signed-off-by: Bharat Bhushan
>>
>> ---
>> v9 -> v
Hi Peter,
On 04/17/2018 02:55 PM, Peter Maydell wrote:
> On 12 April 2018 at 08:38, Eric Auger wrote:
>> We emulate a TLB cache of size SMMU_IOTLB_MAX_SIZE=256.
>> It is implemented as a hash table whose key is a combination
>> of the 16b asid and 48b IOVA.
>>
>> Entries are invalidated on TLB inv
Hi Peter,
On 05/01/2018 12:19 PM, Peter Maydell wrote:
> Add more detail to the documentation for memory_region_init_iommu()
> and other IOMMU-related functions and data structures.
>
> Signed-off-by: Peter Maydell
> ---
> v1 -> v2 changes:
> * documented replay method
> * added note about wan
Hi Peter,
On 05/01/2018 05:00 PM, Peter Maydell wrote:
> On 1 May 2018 at 15:32, Auger Eric wrote:
>> Hi Peter,
>>
>> On 05/01/2018 12:19 PM, Peter Maydell wrote:
>>> Add more detail to the documentation for memory_region_init_iommu()
>>> and other IOMM
Hi,
I would like to resume the discussion on extending the number of PCI
buses to 256 (as in Q35) as a follow-up of past discussions:
https://lists.gnu.org/archive/html/qemu-devel/2018-01/msg03631.html.
With the current 16MB ECAM region we are limited to 16 PCIe busses.
Could we envision to have
Hi Shannon,
On 05/28/2018 10:42 AM, Shannon Zhao wrote:
> acpi_data_push uses g_array_set_size to resize the memory size. If there
> is no enough contiguous memory, the address will be changed. So previous
> pointer could not be used any more. It must update the pointer and use
> the new one.
>
>
Hi Shameer,
On 05/16/2018 05:20 PM, Shameer Kolothum wrote:
> This makes use of the newly introduced iova cap chains added
> to the type1 VFIO_IOMMU_GET_INFO ioctl.
>
> The retrieved iova info is stored in a list for later use.
>
> Signed-off-by: Shameer Kolothum
> ---
> hw/vfio/common.c
Hi Shameer,
On 05/16/2018 05:20 PM, Shameer Kolothum wrote:
> In case valid iova regions are non-contiguous, split the
> RAM mem into a 1GB non-pluggable dimm and remaining as a
> single pc-dimm mem.
Please can you explain where does this split come from? Currently we
have 254 GB non pluggable RA
Hi Shameer,
On 05/16/2018 05:20 PM, Shameer Kolothum wrote:
> This makes changes to the DT mem node creation such that its easier
> to add non-contiguous mem modeled as non-pluggable and a pc-dimm
> mem later.
See comments below. I think you should augment the description here with
what the patch
Hi Shameer,
On 05/16/2018 05:20 PM, Shameer Kolothum wrote:
> This is in preparation for the next patch where initial ram is split
> into a non-pluggable chunk and a pc-dimm modeled mem if the vaild
valid
> iova regions are non-contiguous.
>
> Signed-off-by: Shameer Kolothum
> ---
> hw/arm/vir
Hi Shameer,
On 05/16/2018 05:20 PM, Shameer Kolothum wrote:
> This will be used in subsequent patches to model a chunk of
> memory as pc-dimm(cold plug) if the valid iova regions are
> non-contiguous. This is not yet a full hotplug support.
Please can you give more details about this restriction?
Hi Shameer,
On 05/16/2018 05:20 PM, Shameer Kolothum wrote:
> When the kernel reports valid iova ranges as non-contiguous,
> memory should be allocated to Guest in such a way that
> reserved regions(holes) are not visible by Guest.
>
> This series retrieves the valid iova ranges based on the new
Hi Shameer,
On 05/16/2018 05:20 PM, Shameer Kolothum wrote:
> Register ram_memory_region_init notifier to allocate memory region
> from system memory.
At this stage the commit message does not explain why you need a machine
init done notifier. Also the commit title does not summarize the actual
ch
Hi Peter,
On 05/22/2018 02:27 PM, Peter Maydell wrote:
> On 13 May 2018 at 15:35, Eric Auger wrote:
>> To prepare for multiple redistributor regions, we introduce
>> an array of uint32_t properties that stores the redistributor
>> count of each redistributor region.
>>
>> Non accelerated VGICv3 on
Hi,
On 05/22/2018 02:43 PM, Peter Maydell wrote:
> On 13 May 2018 at 15:35, Eric Auger wrote:
>> With a VGICv3 KVM device, if the number of vcpus exceeds the
>> capacity of the legacy redistributor region (123 redistributors),
>> we now attempt to register the second redistributor region. This
>>
Hi Peter,
On 05/29/2018 11:13 AM, Peter Maydell wrote:
> On 29 May 2018 at 10:08, Auger Eric wrote:
>> Hi Peter,
>> On 05/22/2018 02:27 PM, Peter Maydell wrote:
>>> On 13 May 2018 at 15:35, Eric Auger wrote:
>>>> To prepare for multiple redistributor re
Hi,
On 05/29/2018 07:48 PM, Philippe Mathieu-Daudé wrote:
> Hi,
>
> This series converts error_setg(&error_fatal) to error_report() + exit() as
> suggested by the "qapi/error.h" documentation.
>
> This reduce Coverity and Clang static analyzer positive falses.
>
> See http://lists.nongnu.org/ar
Hi Shannon,
On 05/29/2018 04:09 PM, Shannon Zhao wrote:
>
>
>> 在 2018年5月29日，21:53，Peter Maydell 写道：
>>
>>> On 29 May 2018 at 04:08, Shannon Zhao wrote:
>>> acpi_data_push uses g_array_set_size to resize the memory size. If there
>>> is no enough contiguous memory, the address will be changed.
Hi Shannon,
On 05/30/2018 03:14 AM, Shannon Zhao wrote:
>
>
> On 2018/5/30 3:53, Auger Eric wrote:
>> Hi Shannon,
>>
>> On 05/29/2018 04:09 PM, Shannon Zhao wrote:
>>>
>>>
>>>> 在 2018年5月29日，21:53，Peter Maydell 写道：
>>>>
>
Hi Shannon,
On 05/30/2018 09:05 AM, Shannon Zhao wrote:
> acpi_data_push uses g_array_set_size to resize the memory size. If there
> is no enough contiguous memory, the address will be changed. So previous
> pointer could not be used any more. It must update the pointer and use
> the new one.
>
>
Hi Igor,
On 05/30/2018 02:13 PM, Igor Mammedov wrote:
> On Wed, 30 May 2018 13:45:38 +0200
> Eric Auger wrote:
>
>> This patch allows the creation of a GICv3 node with 1 or 2
>> redistributor regions depending on the number of smu_cpus.
>> The second redistributor region is located just after th
Hi Shameer;
On 05/30/2018 04:39 PM, Shameerali Kolothum Thodi wrote:
> Hi Eric,
>
>> -Original Message-----
>> From: Auger Eric [mailto:eric.au...@redhat.com]
>> Sent: Monday, May 28, 2018 3:22 PM
>> To: Shameerali Kolothum Thodi ;
>> qemu-devel@nongnu.
Hi Shannon,
On 05/31/2018 03:42 AM, Shannon Zhao wrote:
>
>
> On 2018/5/31 0:18, Laszlo Ersek wrote:
>> +vms->highmem_ecam &= vms->highmem && (!firmware_loaded || aarch64);
>>> +
> Does it need a info log here to tell user that even though you enable
> the highmem_ecam but due to some other
On 05/30/2018 06:18 PM, Laszlo Ersek wrote:
> On 05/30/18 16:26, Eric Auger wrote:
>> Add virt-3.0 machine type.
>>
>> This machine type supports highmem 256MB ECAM by default.
>> This feature is disabled for earlier machine types and
>> if highmem is off.
>>
>> The high 256MB ECAM region is cho
Hi Laszlo,
On 05/30/2018 06:11 PM, Laszlo Ersek wrote:
> On 05/30/18 16:26, Eric Auger wrote:
>> This patch defines a new ECAM region located after the 256GB limit.
>>
>> The virt machine state is augmented with a new highmem_ecam field
>> which guards the usage of this new ECAM region instead of
Hi Shannon,
On 05/31/2018 09:16 AM, Shannon Zhao wrote:
> kvm_irqchip_create called by kvm_init will call kvm_init_irq_routing to
> initialize global capability variables. If we call kvm_init_irq_routing in
> GIC realize function, previous allocated memory will leak.
>
> Fix this by deleting the
Hi Shannon,
On 05/31/2018 10:04 AM, Shannon Zhao wrote:
>
>
> On 2018/5/31 15:54, Auger Eric wrote:
>> Hi Shannon,
>>
>> On 05/31/2018 09:16 AM, Shannon Zhao wrote:
>>> kvm_irqchip_create called by kvm_init will call kvm_init_irq_routing to
>>> initi
Hi Laszlo,
On 05/31/2018 10:41 AM, Laszlo Ersek wrote:
> On 05/31/18 08:55, Auger Eric wrote:
>> Hi Laszlo,
>>
>> On 05/30/2018 06:11 PM, Laszlo Ersek wrote:
>>> On 05/30/18 16:26, Eric Auger wrote:
>>>> This patch defines a new ECAM region located
Hi,
On 05/31/2018 05:15 AM, Shannon Zhao wrote:
> While for_each_dist_irq_reg loop starts from GIC_INTERNAL, it forgot to
> offset the date array and index. This will overlap the GICR registers
> value and leave the last GIC_INTERNAL irq's registers out of update.
>
> Fixes: 367b9f527becdd20ddf11
Hi,
On 05/31/2018 05:15 AM, Shannon Zhao wrote:
> While we skip the GIC_INTERNAL irqs, we don't change the register offset
> accordingly. This will overlap the GICR registers value and leave the
> last GIC_INTERNAL irq's registers out of update.
>
> Fix this by skipping the registers banked by GI
Hi Shameer,
On 05/28/2018 07:02 PM, Andrew Jones wrote:
> On Wed, May 16, 2018 at 04:20:25PM +0100, Shameer Kolothum wrote:
>> This is in preparation for the next patch where initial ram is split
>> into a non-pluggable chunk and a pc-dimm modeled mem if the vaild
>> iova regions are non-contiguo
Hi Geert,
On 07/25/2018 04:34 PM, Geert Uytterhoeven wrote:
> From: Auger Eric
>
> Up to now we have relied on the device type to identify a device tree
> node creation function. Since we would like the vfio-platform device to
> be instantiatable with different compatible strin
Hi Geert,
On 07/25/2018 04:34 PM, Geert Uytterhoeven wrote:
> From: Auger Eric
>
> Up to now the vfio-platform device has been abstract and could not be
> instantiated. The integration of a new vfio platform device required
> creating a dummy derived device which only set the co
Hi Geert,
On 07/25/2018 04:34 PM, Geert Uytterhoeven wrote:
> Add a fallback for instantiating generic devices without a type-specific
> or compatible-specific instantation method. This will be used when no
> other match is found.
>
> The generic instantation method creates a device node with "r
Hi Geert,
On 07/25/2018 04:34 PM, Geert Uytterhoeven wrote:
> Allow the instantation of generic dynamic sysbus devices again, without
> the need to create a new device-specific vfio type.
The patch title and commit message need to be updated as we allow the
dynamic instantiation of VFIO PLATFORM d
Hi Geert,
On 08/07/2018 05:00 PM, Geert Uytterhoeven wrote:
> Hi Eric,
>
> On Tue, Aug 7, 2018 at 4:18 PM Auger Eric wrote:
>> On 07/25/2018 04:34 PM, Geert Uytterhoeven wrote:
>>> From: Auger Eric
>>>
>>> Up to now the vfio-platform device has been
Hi Geert,
On 08/07/2018 05:32 PM, Geert Uytterhoeven wrote:
> Hi Eric,
>
> On Tue, Aug 7, 2018 at 4:19 PM Auger Eric wrote:
>> On 07/25/2018 04:34 PM, Geert Uytterhoeven wrote:
>>> Add a fallback for instantiating generic devices without a type-specific
>>> or
Hi Igor,
On 07/18/2018 03:00 PM, Igor Mammedov wrote:
[...]
>>>
>>> I think Igor wants one contiguous region for RAM, where additional
>>> space can be reserved for hotplugging.
>> This is not compliant with 2012 ARM white paper, although I don't really
>> know if this document truly is a refere
Hi Igor,
On 07/18/2018 03:05 PM, Igor Mammedov wrote:
> On Tue, 3 Jul 2018 09:19:49 +0200
> Eric Auger wrote:
>
>> We define a new hotpluggable RAM region (aka. device memory).
>> Its base is 2TB GPA. This obviously requires 42b IPA support
>> in KVM/ARM, FW and guest kernel. At the moment the d
Hi Igor,
On 07/18/2018 04:04 PM, Igor Mammedov wrote:
> On Tue, 3 Jul 2018 09:19:51 +0200
> Eric Auger wrote:
>
>> From: Shameer Kolothum
>>
>> We introduce an helper to create a memory node.
>>
>> Signed-off-by: Eric Auger
>> Signed-off-by: Shameer Kolothum
>>
>> ---
>>
>> v1 -> v2:
>> - no
Hi Geert,
On 08/08/2018 02:59 PM, Geert Uytterhoeven wrote:
> Hi Eric,
>
> On Tue, Aug 7, 2018 at 7:21 PM Auger Eric wrote:
>> On 08/07/2018 05:32 PM, Geert Uytterhoeven wrote:
>>> On Tue, Aug 7, 2018 at 4:19 PM Auger Eric wrote:
>>>> On 07/25/2018 04:34 PM,
Hi Igor,
On 08/09/2018 10:45 AM, Igor Mammedov wrote:
> On Wed, 8 Aug 2018 11:33:23 +0200
> Auger Eric wrote:
>
>> Hi Igor,
>>
>> On 07/18/2018 03:00 PM, Igor Mammedov wrote:
>> [...]
>>>>>
>>>>> I think Igor wants one contiguous r
Hi Philippe,
On 06/25/2018 06:57 PM, Philippe Mathieu-Daudé wrote:
> Use error_report() + exit() instead of error_setg(&error_fatal),
> as suggested by the "qapi/error.h" documentation:
>
>Please don't error_setg(&error_fatal, ...), use error_report() and
>exit(), because that's more obvio
Hi Peter,
On 06/26/2018 07:06 PM, Peter Maydell wrote:
> On 22 June 2018 at 14:22, Eric Auger wrote:
>> When running dtc on the guest /proc/device-tree, we get the
>> following warnings: "Warning (unit_address_vs_reg): Node
>> has a reg or ranges property, but no unit name", with name:
>> /intc,
Hi,
On 06/13/2018 03:19 PM, Eric Auger wrote:
> When an IOMMUMemoryRegion is in front of a virtio device,
> address_space_cache_init does not set cache->ptr as the memory
> region is not RAM. However when the device performs an access,
> we end up in glue() which performs the translation and then
Hi Paolo,
On 06/27/2018 10:26 AM, Paolo Bonzini wrote:
> On 26/06/2018 22:29, Auger Eric wrote:
>>>
>>> Fixes: 48564041a73a (exec: reintroduce MemoryRegion caching)
>>> Signed-off-by: Eric Auger
>> gentle reminder, just to make sure someone is going to pic
Hi Suzuki,
On 06/29/2018 01:15 PM, Suzuki K Poulose wrote:
> Use the new helper for converting the parange to the physical shift.
> Also, add the missing definitions for the VTCR_EL2 register fields
> and use them instead of hard coding numbers.
>
> Cc: Marc Zyngier
> Cc: Christoffer Dall
> Sig
Hi Suzuki,
On 06/29/2018 01:15 PM, Suzuki K Poulose wrote:
> On a 4-level page table pgd entry can be empty, unlike a 3-level
> page table. Remove the spurious WARN_ON() in stage_get_pud().
>
> Cc: Marc Zyngier
> Acked-by: Christoffer Dall
> Signed-off-by: Suzuki K Poulose
> ---
> virt/kvm/ar
Hi Suzuki,
On 06/29/2018 01:15 PM, Suzuki K Poulose wrote:
> On arm64, ID_AA64MMFR0_EL1.PARange encodes the maximum Physical
> Address range supported by the CPU. Add a helper to decode this
> to actual physical shift. If we hit an unallocated value, return
> the maximum range supported by the ker
Hi Suzuki,
On 06/29/2018 01:15 PM, Suzuki K Poulose wrote:
> So far we have only supported 3 level page table with fixed IPA of 40bits.
> Fix stage2_flush_memslot() to accommodate for 4 level tables.
in 06/30 you add the justification for this change I think. worth to put
in here as well?
>
> Cc
Hi Suzuki,
On 06/29/2018 01:15 PM, Suzuki K Poulose wrote:
> Right now the stage2 page table for a VM is hard coded, assuming
> an IPA of 40bits. As we are about to add support for per VM IPA,
> prepare the stage2 page table helpers to accept the kvm instance
> to make the right decision for the V
Hi Suzuki,
On 06/29/2018 01:15 PM, Suzuki K Poulose wrote:
> So far we had a static stage2 page table handling code, based on a
> fixed IPA of 40bits. As we prepare for a configurable IPA size per
> VM, make our stage2 page table code dynamic, to do the right thing
> for a given VM. We ensure the
Hi Suzuki,
On 07/02/2018 03:24 PM, Suzuki K Poulose wrote:
> Hi Eric,
>
>
> On 02/07/18 13:14, Auger Eric wrote:
>> Hi Suzuki,
>>
>> On 06/29/2018 01:15 PM, Suzuki K Poulose wrote:
>>> So far we had a static stage2 page table handling code, based on a
>
Hi Suzuki,
On 06/29/2018 01:15 PM, Suzuki K Poulose wrote:
> On arm64 VTTBR_EL2:BADDR holds the base address for the stage2
> translation table. The Arm ARM mandates that the bits BADDR[x-1:0]
> should be 0, where 'x' is defined for a given IPA Size and the
> number of levels for a translation gra
Hi Suzuki
On 06/29/2018 01:15 PM, Suzuki K Poulose wrote:
> Abstract the allocation of stage2 entry level tables for
> given VM, so that later we can choose to fall back to the
> normal page table levels (i.e, avoid entry level table
> concatenation) on arm64.
the justification is not crystal cle
Hi Suzuki,
On 06/29/2018 01:15 PM, Suzuki K Poulose wrote:
> VTCR_EL2 holds the following key stage2 translation table
> parameters:
> SL0 - Entry level in the page table lookup.
> T0SZ - Denotes the size of the memory addressed by the table.
>
> We have been using fixed values for the SL0 d
Hi Suzuki,
On 06/29/2018 01:15 PM, Suzuki K Poulose wrote:
> We load the stage2 context of a guest for different operations,
> including running the guest and tlb maintenance on behalf of the
> guest. As of now only the vttbr is private to the guest, but this
> is about to change with IPA per VM.
Hi David,
On 07/02/2018 11:37 AM, David Hildenbrand wrote:
> We can assign and verify the slot before realizing and trying to plug.
> reading/writing the slot property should never fail, so let's reduce
> error handling a bit by using &error_abort.
>
> To do this during pre_plug, add and use (x86
Hi David,
On 07/02/2018 11:37 AM, David Hildenbrand wrote:
> All applicable memory regions always have an alignment > 0. All memory
> backends result in file_ram_alloc() or qemu_anon_ram_alloc() getting
> called, setting the alignment to > 0.
>
> So a PCDIMM memory region always has an alignment
Hi David,
On 07/02/2018 11:37 AM, David Hildenbrand wrote:
> Let's set the alignment just like for the posix variant. This will
> implicitly set the alignment of the underlying memory region and
> therefore make memory_region_get_alignment(mr) return something > 0 for
> all memory backends applica
Hi David,
On 07/02/2018 02:47 PM, David Hildenbrand wrote:
> On 02.07.2018 14:44, Igor Mammedov wrote:
>> On Mon, 2 Jul 2018 12:39:43 +0200
>> David Hildenbrand wrote:
>>
>>> On 02.07.2018 12:31, Igor Mammedov wrote:
On Mon, 2 Jul 2018 11:37:55 +0200
David Hildenbrand wrote:
>>
Hi David,
On 07/02/2018 02:47 PM, David Hildenbrand wrote:
> On 02.07.2018 14:44, Igor Mammedov wrote:
>> On Mon, 2 Jul 2018 12:39:43 +0200
>> David Hildenbrand wrote:
>>
>>> On 02.07.2018 12:31, Igor Mammedov wrote:
On Mon, 2 Jul 2018 11:37:55 +0200
David Hildenbrand wrote:
>
Hi Drew,
On 07/03/2018 01:55 PM, Andrew Jones wrote:
> On Wed, Jun 20, 2018 at 03:07:32PM +0200, Eric Auger wrote:
>> The kvm-type property currently is used to pass
>> a user parameter to KVM_CREATE_VM. This matches
>> the way KVM/ARM expects to pass the max_vm_phys_shift
>> parameter.
>>
>> This
Hi Peter,
On 06/15/2018 10:53 AM, Peter Maydell wrote:
> On 15 June 2018 at 08:10, Auger Eric wrote:
>> after reading 8/13, I have a doubt here about the ret.perm value that
>> stays IOMMU_RW independently on the translation success. Usually if the
>> translation failn perm
Hi Peter,
On 06/15/2018 11:04 AM, Peter Maydell wrote:
> On 14 June 2018 at 21:36, Auger Eric wrote:
>> Hi Peter,
>>
>> On 06/04/2018 05:29 PM, Peter Maydell wrote:
>>> Implement the missing registers for the TZ MPC.
>>>
>>> Signed-off
Hi Peter,
On 06/15/2018 03:16 PM, Peter Maydell wrote:
> On 15 June 2018 at 13:26, Peter Maydell wrote:
>> On 9 June 2018 at 15:23, Eric Auger wrote:
>>> When running dtc on the guest /proc/device-tree we get the
>>> following warning: Warning (unit_address_vs_reg): Node /memory
>>> has a reg or
Hi Peter,
On 06/15/2018 02:26 PM, Peter Maydell wrote:
> On 9 June 2018 at 15:23, Eric Auger wrote:
>> When running dtc on the guest /proc/device-tree we get the
>> following warning: Warning (unit_address_vs_reg): Node /memory
>> has a reg or ranges property, but no unit name".
>>
>> Let's fix t
Hi Drew,
On 06/15/2018 05:44 PM, Andrew Jones wrote:
> On Tue, Jun 05, 2018 at 07:49:44AM +, Shameerali Kolothum Thodi wrote:
On 05/16/2018 05:20 PM, Shameer Kolothum wrote:
> In case valid iova regions are non-contiguous, split the
> RAM mem into a 1GB non-pluggable dimm and rema
Hi,
On 06/15/2018 05:54 PM, Peter Maydell wrote:
> Why should the VM ever care about where the address regions in the
> host happen to be when it comes to where it's putting its RAM
> in the VM's address layout? I feel like I'm missing something here...
>
> thanks
The VM cannot use RAM GPA that
Hi Peter,
On 06/15/2018 06:09 PM, Peter Maydell wrote:
> On 15 June 2018 at 17:07, Peter Maydell wrote:
>> On 15 June 2018 at 08:31, Auger Eric wrote:
>>> Hi Peter,
>>>
>>> On 06/04/2018 05:29 PM, Peter Maydell wrote:
>>>> The final par
401 - 500 of 1369 matches
Mail list logo
