Hi Peter,
On 06/20/2018 03:20 PM, Peter Maydell wrote:
> The final part of the Memory Protection Controller we need to
> implement is actually using the BLK_LUT data programmed by the
> guest to determine whether to block the transaction or not.
>
> Since this means we now change transaction mapp
Hi Peter,
On 06/20/2018 03:20 PM, Peter Maydell wrote:
> Implement the missing registers for the TZ MPC.
>
> Signed-off-by: Peter Maydell
> ---
> include/hw/misc/tz-mpc.h | 10 +++
> hw/misc/tz-mpc.c | 142 +--
> 2 files changed, 148 insertions(+), 4
Hi Peter,
On 06/20/2018 04:06 PM, Peter Maydell wrote:
> On 20 June 2018 at 15:03, Auger Eric wrote:
>> Hi Peter,
>> On 06/20/2018 03:57 PM, Peter Maydell wrote:
>>> On 15 June 2018 at 15:28, Eric Auger wrote:
>>>> commit b357bf6023a948cf6a9472f07a1b0caac0
Hi Peter,
On 06/20/2018 03:57 PM, Peter Maydell wrote:
> On 15 June 2018 at 15:28, Eric Auger wrote:
>> commit b357bf6023a948cf6a9472f07a1b0caac0e4f8e8
>> Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm
>>
>> Signed-off-by: Eric Auger
>
> What's 4.18-rc0? The upstream kernel d
Hi Laszlo,
On 06/19/2018 09:02 PM, Ard Biesheuvel wrote:
> On 19 June 2018 at 20:53, Laszlo Ersek wrote:
>> Hi Eric,
>>
>> sorry about the late followup. I have one question (mainly for Ard):
>>
>> On 06/15/18 16:28, Eric Auger wrote:
>>> This patch allows the creation of a GICv3 node with 1 or 2
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
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 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 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 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 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 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/04/2018 05:29 PM, Peter Maydell wrote:
> The final part of the Memory Protection Controller we need to
> implement is actually using the BLK_LUT data programmed by the
> guest to determine whether to block the transaction or not.
>
> Since this means we now change transaction mapp
Hi Peter,
On 06/04/2018 05:29 PM, Peter Maydell wrote:
> Implement the missing registers for the TZ MPC.
>
> Signed-off-by: Peter Maydell
> ---
> include/hw/misc/tz-mpc.h | 10 +++
> hw/misc/tz-mpc.c | 137 ++-
> 2 files changed, 144 insertions(+), 3
Hi Peter,
On 06/04/2018 05:29 PM, Peter Maydell wrote:
> Implement the Arm TrustZone Memory Protection Controller, which sits
> in front of RAM and allows secure software to configure it to either
> pass through or reject transactions.
>
> We implement the MPC as a QEMU IOMMU, which will direct t
Hi Peter,
On 06/04/2018 05:29 PM, Peter Maydell wrote:
> The MPC is guest-configurable for whether blocked accesses:
> * should be RAZ/WI or cause a bus error
> * should generate an interrupt or not
>
> Implement this behaviour in the blocked-access handlers.
>
> Signed-off-by: Peter Maydell
>
Hi Peter,
On 06/04/2018 05:29 PM, Peter Maydell wrote:
> Implement the missing registers for the TZ MPC.
>
> Signed-off-by: Peter Maydell
> ---
> include/hw/misc/tz-mpc.h | 10 +++
> hw/misc/tz-mpc.c | 137 ++-
> 2 files changed, 144 insertions(+), 3
Hi Peter,
On 06/04/2018 05:29 PM, Peter Maydell wrote:
> Implement the missing registers for the TZ MPC.
>
> Signed-off-by: Peter Maydell
> ---
> include/hw/misc/tz-mpc.h | 10 +++
> hw/misc/tz-mpc.c | 137 ++-
> 2 files changed, 144 insertions(+), 3
Hi Peter,
On 06/04/2018 05:29 PM, Peter Maydell wrote:
> Implement the Arm TrustZone Memory Protection Controller, which sits
> in front of RAM and allows secure software to configure it to either
> pass through or reject transactions.
>
> We implement the MPC as a QEMU IOMMU, which will direct tr
Hi Drew,
On 06/14/2018 03:32 PM, Andrew Jones wrote:
> On Wed, Jun 13, 2018 at 10:48:37AM +0200, 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 accele
Hi Drew,
On 06/14/2018 03:39 PM, Andrew Jones wrote:
> On Wed, Jun 13, 2018 at 10:48:38AM +0200, Eric Auger wrote:
>> Let's check if KVM_VGIC_V3_ADDR_TYPE_REDIST_REGION is supported.
>> If not, we check the number of redist region is equal to 1 and use the
>> legacy KVM_VGIC_V3_ADDR_TYPE_REDIST at
Hi Dan, Laszlo,
On 06/14/2018 10:59 AM, Daniel P. Berrangé wrote:
> On Thu, Jun 14, 2018 at 10:56:20AM +0200, Laszlo Ersek wrote:
>> Hi Eric,
>>
>> On 06/14/18 08:27, Auger Eric wrote:
>>> Hi Laszlo,
>>>
>>> On 06/13/2018 11:05 PM, Laszlo Ersek
Hi Laszlo,
On 06/14/2018 10:56 AM, Laszlo Ersek wrote:
> Hi Eric,
>
> On 06/14/18 08:27, Auger Eric wrote:
>> Hi Laszlo,
>>
>> On 06/13/2018 11:05 PM, Laszlo Ersek wrote:
>>> On 06/13/18 10:48, Eric Auger wrote:
>>>
>>>> PATCH: merge o
Hi Peter,
On 06/14/2018 03:52 AM, Peter Xu wrote:
> On Wed, Jun 13, 2018 at 04:20:34PM +0200, Auger Eric wrote:
>> Hi Paolo,
>>
>> On 06/13/2018 03:53 PM, Paolo Bonzini wrote:
>>> On 13/06/2018 15:44, Auger Eric wrote:
>>>>> Queuing this patch. I&
Hi Laszlo,
On 06/13/2018 11:05 PM, Laszlo Ersek wrote:
> On 06/13/18 10:48, Eric Auger wrote:
>
>> PATCH: merge of ECAM and VCPU extension
>> - Laszlo reviewed the ECAM changes but I dropped his R-b
>> due to the squash
>
> Was there any particular reason why the previous patch set (with only
Hi Paolo,
On 06/13/2018 03:53 PM, Paolo Bonzini wrote:
> On 13/06/2018 15:44, Auger Eric wrote:
>>> Queuing this patch. I'm not sure how I missed this, I have actually
>>> tested it with SMMU.
>> no problem. Strange also I was the only one facing the issue.
&
Hi Paolo,
On 06/13/2018 03:36 PM, Paolo Bonzini wrote:
> On 13/06/2018 15:19, 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
Hi Paolo,
On 06/13/2018 11:56 AM, Paolo Bonzini wrote:
> On 12/06/2018 21:05, 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
Hi,
On 06/13/2018 10:05 AM, Markus Armbruster wrote:
> Peter Xu writes:
>
>> Replace existing trace_vtd_err() with error_report_once() then stderr
>> will capture something if any of the error happens, meanwhile we don't
>> suffer from any DDOS. Then remove the trace point. Since at it,
>> prov
Hi Peter,
On 06/13/2018 05:15 AM, Peter Xu wrote:
> On Tue, Jun 12, 2018 at 09:05:25PM +0200, 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 a
Hi,
On 06/08/2018 08:57 AM, Eric Auger wrote:
> From: Jia He
>
> In case the STE's config is "Bypass" we currently don't set the
> IOMMUTLBEntry perm flags and the access does not succeed. Also
> if the config is 0b0xx (Aborted/Reserved), decode_ste and
> smmuv3_decode_config currently returns -
Hi Jia,
On 06/07/2018 03:38 PM, Jia He wrote:
> There is an exception when I passes iommu.passthrough=1 to guest's
> kernel boot parameter(host QDF2400 kernel 4.17, guest kernel 4.14).
> The guest will be hang when booting up.
>
> When guest smmu is in passthrough mode, entry.perm will not be ass
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,
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,
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 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 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 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 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
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 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
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 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 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 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/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,
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 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/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/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 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 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:
> 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:
> 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 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:
> 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 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 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 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 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/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
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/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
>>> -
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 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/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 Laszlo,
On 05/24/2018 03:59 PM, 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 break a guest which is just Linux loaded not via
firmware which is an aarch32 kernel
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 the s->gicd_ipriority & friends.
>> With that change, is it supposed to contain only the states of SPIs or
>> contain the RAZ st
Hi Peter, Laszlo,
On 05/24/2018 03:07 PM, 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 break a guest which is just Linux loaded not via
>>> firmware which is an aarch32 kernel without LPAE support?
>>
>> Does such
Hi Shannon,
On 05/24/2018 11:20 AM, Shannon Zhao wrote:
>
>
> On 2018/5/24 17:04, Auger Eric wrote:
>> Hi Shannon,
>>
>> On 05/23/2018 05:53 AM, Shannon Zhao wrote:
>>> While we skip the GIC_INTERNAL irqs, we don't change the register offset
>>>
Hi Shannon,
On 05/23/2018 05:53 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 bank
Hi,
On 05/23/2018 10:52 PM, Laszlo Ersek wrote:
> On 05/23/18 22:40, Auger Eric wrote:
>> On 05/23/2018 07:45 PM, Laszlo Ersek wrote:
>
>>> Regarding the second patch, I do believe we need "more sophistication"
>>> there. For example, I guess it could be
Hi Laszlo,
On 05/23/2018 07:45 PM, Laszlo Ersek wrote:
> Hi Eric,
>
> On 05/23/18 18:03, Eric Auger wrote:
>> Current Machvirt PCI host controller's ECAM region is 16MB large.
>> This limits the number of PCIe buses to 16.
>>
>> PC/Q35 machines have a 256MB region allowing up to 256 buses.
>> Thi
ate that dependency anyways as well as
eliminate, anyway?
> separate arch CPU reset parts from arm_load_kernel() into CPU
> itself, but that refactoring that I probably would have to do
> anyways later for CPU hotplug to work.
may deserve some rewording.
>
> Reported-by: Auger Eric
Hi,
On 05/10/2018 07:45 PM, Peter Maydell wrote:
> From: Igor Mammedov
>
> load_dtb() depends on arm_load_kernel() to figure out place
> in RAM where it should be loaded, but it's not required for
> arm_load_kernel() to work. Sometimes it's neccesary for
> devices added with -device/device_add t
On 05/22/2018 04:19 PM, Peter Maydell wrote:
> On 22 May 2018 at 15:11, Auger Eric wrote:
>> Hi Peter,
>>
>> On 05/22/2018 03:22 PM, Peter Maydell wrote:
>>> How many substream IDs do we expect to see in practice?
>>
>> Spec says max 20 bits, matching
Hi Peter,
On 05/22/2018 03:22 PM, Peter Maydell wrote:
> On 22 May 2018 at 13:58, Auger Eric wrote:
>> Hi Peter,
>> On 05/21/2018 04:03 PM, Peter Maydell wrote:
>>> If an IOMMU supports mappings that care about the memory
>>> transaction attributes, then it n
Hi Peter,
On 05/21/2018 04:03 PM, Peter Maydell wrote:
> If an IOMMU supports mappings that care about the memory
> transaction attributes, then it no longer has a unique
> address -> output mapping, but more than one. We can
> represent these using an IOMMU index, analogous to TCG's
> mmu indexes.
Hi Peter,
On 05/22/2018 01:56 PM, Peter Maydell wrote:
> On 22 May 2018 at 12:30, Auger Eric wrote:
>> Hi Peter,
>>
>> On 05/21/2018 04:03 PM, Peter Maydell wrote:
>>> Implement the Arm TrustZone Memory Protection Controller, which sits
>>> in front of RAM
Hi Peter,
On 05/21/2018 04:03 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
Reviewed-by: Eric Auger
Thanks
Eric
> ---
> v2->v3 changes:
> * minor wording
Hi Peter,
On 05/21/2018 04:03 PM, Peter Maydell wrote:
> Implement the Arm TrustZone Memory Protection Controller, which sits
> in front of RAM and allows secure software to configure it to either
> pass through or reject transactions.
>
> We implement the MPC as a QEMU IOMMU, which will direct t
On 05/17/2018 10:59 AM, Peter Xu wrote:
> During the recursive page walking of IOVA page tables, some stack
> variables are constant variables and never changed during the whole page
> walking procedure. Isolate them into a struct so that we don't need to
> pass those contants down the stack eve
Hi Peter,
On 05/17/2018 10:59 AM, Peter Xu wrote:
> During IOVA page table walking, there is a special case when the PSI
> covers one whole PDE (Page Directory Entry, which contains 512 Page
> Table Entries) or more. In the past, we skip that entry and we don't
> notify the IOMMU notifiers. This
Hi Peter,
On 05/17/2018 10:59 AM, Peter Xu wrote:
> We pass in the VTDAddressSpace too. It'll be used in the follow up
> patches.
So you evetually preferred to keep .aw. I don't have a strong opinion
but maybe a small preference to v2 version.
Nevertheless
Reviewed-by: E
Hi,
On 05/18/2018 05:41 AM, Peter Xu wrote:
> On Thu, May 17, 2018 at 04:42:54PM +0200, Auger Eric wrote:
>> Hi Peter,
>>
>> On 05/04/2018 05:08 AM, Peter Xu wrote:
>>> During IOVA page table walking, there is a special case when the PSI
>>> covers one
Hi Peter,
On 05/18/2018 07:53 AM, Peter Xu wrote:
> On Thu, May 17, 2018 at 03:39:50PM +0200, Auger Eric wrote:
>> Hi Peter,
>>
>> On 05/04/2018 05:08 AM, Peter Xu wrote:
>>> For UNMAP-only IOMMU notifiers, we don't really need to walk the page
>> s/rea
Hi Peter,
On 05/18/2018 08:06 AM, Peter Xu wrote:
> On Thu, May 17, 2018 at 07:23:33PM +0200, Auger Eric wrote:
>> Hi Peter,
>>
>> On 05/04/2018 05:08 AM, Peter Xu wrote:
>>> IOMMU replay was carried out before in many use cases, e.g., context
>>> cache
Hi Peter,
On 05/18/2018 07:59 AM, Peter Xu wrote:
> On Thu, May 17, 2018 at 04:32:58PM +0200, Auger Eric wrote:
>> Hi Peter,
>>
>> On 05/04/2018 05:08 AM, Peter Xu wrote:
>>> During the recursive page walking of IOVA page tables, some stack
>>> variables a
Hi Peter,
On 05/04/2018 05:08 AM, Peter Xu wrote:
> IOMMU replay was carried out before in many use cases, e.g., context
> cache invalidations, domain flushes. We used this mechanism to sync the
> shadow page table by firstly (1) unmap the whole address space, then
> (2) walk the page table to re
Hi Peter,
On 05/04/2018 05:08 AM, Peter Xu wrote:
> During IOVA page table walking, there is a special case when the PSI
> covers one whole PDE (Page Directory Entry, which contains 512 Page
> Table Entries) or more. In the past, we skip that entry and we don't
> notify the IOMMU notifiers. This
Hi Peter,
On 05/04/2018 05:08 AM, Peter Xu wrote:
> During the recursive page walking of IOVA page tables, some stack
> variables are constant variables and never changed during the whole page
> walking procedure. Isolate them into a struct so that we don't need to
> pass those contants down the
Hi Peter,
On 05/04/2018 05:08 AM, Peter Xu wrote:
> Add a per-iommu big lock to protect IOMMU status. Currently the only
> thing to be protected is the IOTLB/context cache, since that can be
> accessed even without BQL, e.g., in IO dataplane.
As discussed together, Peter challenged per device mu
Hi Peter,
On 05/04/2018 05:08 AM, Peter Xu wrote:
> We pass in the VTDAddressSpace to replace the aw bits when doing page
> walk. The VTDAddressSpace contains the aw bits information, meanwhile
> we'll need to do something more in the follow up patches regarding to
> the address spaces.
>
> Sign
Hi Peter,
On 05/04/2018 05:08 AM, Peter Xu wrote:
> For UNMAP-only IOMMU notifiers, we don't really need to walk the page
s/really// ;-)
> tables. Fasten that procedure by skipping the page table walk. That
> should boost performance for UNMAP-only notifiers like vhost.
>
> Signed-off-by: Peter
Hi Peter,
On 05/17/2018 12:02 PM, Peter Xu wrote:
> On Thu, May 17, 2018 at 11:46:22AM +0200, Auger Eric wrote:
>> Hi Peter,
>>
>> On 05/04/2018 05:08 AM, Peter Xu wrote:
>>> That is not really necessary. Removing that node struct and put the
>>> list e
Hi Peter,
On 05/04/2018 05:08 AM, Peter Xu wrote:
> That is not really necessary. Removing that node struct and put the
> list entry directly into VTDAddressSpace. It simplfies the code a lot.
>
> Signed-off-by: Peter Xu
> ---
> include/hw/i386/intel_iommu.h | 9 ++--
> hw/i386/intel_iom
Hi Peter,
On 05/16/2018 08:31 PM, Eric Auger wrote:
> Let's cache config data to avoid fetching and parsing STE/CD
> structures on each translation. We invalidate them on data structure
> invalidation commands.
You may remember that initially I was taking a QemuMutex to protect
IOTLB/cache struct
Hi Peter,
On 05/16/2018 06:18 PM, Peter Maydell wrote:
> On 16 May 2018 at 15:33, Auger Eric wrote:
>> On 05/08/2018 06:25 PM, Peter Maydell wrote:
>>> This runs into something I found when I was implementing the Arm
>>> Memory Protection Controller -- at the point whe
Hi Philippe,
On 05/16/2018 10:01 PM, Philippe Mathieu-Daudé wrote:
> On 05/16/2018 01:23 PM, Peter Maydell wrote:
>> On 16 May 2018 at 16:16, Philippe Mathieu-Daudé wrote:
>>> Hi Eric,
>>>
>>> On 05/16/2018 03:03 PM, Eric Auger wrote:
Coverity points out that this can overflow if n > 31,
Hi Peter,
On 05/08/2018 06:25 PM, Peter Maydell wrote:
> On 1 May 2018 at 16:53, Auger Eric wrote:
>> Hi Peter,
>>
>> On 05/01/2018 05:00 PM, Peter Maydell wrote:
>>> On 1 May 2018 at 15:32, Auger Eric wrote:
>>>> Hi Peter,
>>>
901 - 1000 of 1369 matches
Mail list logo
