On Thu, Jan 31, 2019 at 06:06:09PM +0100, Andrew Jones wrote:
> On Thu, Jan 31, 2019 at 02:52:11PM +, Marc Zyngier wrote:
> > On 31/01/2019 12:57, Andrew Jones wrote:
> > > On Thu, Jan 31, 2019 at 12:51:56PM +0100, Christoffer Dall wrote:
> >
> > [...]
> >
> > >> I don't think there's
On Thu, Jan 31, 2019 at 02:57:11PM +, Andre Przywara wrote:
> On Wed, 30 Jan 2019 18:20:19 +
> Will Deacon wrote:
> > On Fri, Jan 25, 2019 at 06:07:57PM +, Andre Przywara wrote:
> > > The DT spec describes the stdout-path property in the /chosen node
> > > to contain the DT path for a
Hey Christoffer,
On 31/01/2019 08:08, Christoffer Dall wrote:
> On Thu, Jan 24, 2019 at 04:32:54PM +, James Morse wrote:
>> On systems with VHE the kernel and KVM's world-switch code run at the
>> same exception level. Code that is only used on a VHE system does not
>> need to be annotated as
On Wed, 30 Jan 2019 18:20:46 +
Will Deacon wrote:
> On Fri, Jan 25, 2019 at 06:08:01PM +, Andre Przywara wrote:
> > 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
On Wed, 30 Jan 2019 18:20:36 +
Will Deacon wrote:
> On Fri, Jan 25, 2019 at 06:07:59PM +, Andre Przywara wrote:
> > 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
>
On Thu, Jan 31, 2019 at 02:52:11PM +, Marc Zyngier wrote:
> On 31/01/2019 12:57, Andrew Jones wrote:
> > On Thu, Jan 31, 2019 at 12:51:56PM +0100, Christoffer Dall wrote:
>
> [...]
>
> >> I don't think there's anything very unconventional here.
> >
> > Normally if a thread observes a change
Hi Amit,
On 28/01/2019 06:58, Amit Daniel Kachhap wrote:
> When pointer authentication is supported, a guest may wish to use it.
> This patch adds the necessary KVM infrastructure for this to work, with
> a semi-lazy context switch of the pointer auth state.
>
> Pointer authentication feature is
Hi Amit,
On 28/01/2019 06:58, Amit Daniel Kachhap wrote:
> This feature will allow the KVM guest to allow the handling of
> pointer authentication instructions or to treat them as undefined
> if not set. It uses the existing vcpu API KVM_ARM_VCPU_INIT to
> supply this parameter instead of
Hi Amit,
On 28/01/2019 06:58, Amit Daniel Kachhap wrote:
> When restoring HCR_EL2 for the host, KVM uses HCR_HOST_VHE_FLAGS, which
> is a constant value. This works today, as the host HCR_EL2 value is
> always the same, but this will get in the way of supporting extensions
> that require HCR_EL2
Hi Amit,
On 28/01/2019 06:58, Amit Daniel Kachhap wrote:
> The keys can be switched either inside an assembly or such
> functions which do not have pointer authentication checks, so a GCC
> attribute is added to enable it.
>
> A function ptrauth_keys_store is added which is similar to existing
>
Hi Amit,
On 09/01/2019 10:13, Amit Daniel Kachhap wrote:
> On Sat, Jan 5, 2019 at 12:05 AM James Morse wrote:
>> On 18/12/2018 07:56, Amit Daniel Kachhap wrote:
>>> This feature will allow the KVM guest to allow the handling of
>>> pointer authentication instructions or to treat them as
Interrupts masked by ICC_PMR_EL1 will not be signaled to the CPU. This
means that hypervisor will not receive masked interrupts while running a
guest.
We need to make sure that all maskable interrupts are masked from the
time we call local_irq_disable() in the main run loop, and remain so
until
On Wed, 30 Jan 2019 18:20:19 +
Will Deacon wrote:
Hi,
> On Fri, Jan 25, 2019 at 06:07:57PM +, Andre Przywara wrote:
> > 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
On 31/01/2019 12:57, Andrew Jones wrote:
> On Thu, Jan 31, 2019 at 12:51:56PM +0100, Christoffer Dall wrote:
[...]
>> I don't think there's anything very unconventional here.
>
> Normally if a thread observes a change to vcpu->requests, then we ensure a
> change to some accompanying data is
On Thu, Jan 31, 2019 at 01:57:12PM +0100, Andrew Jones wrote:
> On Thu, Jan 31, 2019 at 12:51:56PM +0100, Christoffer Dall wrote:
> > On Thu, Jan 31, 2019 at 11:12:54AM +0100, Andrew Jones wrote:
> > > On Thu, Jan 31, 2019 at 08:43:53AM +0100, Christoffer Dall wrote:
> > > > On Wed, Jan 30, 2019
On Wed, Jan 23, 2019 at 06:40:08PM +, James Morse wrote:
> My SMM comment was because the CPU must jump from user-space->SMM, which
> injects
> an NMI into the kernel. The kernel's EIP must point into user-space, so
> returning from the NMI without doing the memory_failure() work puts us back
On Wed, 30 Jan 2019 18:20:28 +
Will Deacon wrote:
Hi Will,
thanks for having a look!
> On Fri, Jan 25, 2019 at 06:07:58PM +, Andre Przywara wrote:
> > "make -s" suppresses normal output, just shows warnings and errors.
> > But since we explicitly override the make output with our fancy
On Thu, 31 Jan 2019 14:07:15 +0100
Andrew Jones wrote:
> On Wed, Jan 30, 2019 at 06:20:10PM +, Will Deacon wrote:
> > On Fri, Jan 25, 2019 at 03:43:08PM +, Andre Przywara wrote:
> > > When loading a firmware instead of a kernel, we can still pass on
> > > any *user-provided* command
On 30/01/2019 18:20, Will Deacon wrote:
> On Fri, Jan 25, 2019 at 03:43:08PM +, Andre Przywara wrote:
>> 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
On Wed, Jan 23, 2019 at 06:33:02PM +, James Morse wrote:
> Was the best I had, but this trips the BUILD_BUG() too early.
> With it, x86 BUILD_BUG()s. With just the -1 the path gets pruned out, and
> there
> are no 'sdei' symbols in the object file.
>
> ...at this point, I stopped caring!
On Tue, Jan 29, 2019 at 06:48:33PM +, James Morse wrote:
> If firmware has never generated CPER records, so it has never written to void
> *error_status_address, yes.
I guess this is the bit of information I was missing.
> There seem to be two ways of doing this. This zero check implies an
We currently permit CPUs in the same system to deviate in the exact
topology of the caches, and we subsequently hide this fact from user
space by exposing a sanitised value of the cache type register CTR_EL0.
However, guests running under KVM see the bare value of CTR_EL0, which
could potentially
On SMP ARM systems, cache maintenance by set/way should only ever be
done in the context of onlining or offlining CPUs, which is typically
done by bare metal firmware and never in a virtual machine. For this
reason, we trap set/way cache maintenance operations and replace them
with conditional
While looking into whether we could report the cache geometry as 1 set
and 1 way so that the ARM kernel doesn't stall for 13 seconds at boot,
I noticed that we don't expose the sanitised version of CTR_EL0 to guests,
so I fixed that first (#1)
Since that gives us most of the groundwork for
On Wed, Jan 30, 2019 at 06:20:10PM +, Will Deacon wrote:
> On Fri, Jan 25, 2019 at 03:43:08PM +, Andre Przywara wrote:
> > 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
On 25/01/2019 11:05, Julien Thierry wrote:
> 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
On Thu, Jan 31, 2019 at 12:51:56PM +0100, Christoffer Dall wrote:
> On Thu, Jan 31, 2019 at 11:12:54AM +0100, Andrew Jones wrote:
> > On Thu, Jan 31, 2019 at 08:43:53AM +0100, Christoffer Dall wrote:
> > > On Wed, Jan 30, 2019 at 04:27:21PM +0100, Andrew Jones wrote:
> > > > On Wed, Jan 30, 2019
On Thu, Jan 31, 2019 at 11:12:54AM +0100, Andrew Jones wrote:
> On Thu, Jan 31, 2019 at 08:43:53AM +0100, Christoffer Dall wrote:
> > On Wed, Jan 30, 2019 at 04:27:21PM +0100, Andrew Jones wrote:
> > > On Wed, Jan 30, 2019 at 10:34:31AM +0100, Christoffer Dall wrote:
> > > > On Tue, Jan 29, 2019
On 30/01/2019 15:36, Andrew Jones wrote:
> On Wed, Jan 30, 2019 at 10:56:19AM +, Marc Zyngier wrote:
>> On 29/01/2019 16:33, Andrew Jones wrote:
[...]
>> If we only get halfway through resetting, then we'll get a warn splat,
>>> complete with a backtrace, for each register. Should we do
On Thu, Jan 31, 2019 at 08:43:53AM +0100, Christoffer Dall wrote:
> On Wed, Jan 30, 2019 at 04:27:21PM +0100, Andrew Jones wrote:
> > On Wed, Jan 30, 2019 at 10:34:31AM +0100, Christoffer Dall wrote:
> > > On Tue, Jan 29, 2019 at 05:03:47PM +0100, Andrew Jones wrote:
> > > > On Fri, Jan 25, 2019
Now that we have a common infrastructure for doing MMU cache
allocations, use this for mips as well.
Signed-off-by: Christoffer Dall
---
arch/mips/include/asm/kvm_host.h | 15 ++---
arch/mips/include/asm/kvm_types.h | 7
arch/mips/kvm/mips.c | 2 +-
arch/mips/kvm/mmu.c
As we have moved the mmu memory cache definitions and functions to
common code, they are exported as symols to the rest of the kernel.
Let's rename the functions and data types to have a kvm_ prefix to make
it clear where these functions belong and take this chance to rename
memory_cache to
We currently have duplicated functionality for the mmu_memory_cache used
to pre-allocate memory for the page table manipulation code which cannot
allocate memory while holding spinlocks. This functionality is
duplicated across x86, arm/arm64, and mips.
There were recently a debate of modifying
Now when we have a common mmu mmemcache implementation, we can reuse
this for arm and arm64.
The common implementation has a slightly different behavior when
allocating objects under high memory pressure; whereas the current
arm/arm64 implementation will give up and return -ENOMEM if the full
We are currently duplicating the mmu memory cache functionality quite
heavily between the architectures that support KVM. As a first step,
move the x86 implementation (which seems to have the most recently
maintained version of the mmu memory cache) to common code.
We introduce an arch-specific
On Thu, Jan 24, 2019 at 04:32:54PM +, James Morse wrote:
> On systems with VHE the kernel and KVM's world-switch code run at the
> same exception level. Code that is only used on a VHE system does not
> need to be annotated as __hyp_text as it can reside anywhere in the
> kernel text.
>
>
On Thu, Jan 24, 2019 at 04:32:55PM +, James Morse wrote:
> On systems with VHE the kernel and KVM's world-switch code run at the
> same exception level. Code that is only used on a VHE system does not
> need to be annotated as __hyp_text as it can reside anywhere in the
> kernel text.
>
>
On Thu, Jan 24, 2019 at 04:32:56PM +, James Morse wrote:
> The hyp-stub is loaded by the kernel's early startup code at EL2
> during boot, before KVM takes ownership later. The hyp-stub's
> text is part of the regular kernel text, meaning it can be kprobed.
>
> A breakpoint in the hyp-stub
38 matches
Mail list logo
