lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Sun, 20 May 2018 14:43:10 +0100
From:   Marc Zyngier <marc.zyngier@....com>
To:     Eric Auger <eric.auger@...hat.com>
Cc:     <eric.auger.pro@...il.com>, <linux-kernel@...r.kernel.org>,
        <kvm@...r.kernel.org>, <kvmarm@...ts.cs.columbia.edu>,
        <cdall@...nel.org>, <peter.maydell@...aro.org>,
        <andre.przywara@....com>, <drjones@...hat.com>, <wei@...hat.com>
Subject: Re: [PATCH v6 00/12] KVM: arm/arm64: Allow multiple GICv3
 redistributor regions

Hi Eric,

On Mon, 30 Apr 2018 13:48:26 +0200
Eric Auger <eric.auger@...hat.com> wrote:

> At the moment the KVM VGICv3 only supports a single redistributor
> region (whose base address is set through the GICv3 kvm device
> KVM_DEV_ARM_VGIC_GRP_ADDR/KVM_VGIC_V3_ADDR_TYPE_REDIST). There,
> all the redistributors are laid out contiguously. The size of this
> single redistributor region is not set explicitly but instead
> induced at a late stage by the number of online vcpus.
> 
> The GIC specification does not mandate all redistributors to be
> contiguous. Moreover DT and ACPI were specified so that multiple
> redistributors regions can be defined.
> 
> The current interface brings a limitation on QEMU where ARM
> virt machine available GPA holes only allowed to assign a
> redistributor region fitting a max of 123 vcpus. Overcoming this
> limitation would force either to create a new machine or relocate
> the single rdist region or allow the allocation of multiple rdist
> regions.
> 
> This series enables this last alternative. A new GICv3 KVM device
> KVM_DEV_ARM_VGIC_GRP_ADDR/KVM_VGIC_V3_ADDR_TYPE_REDIST_REGION allows
> to register individual redistributor regions whose size is defined
> explicitly. Those rdist regions then are filled by vcpu rdist frames
> according to the need. The vgic init and related base address checks
> are impacted.

I've taken this series for a test run, and noticed that it breaks
kvmtool:

<quote>
maz@...borg:~$ ./kvmtool/lkvm run -c 1 -k Image --irqchip=gicv3
  # lkvm run -k Image -m 256 -c 1 --name guest-4929
  Info: Loaded kernel to 0x80080000 (20126208 bytes)
  Info: Placing fdt at 0x8fe00000 - 0x8fffffff
  Info: virtio-mmio.devices=0x200@...0000:36

  Info: virtio-mmio.devices=0x200@...0200:37

  Info: virtio-mmio.devices=0x200@...0400:38

KVM_RUN failed: No such device or address
</quote>

Backing out the series results in a working setup.

I presume that the changes in the init has resulted in a stricter
initialization order that matches the QEMU flow, but that kvmtool
doesn't follow.

Could you please have a look at this? I'd like to have it in for 4.18,
just without regressions... ;-)

Thanks,

	M.
-- 
Without deviation from the norm, progress is not possible.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ