headers
Olivia Yin | 1 Mar 2012 02:20
Favicon

[PATCH v2 2/2] KVM: booke: Improve SPE switch

From: Liu Yu <yu.liu <at> freescale.com>

Like book3s did for fp switch,
instead of switch SPE between host and guest,
the patch switch SPE state between qemu and guest.
In this way, we can simulate a host loadup SPE when load guest SPE state,
and let host to decide when to giveup SPE state.
Therefor it cooperates better with host SPE usage,
and so that has some performance benifit in UP host(lazy SPE).

Moreover, since the patch save guest SPE state into linux thread field,
it creates the condition to emulate guest SPE instructions in host,
so that we can avoid injecting SPE exception to guest.

The patch also turns all asm code into C code,
and add SPE stat counts.

Signed-off-by: Liu Yu <yu.liu <at> freescale.com>
Signed-off-by: Olivia Yin <hong-hua.yin <at> freescale.com>
---
v2: 	
Keep shadow MSR[SPE] consistent with 
thread MSR[SPE] in kvmppc_core_vcpu_load

 arch/powerpc/include/asm/kvm_host.h |   11 +++++-
 arch/powerpc/kernel/asm-offsets.c   |    7 ----
 arch/powerpc/kvm/booke.c            |   63 +++++++++++++++++++++++++++++++----
 arch/powerpc/kvm/booke.h            |    8 +----
 arch/powerpc/kvm/booke_interrupts.S |   37 --------------------
 arch/powerpc/kvm/e500.c             |   13 ++++---
(Continue reading)

Permalink | Reply | 0 comments |
headers
Amos Kong | 1 Mar 2012 06:19
Picon
Favicon
Gravatar

Re: [PATCH v3] KVM: Resize kvm_io_range array dynamically

On 01/03/12 00:34, Amos Kong wrote:
> ----- Original Message -----
>> On 2012-02-29 16:22, Amos Kong wrote:
>>> ----- Original Message -----
>>>> On 2012-02-29 14:30, Amos Kong wrote:
>>>>> kvm_io_bus devices are used for ioevent, pit, pic, ioapic,
>>>>> coalesced_mmio.
>>>>>
>>>>> Currently Qemu only emulates one PCI bus, it contains 32 slots,
>>>>> one slot contains 8 functions, maximum of supported PCI devices:
>>>>>   1 * 32 * 8 = 256. The maximum of coalesced mmio zone is 100,
>>>>> each zone has an iobus devices. 300 io_bus devices is not enough.
>>>>>
>>>>> This patch makes the kvm_io_range array can be resized
>>>>> dynamically.
>>>>
>>>> Is there any limit, or can userspace allocate arbitrary amounts of
>>>> kernel memory this way?
>>>
>>> Hi Jan,
>>>
>>> There is a fixed array in linux-2.6/include/linux/kvm_host.h,
>>> we can only register 300 devices.
>>>
>>> struct kvm_io_range {
>>>          gpa_t addr;
>>>          int len;
>>>          struct kvm_io_device *dev;
>>> };
>>>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Amos Kong | 1 Mar 2012 08:01
Picon
Favicon
Gravatar

[PATCH v4] KVM: Resize kvm_io_range array dynamically

kvm_io_bus devices are used for ioevent, pit, pic, ioapic,
coalesced_mmio.

Currently Qemu only emulates one PCI bus, it contains 32 slots,
one slot contains 8 functions, maximum of supported PCI devices:
 1 * 32 * 8 = 256. One virtio-blk takes one iobus device,
one virtio-net(vhost=on) takes two iobus devices.
The maximum of coalesced mmio zone is 100, each zone
has an iobus devices. So 300 io_bus devices are not enough.

This patch makes the kvm_io_range array can be resized dynamically.
Set an upper bounds for kvm_io_range to limit userspace.
1000 is a very large limit and not bloat the typical user.

Changes from v1:
- fix typo: kvm_io_bus_range -> kvm_io_range

Changes from v2:
- unregister device only when it exists

Changes from v3:
- set upper bounds to limit userspace

Signed-off-by: Amos Kong <akong <at> redhat.com>
---
 include/linux/kvm_host.h |    5 +++--
 virt/kvm/kvm_main.c      |   41 ++++++++++++++++++++++-------------------
 2 files changed, 25 insertions(+), 21 deletions(-)

diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
(Continue reading)

Permalink | Reply | 19 comments |
headers
Thomas Gleixner | 1 Mar 2012 10:58
Picon

Re: x86: kvmclock: abstract save/restore sched_clock_state

On Tue, 7 Feb 2012, Marcelo Tosatti wrote:
> 
> Upon resume from hibernation, CPU 0's hvclock area contains the old
> values for system_time and tsc_timestamp. It is necessary for the
> hypervisor to update these values with uptodate ones before the CPU uses
> them.
> 
> Abstract TSC's save/restore sched_clock_state functions and use
> restore_state to write to KVM_SYSTEM_TIME MSR, forcing an update.
> 
> Fixes suspend-to-disk with kvmclock.
> 
> Signed-off-by: Marcelo Tosatti <mtosatti <at> redhat.com>
> 
> diff --git a/arch/x86/include/asm/tsc.h b/arch/x86/include/asm/tsc.h
> index 15d9915..c91e8b9 100644
> --- a/arch/x86/include/asm/tsc.h
> +++ b/arch/x86/include/asm/tsc.h
>  <at>  <at>  -61,7 +61,7  <at>  <at>  extern void check_tsc_sync_source(int cpu);
>  extern void check_tsc_sync_target(void);
>  
>  extern int notsc_setup(char *);
> -extern void save_sched_clock_state(void);
> -extern void restore_sched_clock_state(void);
> +extern void tsc_save_sched_clock_state(void);
> +extern void tsc_restore_sched_clock_state(void);
>  
>  #endif /* _ASM_X86_TSC_H */
> diff --git a/arch/x86/include/asm/x86_init.h b/arch/x86/include/asm/x86_init.h
> index 5d0afac..baaca8d 100644
(Continue reading)

Permalink | Reply | 0 comments |
headers
Russell King - ARM Linux | 1 Mar 2012 11:10
Picon

Re: [PATCH-WIP 01/13] xen/arm: use r12 to pass the hypercall number to the hypervisor

On Wed, Feb 29, 2012 at 12:58:26PM +0000, Dave Martin wrote:
> On Wed, Feb 29, 2012 at 09:56:02AM +0000, Ian Campbell wrote:
> > On Wed, 2012-02-29 at 09:34 +0000, Dave Martin wrote:
> > > On Tue, Feb 28, 2012 at 12:28:29PM +0000, Stefano Stabellini wrote:
> > 
> > > > I don't have a very strong opinion on which register we should use, but
> > > > I would like to avoid r7 if it is already actively used by gcc.
> > > 
> > > But there is no framepointer for Thumb-2 code (?)
> > 
> > Peter Maydell suggested there was:
> > > r7 is (used by gcc as) the Thumb frame pointer; I don't know if this
> > > makes it worth avoiding in this context.
> > 
> > Sounds like it might be a gcc-ism, possibly a non-default option?
> > 
> > Anyway, I think r12 will be fine for our purposes so the point is rather
> > moot.
> 
> Just had a chat with some tools guys -- apparently, when passing register
> arguments to gcc inline asms there really isn't a guarantee that those
> variables will be in the expected registers on entry to the inline asm.

The best you can do is:

	register unsigned int foo asm("r7") = value;

	asm("blah %0" : : "r" (foo));

and ensure that your assembly checks that %0 _is_ r7 and produces a build
(Continue reading)

Permalink | Reply | 3 comments |
headers
Russell King - ARM Linux | 1 Mar 2012 11:12
Picon

Re: [PATCH-WIP 01/13] xen/arm: use r12 to pass the hypercall number to the hypervisor

On Wed, Feb 29, 2012 at 02:44:24PM +0000, 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 (or gas?) smart enough to optimise this away if it turns out that
> %[hvc_num] == r12?

No, and it won't do, because %[hvc_num] is specified in these operands:

> > 		...
> > 		"hvc	#0"
> > 		:: [hvc_num] "i" (NUMBER) : "r12"

to be an integer, not a register.

> How are system calls implemented on the userspace side? I confess I
> don't know what the ARM syscall ABI looks like -- is it all registers or
> is some of it on the stack? It sounds like the solution ought to be
> pretty similar though.

All registers.  We have a few which take a pointer to an in memory array,
but those are for some old multiplexed syscalls.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
(Continue reading)

Permalink | Reply | 0 comments |
headers
Sasha Levin | 1 Mar 2012 11:14
Picon

Re: [PATCH v4] KVM: Resize kvm_io_range array dynamically

On Thu, Mar 1, 2012 at 9:01 AM, Amos Kong <akong <at> redhat.com> wrote:
> This patch makes the kvm_io_range array can be resized dynamically.
> Set an upper bounds for kvm_io_range to limit userspace.
> 1000 is a very large limit and not bloat the typical user.

Whats the reason for making everything dynamic? Memory savings there
aren't that significant.

If you want to make it more efficient just define:
static struct kvm_io_bus io_bus[2];

somewhere in kvm_main.c, and just switch between them when you need to
do insertion and removal of devices. You get the benefit of zero slub
usage, no allocations in any of the paths, and much simpler logic.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 1 comment |
headers
Takuya Yoshikawa | 1 Mar 2012 11:34
Picon

[PATCH 4/4] KVM: Remove unused dirty_bitmap_head and nr_dirty_pages

Now that we do neither double buffering nor heuristic selection of the
write protection method these are not needed anymore.

Note: some drivers have their own implementation of set_bit_le() and
making it generic needs a bit of work; so we use test_and_set_bit_le()
and will later replace it with generic set_bit_le().

Signed-off-by: Takuya Yoshikawa <yoshikawa.takuya <at> oss.ntt.co.jp>
---
 include/linux/kvm_host.h |    2 --
 virt/kvm/kvm_main.c      |   14 +++++---------
 2 files changed, 5 insertions(+), 11 deletions(-)

diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index 355e445..73c7d76 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
 <at>  <at>  -177,8 +177,6  <at>  <at>  struct kvm_memory_slot {
 	unsigned long flags;
 	unsigned long *rmap;
 	unsigned long *dirty_bitmap;
-	unsigned long *dirty_bitmap_head;
-	unsigned long nr_dirty_pages;
 	struct kvm_arch_memory_slot arch;
 	unsigned long userspace_addr;
 	int user_alloc;
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index e4431ad..27a1083 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
(Continue reading)

Permalink | Reply | 0 comments |
headers
Russell King - ARM Linux | 1 Mar 2012 11:35
Picon

Re: [PATCH-WIP 01/13] xen/arm: use r12 to pass the hypercall number to the hypervisor

On Thu, Mar 01, 2012 at 10:27:02AM +0000, 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 practical experience from the kernel suggests that there isn't a
problem - that's not to say that future versions of gcc won't become
a problem, and that the compiler guys may refuse to fix it.

I think it's a feature that we should be pressing gcc guys for - it's
fairly fundamental to any programming which requires interfaces that
require certain args in certain registers, or receive results in
certain registers.

The options over this are basically:
1. refusing to upgrade to any version of gcc which does not allow
   registers-in-asm
2. doing the store-to-memory reload-in-asm thing
3. hand-coding veneers for every call to marshall the registers

Each of those has its down sides, but I suspect with (1), it may be
possible to have enough people applying pressure to the compiler guys
that they finally see sense on this matter.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
(Continue reading)

Permalink | Reply | 1 comment |
headers
bugzilla-daemon | 1 Mar 2012 11:46

[Bug 42829] KVM Guest with virtio network driver loses network connectivity

https://bugzilla.kernel.org/show_bug.cgi?id=42829

Steve <stefan.bosak <at> gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Kernel Version|3.2                         |3.2-rc3

--- Comment #2 from Steve <stefan.bosak <at> gmail.com>  2012-03-01 10:46:09 ---
Rusty, could you have a look at, please ?

Thank you for your time.

--

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |

Gmane