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 op
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
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?
T
On Mon, Feb 25, 2013 at 02:21:17PM +0200, Gleb Natapov wrote:
> On Mon, Feb 25, 2013 at 12:18:27PM +, Marc Zyngier wrote:
> > Russell, Marcelo, Gleb,
> >
> > Commit 89f8833 (Merge tag 'kvm-3.9-1' of
> > git://git.kernel.org/pub/scm/virt/kvm/kvm) broke KVM/ARM. Nothing
> > fundamental, just ann
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
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
> copy_t
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
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
> wrote:
> > On 16 September 2013 19:41, Olof Johansson wrote:
> >> Hi,
> >>
> >> On Wed, Sep 11, 2013 at 6:50 PM, Christoffer Dall
> >> wrote:
> >>> On Wed, S
On Tue, Jul 01, 2014 at 05:42:42PM +0100, Måns Rullgård wrote:
> Russell King 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 the "mov pc, lr"
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 reques
On Sat, Sep 15, 2012 at 11:34:36AM -0400, Christoffer Dall wrote:
> From: Marc Zyngier
>
> 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 accessor (get_me
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 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
> >
> > If we have level interrupts already programmed to fire on a vcpu,
> > there is no reason to kick it after injecting a new interrupt,
> >
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 the
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: M
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 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:
> + kvm_psci_vcpu_o
On Fri, Jan 11, 2013 at 12:33:15PM -0500, Christoffer Dall wrote:
> On Fri, Jan 11, 2013 at 12:24 PM, Marc Zyngier 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_p
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 througho
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 b
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 de
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 argumen
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
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
> wrote:
> > On Tue, Jan 08, 2013 at 01:39:31PM -0500, Christoffer Dall wrote:
> >> + /*
> >> + * Check whether this vcpu requi
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 Wed, Jan 16, 2013 at 01:26:01PM +1030, Rusty Russell wrote:
> Christoffer Dall writes:
>
> > On Mon, Jan 14, 2013 at 11:24 AM, Russell King - ARM Linux
> > wrote:
> >> On Tue, Jan 08, 2013 at 01:38:55PM -0500, Christoffer Dall wrote:
> >>> + /* -E
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 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 option
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
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
32 matches
Mail list logo
