Hi Jean-Philippe,
On 1/11/19 7:16 PM, Jean-Philippe Brucker wrote:
> On 08/01/2019 10:26, Eric Auger wrote:
>> From: Jacob Pan
>>
>> In virtualization use case, when a guest is assigned
>> a PCI host device, protected by a virtual IOMMU on a guest,
>> the physical IOMMU must be programmed to be c
Hi Jean-Philippe,
On 1/25/19 9:39 AM, Auger Eric wrote:
> Hi Jean-Philippe,
>
> On 1/11/19 7:16 PM, Jean-Philippe Brucker wrote:
>> On 08/01/2019 10:26, Eric Auger wrote:
>>> From: Jacob Pan
>>>
>>> In virtualization use case, when a guest is assigned
>>> a PCI host device, protected by a virtua
Hi Alex,
On 1/11/19 7:43 PM, Alex Williamson wrote:
> On Tue, 8 Jan 2019 11:26:13 +0100
> Eric Auger wrote:
>
>> From: Jacob Pan
>>
>> In virtualization use case, when a guest is assigned
>> a PCI host device, protected by a virtual IOMMU on a guest,
>> the physical IOMMU must be programmed to
As the comment block in include/trace/define_trace.h says,
TRACE_INCLUDE_PATH should be a relative path to the define_trace.h
../../virt/kvm/arm is the correct relative path.
../../../virt/kvm/arm is working by coincidence because the top
Makefile adds -I$(srctree)/arch/$(SRCARCH)/include as a he
My main motivation is to get rid of crappy header search path manipulation
from Kbuild core.
Before that, I want to finish as many cleanup works as possible.
If you are interested in the big picture of this work,
the full patch set is available at:
git://git.kernel.org/pub/scm/linux/kernel/git/m
The header search path -I. in kernel Makefiles is very suspicious;
it allows the compiler to search for headers in the top of $(srctree),
where obviously no header file exists.
I was able to build without these extra header search paths.
Signed-off-by: Masahiro Yamada
---
arch/arm/kvm/Makefile
Currently, the Kbuild core manipulates header search paths in a crazy
way [1].
To fix this mess, I want all Makefiles to add explicit $(srctree)/ to
the search paths in the srctree. Some Makefiles are already written in
that way, but not all. The goal of this work is to make the notation
consisten
This series fixes a number of issues:
- When powering on and resetting VCPUs, we can be preempted in the
middle which can lead to guest system register corruption.
- We were missing support for PSCI ON_PENDING when multiple VCPUs try
to turn on a target VCPU at the same time.
- Powering
Resetting the VCPU state modifies the system register state in memory,
but this may interact with vcpu_load/vcpu_put if running with preemption
disabled, which in turn may lead to corrupted system register state.
Address this by disabling preemption and doing put/load if required
around the reset
From: Marc Zyngier
Failing to properly reset system registers is pretty bad. But not
quite as bad as bringing the whole machine down... So warn loudly,
but slightly more gracefully.
Signed-off-by: Marc Zyngier
Acked-by: Christoffer Dall
---
arch/arm/kvm/coproc.c | 4 ++--
arch/arm64/kvm/s
We are currently not implementing the PSCI spec completely, as we do not
take handle the situation where two VCPUs are attempting to turn on a
third VCPU at the same time. The PSCI implementation should make sure
that only one requesting VCPU wins the race and that the other receives
PSCI_RET_ON_P
From: Marc Zyngier
The current kvm_psci_vcpu_on implementation will directly try to
manipulate the state of the VCPU to reset it. However, since this is
not done on the thread that runs the VCPU, we can end up in a strangely
corrupted state when the source and target VCPUs are running at the sam
To avoid a race between turning VCPUs off and turning them on, make sure
that only the VCPU threat itself turns off the VCPU. When other threads
want to turn of a VCPU, they now do this via a request.
Signed-off-by: Christoffer Dall
Acked-by: Marc Zyngier
---
arch/arm/include/asm/kvm_host.h
Hi James,
Thanks for looking into this.
On Thu, 24 Jan 2019 19:01:57 +,
James Morse wrote:
>
> Hi guys,
>
> (CC: +Suzuki)
>
> On 24/01/2019 14:00, Christoffer Dall wrote:
> > In preparation for nested virtualization where we are going to have more
> > than a single VMID per VM, let's fact
On 25/01/2019 08:55, Auger Eric wrote:
> Hi Jean-Philippe,
>
> On 1/25/19 9:39 AM, Auger Eric wrote:
>> Hi Jean-Philippe,
>>
>> On 1/11/19 7:16 PM, Jean-Philippe Brucker wrote:
>>> On 08/01/2019 10:26, Eric Auger wrote:
From: Jacob Pan
In virtualization use case, when a guest is as
Hi Christoffer,
On 24/01/2019 14:00, Christoffer Dall wrote:
> In preparation for nested virtualization where we are going to have more
> than a single VMID per VM, let's factor out the VMID data into a
> separate VMID data structure and change the VMID allocator to operate on
> this new structure
On Fri, Jan 25, 2019 at 04:57:27PM +0900, Masahiro Yamada wrote:
> My main motivation is to get rid of crappy header search path manipulation
> from Kbuild core.
>
> Before that, I want to finish as many cleanup works as possible.
>
> If you are interested in the big picture of this work,
> the f
Hi,
I'm wondering, could this patch be split in two? One for the
introduction of kvm_arm_timer_read_sysreg() +
kvm_arm_timer_write_sysreg() and the other for merging the handlers into
a single function?
On 24/01/2019 14:00, Christoffer Dall wrote:
> From: Andre Przywara
>
> At the moment we h
On 1/24/19 1:11 PM, Andrew Jones wrote:
On Thu, Jan 24, 2019 at 11:16:28AM +, Alexandru Elisei wrote:
Add support for discovering the ns16550a UART from the device tree. This
particular UART model is emulated by kvmtool.
Signed-off-by: Alexandru Elisei
---
lib/arm/io.c | 18 +++
On 1/24/19 1:01 PM, Andrew Jones wrote:
On Thu, Jan 24, 2019 at 11:16:31AM +, Alexandru Elisei wrote:
A new function psci_system_off() is added which implements the PSCI
SYSTEM_OFF function. A call causes the hypervisor to terminate the virtual
machine.
Consumers for the function will be
On 1/24/19 1:00 PM, Andrew Jones wrote:
> On Thu, Jan 24, 2019 at 11:16:32AM +, Alexandru Elisei wrote:
>> On arm and arm64, kvm-unit-tests uses the QEMU chr-testdev device to shut
>> down the virtual machine at the end of a test. The function
>> psci_system_off() provides another mechanism f
On Fri, Jan 25, 2019 at 02:08:45PM +, Alexandru Elisei wrote:
>
> On 1/24/19 1:01 PM, Andrew Jones wrote:
> > On Thu, Jan 24, 2019 at 11:16:31AM +, Alexandru Elisei wrote:
> > > A new function psci_system_off() is added which implements the PSCI
> > > SYSTEM_OFF function. A call causes the
On Tue, 22 Jan 2019 15:17:14 +
Dave Martin wrote:
Hi Dave,
thanks for having a look!
> On Mon, Jan 07, 2019 at 12:05:36PM +, Andre Przywara wrote:
> > KVM implements the firmware interface for mitigating cache
> > speculation vulnerabilities. Guests may use this interface to
> > ensure
On 1/24/19 1:35 PM, Andrew Jones wrote:
> On Thu, Jan 24, 2019 at 02:00:20PM +0100, Andrew Jones wrote:
>> [..]
>> chr_testdev_init() ensures vcon is NULL if it fails to initialize.
>> chr_testdev_exit() immediately returns if vcon is NULL. This was
>> done by design to allow fallback exits to be
Hi,
this is a try to address Dave's comments concerning the readability of
the compatiblitiy check of the protection levels.
If picks up the idea of creating a linear scale, where smaller values
mean less protection. Originally the suggestion was to use a signed
encoding, with "unknown" being 0. W
Add documentation for the newly defined firmware registers to save and
restore any vulnerability migitation status.
Signed-off-by: Andre Przywara
---
Documentation/virtual/kvm/arm/psci.txt | 21 +
1 file changed, 21 insertions(+)
diff --git a/Documentation/virtual/kvm/arm/ps
KVM implements the firmware interface for mitigating cache speculation
vulnerabilities. Guests may use this interface to ensure mitigation is
active.
If we want to migrate such a guest to a host with a different support
level for those workarounds, migration might need to fail, to ensure that
criti
On Fri, Jan 25, 2019 at 02:56:30PM +, Alexandru Elisei wrote:
>
> On 1/24/19 1:35 PM, Andrew Jones wrote:
> > On Thu, Jan 24, 2019 at 02:00:20PM +0100, Andrew Jones wrote:
> >> [..]
> >> chr_testdev_init() ensures vcon is NULL if it fails to initialize.
> >> chr_testdev_exit() immediately retu
When loading a firmware instead of a kernel, we can still pass on any
*user-provided* command line, as /chosen/bootargs is a generic device tree
feature. We just need to make sure to not pass our mangled-for-Linux
version.
This allows to run "firmware" images which make use of a command line,
stil
On 1/25/19 3:31 PM, Andrew Jones wrote:
> On Fri, Jan 25, 2019 at 02:56:30PM +, Alexandru Elisei wrote:
>> On 1/24/19 1:35 PM, Andrew Jones wrote:
>>> On Thu, Jan 24, 2019 at 02:00:20PM +0100, Andrew Jones wrote:
[..]
chr_testdev_init() ensures vcon is NULL if it fails to initialize
On Fri, Jan 25, 2019 at 04:31:37PM +0100, Andrew Jones wrote:
> On Fri, Jan 25, 2019 at 02:56:30PM +, Alexandru Elisei wrote:
> >
> > On 1/24/19 1:35 PM, Andrew Jones wrote:
> > > On Thu, Jan 24, 2019 at 02:00:20PM +0100, Andrew Jones wrote:
> > >> [..]
> > >> chr_testdev_init() ensures vcon i
On Fri, 25 Jan 2019 17:05:45 +0100
Andrew Jones wrote:
Hi,
> On Fri, Jan 25, 2019 at 04:31:37PM +0100, Andrew Jones wrote:
> > On Fri, Jan 25, 2019 at 02:56:30PM +, Alexandru Elisei wrote:
> > >
> > > On 1/24/19 1:35 PM, Andrew Jones wrote:
> > > > On Thu, Jan 24, 2019 at 02:00:20PM +01
On 1/24/19 12:37 PM, Andrew Jones wrote:
> On Thu, Jan 24, 2019 at 11:59:43AM +, Andre Przywara wrote:
>> On Thu, 24 Jan 2019 11:16:29 +
>> Alexandru Elisei wrote:
>>
>>> A warning is displayed if uart0_base is different from what the code
>>> expects qemu to generate for the pl011 UART in
On 1/25/19 4:14 PM, Andre Przywara wrote:
> On Fri, 25 Jan 2019 17:05:45 +0100
> Andrew Jones wrote:
>
> Hi,
>
>> On Fri, Jan 25, 2019 at 04:31:37PM +0100, Andrew Jones wrote:
>>> On Fri, Jan 25, 2019 at 02:56:30PM +, Alexandru Elisei wrote:
On 1/24/19 1:35 PM, Andrew Jones wrote:
>>>
On Fri, Jan 25, 2019 at 04:36:13PM +, Alexandru Elisei wrote:
> On 1/24/19 12:37 PM, Andrew Jones wrote:
> > On Thu, Jan 24, 2019 at 11:59:43AM +, Andre Przywara wrote:
> >> On Thu, 24 Jan 2019 11:16:29 +
> >> Alexandru Elisei wrote:
> >>
> >>> A warning is displayed if uart0_base is d
Hi Alex,
On 1/11/19 10:30 PM, Alex Williamson wrote:
> On Tue, 8 Jan 2019 11:26:14 +0100
> Eric Auger wrote:
>
>> From: "Liu, Yi L"
>>
>> In any virtualization use case, when the first translation stage
>> is "owned" by the guest OS, the host IOMMU driver has no knowledge
>> of caching structu
On Fri, Jan 25, 2019 at 04:44:39PM +, Alexandru Elisei wrote:
> On 1/25/19 4:14 PM, Andre Przywara wrote:
> > On Fri, 25 Jan 2019 17:05:45 +0100
> > Andrew Jones wrote:
> >
> > Hi,
> >
> >> On Fri, Jan 25, 2019 at 04:31:37PM +0100, Andrew Jones wrote:
> >>> On Fri, Jan 25, 2019 at 02:56:30PM +
Hi Alex,
On 1/11/19 11:44 PM, Alex Williamson wrote:
> On Tue, 8 Jan 2019 11:26:15 +0100
> Eric Auger wrote:
>
>> On ARM, MSI are translated by the SMMU. An IOVA is allocated
>> for each MSI doorbell. If both the host and the guest are exposed
>> with SMMUs, we end up with 2 different IOVAs allo
As I found myself using kvmtool more often in the last weeks, I got more
and more annoyed by some smaller "ticks" that kvmtool shows.
So this is an attempt to post various smaller fixes I gathered up over
the years, but never found worth enough to send out:
- drop unnecessarily detailed debug out
The DT spec describes the stdout-path property in the /chosen node to
contain the DT path for a default device usable for outputting characters.
The Linux kernel uses this for earlycon (without further parameters),
other DT users might rely on this as well.
Add a property containing the path to ou
On every build we report the kvmtool "version" number, which isn't
meaningful at all anymore.
Remove the line from the KVMTOOLS-VERSION-GEN script to drop a
pointless message.
Signed-off-by: Andre Przywara
---
util/KVMTOOLS-VERSION-GEN | 1 -
1 file changed, 1 deletion(-)
diff --git a/util/KVM
"make -s" suppresses normal output, just shows warnings and errors.
But since we explicitly override the make output with our fancy concise
version, we miss out on this feature.
Do as the kernel does and explicitly suppress every normal output when -s
is given. This helps to spot warnings that scr
At the moment kvmtool always tries to instantiate a virtual GICv2 for
the guest, and fails with some scary error message if that doesn't work.
The user has then to manually specify "--irqchip=gicv3", which is not
really obvious.
With the advent of more GICv3-only machines, let's try to be more
clev
For whatever reason on ARM/arm64 machines kvmtool greets us with quite
some elaborate messages:
Info: Loaded kernel to 0x8008 (18704896 bytes)
Info: Placing fdt at 0x8fe0 - 0x8fff
Info: virtio-mmio.devices=0x200@0x1:36
Info: virtio-mmio.devices=0x200@0x10200:37
Info: vir
The KVM ioctls mostly just return -1 in the error case, leaving the
actual error code in errno.
Change the output of the PMU error message to actually print this error
code instead of the generic -1.
Signed-off-by: Andre Przywara
---
arm/pmu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(
Hi Alex,
On 1/11/19 11:44 PM, Alex Williamson wrote:
> On Tue, 8 Jan 2019 11:26:15 +0100
> Eric Auger wrote:
>
>> On ARM, MSI are translated by the SMMU. An IOVA is allocated
>> for each MSI doorbell. If both the host and the guest are exposed
>> with SMMUs, we end up with 2 different IOVAs all
On 08/01/2019 10:26, Eric Auger wrote:
To allow nested stage support, we need to store both
stage 1 and stage 2 configurations (and remove the former
union).
arm_smmu_write_strtab_ent() is modified to write both stage
fields in the STE.
We add a nested_bypass field to the S1 configuration as th
47 matches
Mail list logo
