On Tue, Nov 03, 2015 at 11:33:17AM -0500, Christopher Covington wrote:
> > diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
> > index a2e16f9..d126bd4 100644
> > --- a/arch/arm/Kconfig.debug
> > +++ b/arch/arm/Kconfig.debug
> > @@ -1155,6 +1155,28 @@ choice
> > This
On Thu, Aug 27, 2015 at 03:05:47PM +0100, Marc Zyngier wrote:
When injecting a fault into a 32bit guest, it seems rather idiotic
to also inject a 64bit fault that is only going to corrupt the
guest state, and lead to a situation where we restore an illegal
context.
Just fix the stupid bug
On Thu, Feb 19, 2015 at 05:56:45AM -0500, Sasha Levin wrote:
What inconvenience is caused by having it sit inside the kernel tree
beyond an increased requirement in disk space?
I've come across this problem with the perf tools - luckily, the perf
tools allow the source to be exported from the
On Tue, Sep 23, 2014 at 04:46:06PM +0200, Antonios Motakis wrote:
As already demonstrated with PCI [1] and the platform bus [2], a
driver_override property in sysfs can be used to bypass the id matching
of a device to a AMBA driver. This can be used by VFIO to bind to any AMBA
device requested
On Tue, Jul 01, 2014 at 05:42:42PM +0100, Måns Rullgård wrote:
Russell King rmk+ker...@arm.linux.org.uk writes:
ARMv6 and greater introduced a new instruction (bx) which can be used
to return from function calls. Recent CPUs perform better when the
bx lr instruction is used rather than
On Mon, Sep 23, 2013 at 12:59:44PM -0700, Olof Johansson wrote:
Hi Christoffer,
On Mon, Sep 16, 2013 at 8:47 PM, Christoffer Dall
christoffer.d...@linaro.org wrote:
On 16 September 2013 19:41, Olof Johansson o...@lixom.net wrote:
Hi,
On Wed, Sep 11, 2013 at 6:50 PM, Christoffer Dall
On Wed, Aug 21, 2013 at 05:09:39PM -0700, Christoffer Dall wrote:
Linaro is going to host a bi-weekly sync-up call for technical issues on
KVM/ARM development. The KVM 32-bit and 64-bit maintainers as well as
the QEMU ARM maintainer will typically be on the call.
The first call will be held
On Wed, May 22, 2013 at 11:25:36AM +0200, Arnd Bergmann wrote:
Given the most commonly used functions and a couple of architectures
I'm familiar with, these are the ones that currently call might_fault()
x86-32 x86-64 arm arm64 powerpc s390generic
On Fri, Apr 05, 2013 at 10:08:04AM +0100, Marc Zyngier wrote:
On 04/04/13 23:10, Geoff Levand wrote:
Hi,
On Tue, 2013-04-02 at 14:25 +0100, Marc Zyngier wrote:
+ @ Jump to the trampoline page
+ ldr r2, =#PAGE_MASK
+ adr r3, target
+ bic r3, r3, r2
+ ldr r2,
On Wed, Jan 16, 2013 at 01:26:01PM +1030, Rusty Russell wrote:
Christoffer Dall c.d...@virtualopensystems.com writes:
On Mon, Jan 14, 2013 at 11:24 AM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Tue, Jan 08, 2013 at 01:38:55PM -0500, Christoffer Dall wrote
If you're going to bother commenting on a big long email, please
_CHOP OUT_ content which is not relevant to your reply. I paged down 5
pages, hit end, paged up, found no comment from you, so I'm not going to
bother reading anything further in this message.
Help your readers to read your email.
On Mon, Jan 14, 2013 at 01:07:56PM +0200, Gleb Natapov wrote:
Ah, of course. This is ident map so by definition it cannot map phys
addresses above 4G. And since __virt_to_phys() suppose to work only on
ident map it's OK to returns unsigned long.
Let's get this right... the lack of correct
On Tue, Jan 08, 2013 at 01:38:48PM -0500, Christoffer Dall wrote:
+ pr_info(Setting up static %sidentity map for 0x%llx - 0x%llx\n,
+ prot ? HYP : ,
+ (long long)addr, (long long)end);
There's no point using 0x%llx and casting to 64-bit longs if the arguments
are
On Tue, Jan 08, 2013 at 01:38:55PM -0500, Christoffer Dall wrote:
+ /* -ENOENT for unknown features, -EINVAL for invalid combinations. */
+ for (i = 0; i sizeof(init-features)*8; i++) {
+ if (init-features[i / 32] (1 (i % 32))) {
Isn't this an open-coded version of
On Tue, Jan 08, 2013 at 01:39:31PM -0500, Christoffer Dall wrote:
+ /*
+ * Check whether this vcpu requires the cache to be flushed on
+ * this physical CPU. This is a consequence of doing dcache
+ * operations by set/way on this vcpu. We do it here to be in
+ * a
On Tue, Jan 08, 2013 at 01:40:05PM -0500, Christoffer Dall wrote:
diff --git a/arch/arm/kvm/decode.c b/arch/arm/kvm/decode.c
new file mode 100644
index 000..469cf14
--- /dev/null
+++ b/arch/arm/kvm/decode.c
@@ -0,0 +1,462 @@
+/*
+ * Copyright (C) 2012 - Virtual Open Systems and
On Mon, Jan 14, 2013 at 12:38:17PM -0500, Christoffer Dall wrote:
On Mon, Jan 14, 2013 at 11:36 AM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Tue, Jan 08, 2013 at 01:39:31PM -0500, Christoffer Dall wrote:
+ /*
+ * Check whether this vcpu requires the cache
On Mon, Jan 14, 2013 at 01:25:39PM -0500, Christoffer Dall wrote:
However, unifying all instruction decoding within arch/arm is quite
the heavy task, and requires agreeing on some canonical API that
people can live with and it will likely take a long time. I seem to
recall there were also
On Thu, Jan 10, 2013 at 04:06:45PM +, Marc Zyngier wrote:
+int kvm_psci_call(struct kvm_vcpu *vcpu)
+{
+ unsigned long psci_fn = *vcpu_reg(vcpu, 0) ~((u32) 0);
+ unsigned long val;
+
+ switch (psci_fn) {
+ case KVM_PSCI_FN_CPU_OFF:
+
On Fri, Jan 11, 2013 at 12:33:15PM -0500, Christoffer Dall wrote:
On Fri, Jan 11, 2013 at 12:24 PM, Marc Zyngier marc.zyng...@arm.com wrote:
On 11/01/13 17:12, Russell King - ARM Linux wrote:
On Thu, Jan 10, 2013 at 04:06:45PM +, Marc Zyngier wrote:
+int kvm_psci_call(struct kvm_vcpu
On Fri, Jan 11, 2013 at 12:48:45PM -0500, Christoffer Dall wrote:
again, that's why I suggest returning a bool instead. You just said
it: it's a basic handled/not-handled state. Why do you want to return
-EINVAL if that's not propogated anywhere?
We have a well established principle throughout
On Fri, Jan 11, 2013 at 01:07:31PM -0500, Christoffer Dall wrote:
The _very_ good reason here, is that we have two success cases: return
to guest and return to user space. As I said, we can save this state
in another bit somewhere and change all the KVM/ARM code to do so, but
the KVM guys back
On Wed, Dec 05, 2012 at 10:43:58AM +, Will Deacon wrote:
On Sat, Nov 10, 2012 at 03:45:39PM +, Christoffer Dall wrote:
From: Marc Zyngier marc.zyng...@arm.com
If we have level interrupts already programmed to fire on a vcpu,
there is no reason to kick it after injecting a new
For the sake of public education, let me rewrite this patch a bit to
illustrate why atomic_t's are bad, and then people can review this
instead.
Every change I've made here is functionally equivalent to the behaviour
of the atomic type; I have not added any new bugs here that aren't
present in
On Wed, Dec 05, 2012 at 12:17:57PM +, Marc Zyngier wrote:
On 05/12/12 10:58, Russell King - ARM Linux wrote:
On Wed, Dec 05, 2012 at 10:43:58AM +, Will Deacon wrote:
On Sat, Nov 10, 2012 at 03:45:39PM +, Christoffer Dall wrote:
From: Marc Zyngier marc.zyng...@arm.com
If we
On Wed, Dec 05, 2012 at 01:40:24PM +, Marc Zyngier wrote:
Admittedly, the whole sequence should be rewritten to be clearer. What
it does is If we're running a guest and there is no active interrupt,
then kick the guest.
On the whole this entire thing should be written clearer; from the
On Mon, Oct 01, 2012 at 01:53:26PM +0100, Dave Martin wrote:
A good starting point would be load/store emulation as this seems to be a
common theme, and we would need a credible deployment for any new
framework so that we know it's fit for purpose.
Probably not actually, that code is written
On Sat, Sep 15, 2012 at 11:34:36AM -0400, Christoffer Dall wrote:
From: Marc Zyngier marc.zyng...@arm.com
The KVM hypervisor mmu code requires access to the mem_type prot_pte
field when setting up page tables pointing to a device. Unfortunately,
the mem_type structure is opaque.
Add an
On Wed, Feb 29, 2012 at 12:58:26PM +, Dave Martin wrote:
On Wed, Feb 29, 2012 at 09:56:02AM +, Ian Campbell wrote:
On Wed, 2012-02-29 at 09:34 +, Dave Martin wrote:
On Tue, Feb 28, 2012 at 12:28:29PM +, Stefano Stabellini wrote:
I don't have a very strong opinion on
On Wed, Feb 29, 2012 at 02:44:24PM +, Ian Campbell wrote:
If you need a specific register, this means that you must set up that
register explicitly inside the asm if you want a guarantee that the
code will work:
asm volatile (
movw r12, %[hvc_num]\n\t
Is gcc
On Thu, Mar 01, 2012 at 10:27:02AM +, Dave Martin wrote:
So, where there's a compelling reason to inline these things, we can use
the existing techniques if we're alert to the risks. But in cases where
there isn't a compelling reason, aren't we just inviting fragility
unnecessarily?
The
31 matches
Mail list logo
