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 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 QEM
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 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: And
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
---
arm/cstart.S | 9 ++
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 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
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 ca
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 th
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 TEST=some-test'
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 se
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
On 25 June 2015 at 14:44, Marc Zyngier 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).
>
> So if the us
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/
On 25 June 2015 at 13:41, Christoffer Dall wrote:
> On Thu, Jun 25, 2015 at 10:06:20AM +0100, Peter Maydell wrote:
>> I agree it's not very likely anybody cares about the specific cluster
>> topology. However if we don't want to support arbitrary topologies
>> then QEMU is going to end up in the b
On Thu, Jun 25, 2015 at 10:06:20AM +0100, Peter Maydell wrote:
> On 25 June 2015 at 09:00, Christoffer Dall
> wrote:
> > Of course, KVM can deny an unsupported configuration, but I am wondering
> > if we really think anybody will care about the 'model such specific
> > hardware' aspect with KVM,
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 J
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
> >>> wr
Christoffer Dall writes:
> On Thu, Jun 25, 2015 at 07:38:33AM +0100, Alex Bennée wrote:
>>
>> Christoffer Dall 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 deb
On 25.06.2015 11:10, Peter Maydell wrote:
> On 25 June 2015 at 09:59, Claudio Fontana 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 ?
>
On 25 June 2015 at 09:59, Claudio Fontana 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 assume that we can:
* stop
On 25 June 2015 at 09:00, Christoffer Dall wrote:
> Of course, KVM can deny an unsupported configuration, but I am wondering
> if we really think anybody will care about the 'model such specific
> hardware' aspect with KVM, or if we should only consider the 'I want a
> VM with x VCPUs' scenario, i
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 th
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
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 h
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 for
Hi,
[sorry for reviving this thread late]
On Tue, Jun 09, 2015 at 12:24:13PM +0100, Peter Maydell wrote:
> On 9 June 2015 at 11:52, Marc Zyngier wrote:
> > On 08/06/15 11:52, Peter Maydell wrote:
> >> On 8 June 2015 at 11:32, Igor Mammedov wrote:
> >>> On Thu, 4 Jun 2015 18:17:39 +0100
> >>> Pe
On Thu, Jun 25, 2015 at 07:38:33AM +0100, Alex Bennée wrote:
>
> Christoffer Dall 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
On Thu, Jun 25, 2015 at 07:32:27AM +0100, Alex Bennée wrote:
>
> Christoffer Dall 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
28 matches
Mail list logo
