On Thu, Jun 25, 2015 at 07:38:33AM +0100, Alex Bennée wrote:
Christoffer Dall christoffer.d...@linaro.org writes:
On Fri, Jun 19, 2015 at 01:23:48PM +0100, Alex Bennée wrote:
This adds support for userspace to control the HW debug registers for
guest debug. In the debug ioctl we copy
On Wed, Jun 24, 2015 at 03:54:57PM +0100, Marc Zyngier wrote:
Userspace is allowed to set the guest's view of CNTVCT, which turns
into setting CNTVOFF for the whole VM. One thing userspace is not supposed
to do is to update that register while the guest is running. Time will
either move
Christoffer Dall christoffer.d...@linaro.org writes:
On Fri, Jun 19, 2015 at 01:23:38PM +0100, Alex Bennée wrote:
Here is V6 of the KVM Guest Debug support for arm64.
The changes are even more minimal than the last round which is
hopefully a good indication the series is ready for merging:
Christoffer Dall christoffer.d...@linaro.org writes:
On Fri, Jun 19, 2015 at 01:23:46PM +0100, Alex Bennée wrote:
This is a pre-cursor to sharing the code with the guest debug support.
This replaces the big macro that fishes data out of a fixed location
with a more general helper macro to
On Thu, Jun 25, 2015 at 07:32:27AM +0100, Alex Bennée wrote:
Christoffer Dall christoffer.d...@linaro.org writes:
On Fri, Jun 19, 2015 at 01:23:47PM +0100, Alex Bennée wrote:
This introduces a level of indirection for the debug registers. Instead
of using the sys_regs[] directly we
On 2015-06-25 11:25, Claudio Fontana wrote:
On 25.06.2015 11:10, Peter Maydell wrote:
On 25 June 2015 at 09:59, Claudio Fontana claudio.font...@huawei.com wrote:
Once the VM is created, I think QEMU should not request kvm to
change the virtual offset of the VM anymore: maybe an unexpected
On Wed, Jun 24, 2015 at 10:32:38AM +0100, Marc Zyngier wrote:
Hi Christoffer,
On 24/06/15 09:51, Christoffer Dall wrote:
On Wed, Jun 24, 2015 at 09:29:56AM +0100, Marc Zyngier wrote:
On 22/06/15 09:44, Peter Maydell wrote:
On 17 June 2015 at 10:00, Suzuki K. Poulose
On 25/06/15 13:30, Christoffer Dall wrote:
On Wed, Jun 24, 2015 at 10:32:38AM +0100, Marc Zyngier wrote:
Hi Christoffer,
On 24/06/15 09:51, Christoffer Dall wrote:
On Wed, Jun 24, 2015 at 09:29:56AM +0100, Marc Zyngier wrote:
On 22/06/15 09:44, Peter Maydell wrote:
On 17 June 2015 at 10:00,
On 22/06/15 19:04, Denis V. Lunev wrote:
From: Andrey Smetanin asmeta...@virtuozzo.com
This patch introduces Hyper-V related source code file - hyperv.c and
per vm and per vcpu hyperv context structures.
All Hyper-V MSR's and hypercall code moved into hyperv.c.
All hyper-v kvm/vcpu fields moved
On 25/06/2015 12:25, Denis V. Lunev wrote:
Paolo, Gleb,
we are very sensitive on the first patch. Could you
suggest which tree we should be based on?
For now I think that we should use
https://git.kernel.org/cgit/virt/kvm/kvm.git/
but the branch here could also matters.
You can
On 25/06/15 13:40, Marc Zyngier wrote:
On 25/06/15 13:30, Christoffer Dall wrote:
On Wed, Jun 24, 2015 at 10:32:38AM +0100, Marc Zyngier wrote:
Hi Christoffer,
On 24/06/15 09:51, Christoffer Dall wrote:
On Wed, Jun 24, 2015 at 09:29:56AM +0100, Marc Zyngier wrote:
On 22/06/15 09:44, Peter
On 25 June 2015 at 14:44, Marc Zyngier marc.zyng...@arm.com wrote:
It should always be possible to emulate a known CPU on a generic host,
and it should be able to migrate. The case we can't migrate is when we
let the guest be generic (which I guess should really be unknown, and
not generic).
Christoffer Dall christoffer.d...@linaro.org writes:
On Thu, Jun 25, 2015 at 07:38:33AM +0100, Alex Bennée wrote:
Christoffer Dall christoffer.d...@linaro.org writes:
On Fri, Jun 19, 2015 at 01:23:48PM +0100, Alex Bennée wrote:
This adds support for userspace to control the HW debug
3.16.7-ckt14 -stable review patch. If anyone has any objections, please let me
know.
--
From: Nicholas Mc Guire hof...@osadl.org
commit ed9244e6c534612d2b5ae47feab2f55a0d4b4ced upstream.
Fix possible unintended sign extension in unsigned MMIO loads by casting
to uint16_t in
On Thu, 2015-06-25 at 09:37 +, Wu, Feng wrote:
-Original Message-
From: Joerg Roedel [mailto:j...@8bytes.org]
Sent: Wednesday, June 24, 2015 11:46 PM
To: Alex Williamson
Cc: Wu, Feng; Eric Auger; Avi Kivity; kvm@vger.kernel.org;
linux-ker...@vger.kernel.org;
my name is Mrs. Alice Walton,i have a charity proposal for you
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
spinlock torture tests made it clear that checking mmu_enabled()
every time we call spin_lock is a bad idea. As most tests will
want the MMU enabled the entire time, then just hard code
mmu_enabled() to true. Tests that want to play with the MMU can
be compiled with CONFIG_MAY_DISABLE_MMU to get
While porting the test in virtualopensystems' tcg_baremetal_tests
to kvm-unit-tests, I found a couple places to improve the spinlock
implementation. I also added a way to build a single test that
doesn't necessary have an entry in the makefile, which should be handy
for experimental tests.
Andrew
This is mostly useful for building new tests that don't yet (and
may never) have entries in the makefiles (config-arm*.mak). Of course
it can be used to build tests that do have entries as well, in order
to avoid building all tests, if the plan is to run just the one.
Just do 'make
It shouldn't be necessary to use a barrier on the way into
spin_lock. We'll be focused on a single address until we get
it (exclusively) set, and then we'll do a barrier on the way
out. Also, it does make sense to do a barrier on the way in
to spin_unlock, i.e. ensure what we did in the critical
On 25/06/2015 18:12, Andrew Jones wrote:
spinlock torture tests made it clear that checking mmu_enabled()
every time we call spin_lock is a bad idea. As most tests will
want the MMU enabled the entire time, then just hard code
mmu_enabled() to true. Tests that want to play with the MMU can
On Thu, Jun 25, 2015 at 06:23:48PM +0200, Paolo Bonzini wrote:
On 25/06/2015 18:12, Andrew Jones wrote:
spinlock torture tests made it clear that checking mmu_enabled()
every time we call spin_lock is a bad idea. As most tests will
want the MMU enabled the entire time, then just hard
On Wed, 24 Jun 2015 17:08:56 +0200
Michael S. Tsirkin m...@redhat.com wrote:
On Wed, Jun 24, 2015 at 04:52:29PM +0200, Igor Mammedov wrote:
On Wed, 24 Jun 2015 16:17:46 +0200
Michael S. Tsirkin m...@redhat.com wrote:
On Wed, Jun 24, 2015 at 04:07:27PM +0200, Igor Mammedov wrote:
On
spinlock torture tests made it clear that checking mmu_enabled()
every time we call spin_lock is a bad idea. As most tests will
want the MMU enabled the entire time, then we can inline a light
weight nobody disabled the mmu check, and bail out early.
Adding a light weight inlined check vs. a
Allow unit test cpus to disable the MMU. Why not? We want the
test framework to be as flexible as possible. Callers will have
to deal with the cache coherency fallout... Cache flush support
is still forthcoming to the framework though.
Signed-off-by: Andrew Jones drjo...@redhat.com
---
The mmu is enabled automatically for all cpus, they must disable it
themselves if they don't want it on. Switch from managing a cpumask
of enabled cpus to one of disabled cpus. This allows us to remove
the mmu_set_enabled call from secondary_cinit, and the function all
together.
Signed-off-by:
Andrew Jones (3):
arm/arm64: Introduce mmu_disable
arm/arm64: drop mmu_set_enabled
arm/arm64: speed up spinlocks and atomic ops
arm/cstart.S | 9 +
arm/cstart64.S| 8
lib/arm/asm/mmu-api.h | 9 +++--
lib/arm/mmu.c | 32
On Sun, Jun 07, 2015 at 11:15:08AM +0200, Jan Kiszka wrote:
From: Jan Kiszka jan.kis...@siemens.com
ARAT signals that the APIC timer does not stop in power saving states.
As our APICs are emulated, it's fine to expose this feature to guests,
at least when asking for KVM host features or with
However, why is the roundtrip to userspace necessary? Could you pass
the extint index directly as an argument to KVM_INTERRUPT? It's
backwards-compatible, because KVM_INTERRUPT so far could not be used
together with an in-kernel LAPIC. If you could do that, you could also
avoid the new
Christoffer Dall christoffer.d...@linaro.org writes:
On Fri, Jun 19, 2015 at 01:23:47PM +0100, Alex Bennée wrote:
This introduces a level of indirection for the debug registers. Instead
of using the sys_regs[] directly we store registers in a structure in
the vcpu. As we are no longer tied
Christoffer Dall christoffer.d...@linaro.org writes:
On Fri, Jun 19, 2015 at 01:23:48PM +0100, Alex Bennée wrote:
This adds support for userspace to control the HW debug registers for
guest debug. In the debug ioctl we copy the IMPDEF defined number of
s/defined//
registers into a new
Hi!
But personally I would prefer we
check irqchip routing entries have flat mapping, ie gsi = irqchip.pin
since in any case we don't want/expect the userspace to play with that.
Why? On x86 userspace perfectly can play with it. We can imagine some very new
qemu version in
future which has
Hi Christoffer,
On 25/06/15 09:04, Christoffer Dall wrote:
On Wed, Jun 24, 2015 at 03:54:57PM +0100, Marc Zyngier wrote:
Userspace is allowed to set the guest's view of CNTVCT, which turns
into setting CNTVOFF for the whole VM. One thing userspace is not supposed
to do is to update that
On 25.06.2015 11:10, Peter Maydell wrote:
On 25 June 2015 at 09:59, Claudio Fontana claudio.font...@huawei.com wrote:
Once the VM is created, I think QEMU should not request kvm to
change the virtual offset of the VM anymore: maybe an unexpected
consequence of QEMU's
-Original Message-
From: Joerg Roedel [mailto:j...@8bytes.org]
Sent: Wednesday, June 24, 2015 11:46 PM
To: Alex Williamson
Cc: Wu, Feng; Eric Auger; Avi Kivity; kvm@vger.kernel.org;
linux-ker...@vger.kernel.org; pbonz...@redhat.com; mtosa...@redhat.com
Subject: Re: [v4 08/16] KVM:
Hi Christoffer,
On 25.06.2015 10:04, Christoffer Dall wrote:
On Wed, Jun 24, 2015 at 03:54:57PM +0100, Marc Zyngier wrote:
Userspace is allowed to set the guest's view of CNTVCT, which turns
into setting CNTVOFF for the whole VM. One thing userspace is not supposed
to do is to update that
On 25 June 2015 at 09:59, Claudio Fontana claudio.font...@huawei.com wrote:
Once the VM is created, I think QEMU should not request kvm to
change the virtual offset of the VM anymore: maybe an unexpected
consequence of QEMU's target-arm/kvm64.c::kvm_arch_put_registers ?
Hmm. In general we
37 matches
Mail list logo
