On 19/09/12 16:47, Alexander Graf wrote:
>
> On 04.09.2012, at 17:13, Cornelia Huck wrote:
>
>> Handle most support for channel I/O instructions in the kernel itself.
>>
>> Only asynchronous functions (such as the start function) need to be
>> handled by userspace.
>
> Phew. This is a lot of cod
Am Donnerstag 20 September 2012, 09:14:18 schrieb Michael Tokarev:
> This appears to be the same as https://bugs.launchpad.net/bugs/1033727 ,
> FWIW.
Yes, seems so. I've subscribed to it.
Bye...
Dirk
--
Dirk Heinrichs
Tel: +49 (0)2471 209385 | Mobil: +49 (0)176 34473913
GPG Public Key
On 09/13/2012 02:48 AM, Jiannan Ouyang wrote:
Hi Raghu,
I'm working on improving paravirtualized spinlock performance for a
while, with my past findings, I come up with a new idea to make the
pause-loop handler more efficient.
Our original idea is to expose vmm scheduling information to the
gue
Commit f349c12c0434e29c79ecde89029320c4002f7253 added the guest stop
notification, but it did it in a way that the stop notification would
never reach the kernel. The kvm_vm_state_changed() function gets a
value of 0 for the 'running' parameter when the VM is stopped, making
all the code added pre
On 09/20/2012 04:43 AM, Hao, Xudong wrote:
>> -Original Message-
>> From: Avi Kivity [mailto:a...@redhat.com]
>> Sent: Wednesday, September 19, 2012 6:24 PM
>> To: Hao, Xudong
>> Cc: Marcelo Tosatti; kvm@vger.kernel.org; Zhang, Xiantao
>> Subject: Re: [PATCH v3] kvm/fpu: Enable fully eager
On 18/09/12 22:53, Christoffer Dall wrote:
> On Tue, Sep 18, 2012 at 5:04 PM, Russell King - ARM Linux
> wrote:
>> 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 s
On 09/14/2012 12:58 PM, Xiao Guangrong wrote:
> Let it return emulate state instead of spte like __direct_map
>
> Signed-off-by: Xiao Guangrong
> ---
> arch/x86/kvm/paging_tmpl.h | 28 ++--
> 1 files changed, 10 insertions(+), 18 deletions(-)
>
> diff --git a/arch/x86/
On 09/14/2012 12:59 PM, Xiao Guangrong wrote:
> Wrap the common operations into these two functions
>
> Signed-off-by: Xiao Guangrong
> ---
> arch/x86/kvm/mmu.c | 53 +++
> arch/x86/kvm/paging_tmpl.h | 16 +
> 2 files changed, 39 in
On 09/19/2012 08:44 PM, Auld, Will wrote:
> From 9982bb73460b05c1328068aae047b14b2294e2da Mon Sep 17 00:00:00 2001
> From: Will Auld
> Date: Wed, 12 Sep 2012 18:10:56 -0700
> Subject: [PATCH] Enabling IA32_TSC_ADJUST for guest VM
>
> CPUID.7.0.EBX[1]=1 indicates IA32_TSC_ADJUST MSR 0x3b is suppor
On 09/19/2012 08:44 PM, Auld, Will wrote:
> @@ -2241,6 +2244,13 @@ static int vmx_set_msr(struct kvm_vcpu *vcpu, u32
> msr_index, u64 data)
> }
> ret = kvm_set_msr_common(vcpu, msr_index, data);
> break;
> + case MSR_TSC_ADJUST:
> +#define DUMMY 1
> +
On 09/19/2012 10:38 PM, Jan Kiszka wrote:
> If we reset a vcpu on INIT, make sure to not touch dr7 as stored in the
> VMCS/VMCB and also switch_db_regs if guest debugging is using hardware
> breakpoints. Otherwise, the vcpu will not trigger hardware breakpoints
> until userspace issues another KVM_
On 09/13/2012 05:19 PM, Gleb Natapov wrote:
> Most interrupt are delivered to only one vcpu. Use pre-build tables to
> find interrupt destination instead of looping through all vcpus. In case
> of logical mode loop only through vcpus in a logical cluster irq is sent
> to.
Applied, thanks.
--
er
On Thu, Sep 20, 2012 at 01:55:20PM +0530, Amit Shah wrote:
> Commit f349c12c0434e29c79ecde89029320c4002f7253 added the guest stop
> notification, but it did it in a way that the stop notification would
> never reach the kernel. The kvm_vm_state_changed() function gets a
> value of 0 for the 'runni
Amit, should please use "uq/master" in the subject to help
the person who is merging patches.
On Thu, Sep 20, 2012 at 01:55:20PM +0530, Amit Shah wrote:
> Commit f349c12c0434e29c79ecde89029320c4002f7253 added the guest stop
> notification, but it did it in a way that the stop notification would
>
On Mon, Sep 17, 2012 at 07:58:57AM -0700, Arnaldo Carvalho de Melo wrote:
> Em Mon, Sep 17, 2012 at 04:31:13PM +0800, Dong Hao escreveu:
> > From: Xiao Guangrong
> >
> > Exporting KVM exit information to userspace to be consumed by perf.
> >
> > [ Dong Hao : rebase it on acme's git tree ]
> > Si
> -Original Message-
> From: kvm-ow...@vger.kernel.org [mailto:kvm-ow...@vger.kernel.org] On
> Behalf Of Christoffer Dall
> Sent: Sunday, September 16, 2012 12:37 AM
> To: kvm@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> kvm...@lists.cs.columbia.edu
> Subject: [PATCH 01/10] ARM:
On Thu, Sep 20, 2012 at 6:01 AM, Marc Zyngier wrote:
> On 18/09/12 22:53, Christoffer Dall wrote:
>> On Tue, Sep 18, 2012 at 5:04 PM, Russell King - ARM Linux
>> wrote:
>>> On Sat, Sep 15, 2012 at 11:34:36AM -0400, Christoffer Dall wrote:
From: Marc Zyngier
The KVM hypervisor mmu
On 9/17/12 2:31 AM, Dong Hao wrote:
From: Xiao Guangrong
Add 'perf kvm stat' support to analyze kvm vmexit/mmio/ioport smartly
Usage:
- kvm stat
run a command and gather performance counter statistics, it is the alias of
perf stat
- trace kvm events:
perf kvm stat record, or, if othe
On Thu, 20 Sep 2012 21:53:33 +0900, Min-gyu Kim
wrote:
>> -Original Message-
>> From: kvm-ow...@vger.kernel.org [mailto:kvm-ow...@vger.kernel.org] On
>> Behalf Of Christoffer Dall
>> Sent: Sunday, September 16, 2012 12:37 AM
>> To: kvm@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
Hi Richard,
This series is following up from your mail at
http://www.spinics.net/lists/kvm/msg80080.html . I am pleased the lock
contention is now reduced but acknowledge that the scanning rates are
stupidly high. Fortunately, I am reasonably confident I know what is
going wrong. If all goes accor
This is almost entirely based on Rik's previous patches and discussions
with him about how this might be implemented.
Order > 0 compaction stops when enough free pages of the correct page
order have been coalesced. When doing subsequent higher order allocations,
it is possible for compaction to b
When compaction was implemented it was known that scanning could potentially
be excessive. The ideal was that a counter be maintained for each pageblock
but maintaining this information would incur a severe penalty due to a
shared writable cache line. It has reached the point where the scanning
cos
This reverts commit 7db8889a (mm: have order > 0 compaction start off
where it left) and commit de74f1cc (mm: have order > 0 compaction start
near a pageblock with free pages). These patches were a good idea and
tests confirmed that they massively reduced the amount of scanning but
the implementati
From: Shaohua Li
Changelog since V2
o Fix BUG_ON triggered due to pages left on cc.migratepages
o Make compact_zone_order() require non-NULL arg `contended'
Changelog since V1
o only abort the compaction if lock is contended or run too long
o Rearranged the code by Andrea Arcangeli.
isolate_mig
Compactions free scanner acquires the zone->lock when checking for PageBuddy
pages and isolating them. It does this even if there are no PageBuddy pages
in the range.
This patch defers acquiring the zone lock for as long as possible. In the
event there are no free pages in the pageblock then the l
Compactions migrate scanner acquires the zone->lru_lock when scanning a range
of pages looking for LRU pages to acquire. It does this even if there are
no LRU pages in the range. If multiple processes are compacting then this
can cause severe locking contention. To make matters worse commit b2eef8c
Cornelia Huck writes:
> Add a new virtio transport that uses channel commands to perform
> virtio operations.
>
> Add a new machine type s390-ccw that uses this virtio-ccw transport
> and make it the default machine for s390.
>
> Signed-off-by: Cornelia Huck
> ---
>
> Changes v1->v2:
> - update
Cornelia Huck writes:
> This patch enables using both virtio-xxx-s390 and virtio-xxx-ccw
> by making the alias lookup code verify that a driver is actually
> registered.
>
> (Only included in order to allow testing of virtio-ccw; should be
> replaced by cleaning up the virtio bus model.)
>
> Not-
On 20.09.2012, at 16:24, Anthony Liguori wrote:
> Cornelia Huck writes:
>
>> Add a new virtio transport that uses channel commands to perform
>> virtio operations.
>>
>> Add a new machine type s390-ccw that uses this virtio-ccw transport
>> and make it the default machine for s390.
>>
>> Si
On Wed, Sep 19, 2012 at 05:26:01PM -0400, Don Slutz wrote:
> On 09/19/12 15:32, Eduardo Habkost wrote:
> >On Mon, Sep 17, 2012 at 10:00:55AM -0400, Don Slutz wrote:
> >>This is used to set the cpu object's hypervisor level to the default for
> >>Microsoft's Hypervisor.
> >>
> >>Signed-off-by: Don
Hi guys,
We're seeing the following problem during upstream testing:
qemu: VQ 0 size 0x80 Guest index 0x2d6
inconsistent with Host index 0x18: delta 0x2be
qemu: warning: error while loading state for
instance 0x0 of device ':00:04.0/virtio-blk'
load of migration failed
This
On 2012-09-19, at 7:45 AM, Jan Kiszka wrote:
> On 2012-09-19 16:38, Avi Kivity wrote:
>> On 09/17/2012 10:36 PM, Dean Pucsek wrote:
>>> Hello,
>>>
>>> For my Masters thesis I am investigating the usage of Intel VT-x and branch
>>> tracing in the domain of malware analysis. Essentially what I'
In hw/kvm/pci-assign.c a pread() error part of assigned_dev_pci_read()
result in a hw_error(). Similarly a pwrite() error part of
assigned_dev_pci_write() also result in a hw_error().
Would there be a way to avoid terminating the guest for those cases? How
about we deassign the device upon err
On Thu, Sep 06, 2012 at 08:27:40PM +0900, Tomoki Sekiyama wrote:
> Initialize rcu related variables to avoid warnings about RCU usage while
> slave CPUs is running specified functions. Also notify RCU subsystem before
> the slave CPU is entered into idle state.
Hello, Tomoki,
A few questions and
On 2012-09-20 19:27, Etienne Martineau wrote:
> In hw/kvm/pci-assign.c a pread() error part of assigned_dev_pci_read()
> result in a hw_error(). Similarly a pwrite() error part of
> assigned_dev_pci_write() also result in a hw_error().
>
> Would there be a way to avoid terminating the guest for th
On Thu, 2012-09-20 at 13:27 -0400, Etienne Martineau wrote:
> In hw/kvm/pci-assign.c a pread() error part of assigned_dev_pci_read()
> result in a hw_error(). Similarly a pwrite() error part of
> assigned_dev_pci_write() also result in a hw_error().
>
> Would there be a way to avoid terminating
On 09/20/2012 10:04 AM, Mel Gorman wrote:
When compaction was implemented it was known that scanning could potentially
be excessive. The ideal was that a counter be maintained for each pageblock
but maintaining this information would incur a severe penalty due to a
shared writable cache line. It
On 09/20/2012 10:04 AM, Mel Gorman wrote:
This reverts commit 7db8889a (mm: have order > 0 compaction start off
where it left) and commit de74f1cc (mm: have order > 0 compaction start
near a pageblock with free pages). These patches were a good idea and
tests confirmed that they massively reduced
On 09/20/2012 10:04 AM, Mel Gorman wrote:
This is almost entirely based on Rik's previous patches and discussions
with him about how this might be implemented.
Order > 0 compaction stops when enough free pages of the correct page
order have been coalesced. When doing subsequent higher order all
On 09/20/2012 10:04 AM, Mel Gorman wrote:
Compactions free scanner acquires the zone->lock when checking for PageBuddy
pages and isolating them. It does this even if there are no PageBuddy pages
in the range.
This patch defers acquiring the zone lock for as long as possible. In the
event there a
On 09/20/2012 10:04 AM, Mel Gorman wrote:
Compactions migrate scanner acquires the zone->lru_lock when scanning a range
of pages looking for LRU pages to acquire. It does this even if there are
no LRU pages in the range. If multiple processes are compacting then this
can cause severe locking cont
On 09/20/2012 10:04 AM, Mel Gorman wrote:
From: Shaohua Li
Changelog since V2
o Fix BUG_ON triggered due to pages left on cc.migratepages
o Make compact_zone_order() require non-NULL arg `contended'
Changelog since V1
o only abort the compaction if lock is contended or run too long
o Rearrange
On 09/20/2012 02:16 PM, Alex Williamson wrote:
On Thu, 2012-09-20 at 13:27 -0400, Etienne Martineau wrote:
In hw/kvm/pci-assign.c a pread() error part of assigned_dev_pci_read()
result in a hw_error(). Similarly a pwrite() error part of
assigned_dev_pci_write() also result in a hw_error().
Woul
On Thu, 2012-09-20 at 15:08 -0400, Etienne Martineau wrote:
> On 09/20/2012 02:16 PM, Alex Williamson wrote:
> > On Thu, 2012-09-20 at 13:27 -0400, Etienne Martineau wrote:
> >> In hw/kvm/pci-assign.c a pread() error part of assigned_dev_pci_read()
> >> result in a hw_error(). Similarly a pwrite()
Also known as Paravirtualization CPUIDs.
This is primarily done so that the guest will think it is running
under vmware when hypervisor-vendor=vmware is specified as a
property of a cpu.
This depends on:
http://lists.gnu.org/archive/html/qemu-devel/2012-09/msg01400.html
As far as I know it is
The check using INT_MAX (2147483647) is wrong in this case.
Signed-off-by: Fred Oliveira
Signed-off-by: Don Slutz
---
target-i386/cpu.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/target-i386/cpu.c b/target-i386/cpu.c
index af50a8f..0313cf5 100644
--- a/target-i386
Fix duplicate name (kvmclock => kvm_clock2) also.
Signed-off-by: Don Slutz
---
target-i386/cpu.c | 12
1 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/target-i386/cpu.c b/target-i386/cpu.c
index 0313cf5..5f9866a 100644
--- a/target-i386/cpu.c
+++ b/target-i386/cpu.c
Also known as Paravirtualization level or maximim cpuid function present in
this leaf.
This is just the EAX value for 0x4000.
QEMU knows this is KVM_CPUID_SIGNATURE (0x4000).
This is based on:
Microsoft Hypervisor CPUID Leaves:
http://msdn.microsoft.com/en-us/library/windows/hardware
This is used to set the cpu object's hypervisor level to the default for
Microsoft's Hypervisor.
HYPERV_CPUID_MIN (0x4005) is defined in a linux header file.
CPUID_HV_LEVEL_HYPERV (0x4005) is used instead.
Signed-off-by: Don Slutz
---
target-i386/cpu.c | 10 ++
target-i386/cp
These are modeled after x86_cpuid_get_xlevel and x86_cpuid_set_xlevel.
Signed-off-by: Don Slutz
---
target-i386/cpu.c | 28
1 files changed, 28 insertions(+), 0 deletions(-)
diff --git a/target-i386/cpu.c b/target-i386/cpu.c
index 5f9866a..0e4a18d 100644
--- a/tar
Also known as Paravirtualization level.
This change is based on:
Microsoft Hypervisor CPUID Leaves:
http://msdn.microsoft.com/en-us/library/windows/hardware/ff542428%28v=vs.85%29.aspx
Linux kernel change starts with:
http://fixunix.com/kernel/538707-use-cpuid-communicate-hypervisor.html
Als
Also known as Paravirtualization level.
This change is based on:
Microsoft Hypervisor CPUID Leaves:
http://msdn.microsoft.com/en-us/library/windows/hardware/ff542428%28v=vs.85%29.aspx
Linux kernel change starts with:
http://fixunix.com/kernel/538707-use-cpuid-communicate-hypervisor.html
Als
These are modeled after x86_cpuid_set_vendor and x86_cpuid_get_vendor.
Since kvm's vendor is shorter, the test for correct size is removed and zero
padding is added.
Set Microsoft's Vendor now that we can. Value defined in:
http://msdn.microsoft.com/en-us/library/windows/hardware/ff542428%28v
Also known as Paravirtualization vendor.
This change is based on:
Microsoft Hypervisor CPUID Leaves:
http://msdn.microsoft.com/en-us/library/windows/hardware/ff542428%28v=vs.85%29.aspx
Linux kernel change starts with:
http://fixunix.com/kernel/538707-use-cpuid-communicate-hypervisor.html
Al
Signed-off-by: Don Slutz
---
target-i386/cpu.h |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/target-i386/cpu.h b/target-i386/cpu.h
index 6dafaeb..e158c54 100644
--- a/target-i386/cpu.h
+++ b/target-i386/cpu.h
@@ -807,6 +807,10 @@ typedef struct CPUX86State {
uin
Signed-off-by: Don Slutz
---
target-i386/cpu.c | 66 +
1 files changed, 66 insertions(+), 0 deletions(-)
diff --git a/target-i386/cpu.c b/target-i386/cpu.c
index 904b08f..7e9c43b 100644
--- a/target-i386/cpu.c
+++ b/target-i386/cpu.c
@@ -1273
This was taken from:
http://article.gmane.org/gmane.comp.emulators.kvm.devel/22643
Signed-off-by: Don Slutz
---
target-i386/cpu.c | 32
1 files changed, 32 insertions(+), 0 deletions(-)
diff --git a/target-i386/cpu.c b/target-i386/cpu.c
index 7e9c43b..459469
Signed-off-by: Don Slutz
---
target-i386/kvm.c | 19 +++
1 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/target-i386/kvm.c b/target-i386/kvm.c
index dde9214..bd7753f 100644
--- a/target-i386/kvm.c
+++ b/target-i386/kvm.c
@@ -457,6 +457,25 @@ int kvm_arch_init_vcp
Signed-off-by: Don Slutz
---
target-i386/cpu.c | 44 +++-
target-i386/cpu.h | 14 ++
2 files changed, 57 insertions(+), 1 deletions(-)
diff --git a/target-i386/cpu.c b/target-i386/cpu.c
index 5cf7146..904b08f 100644
--- a/target-i386/cpu.c
Also known as Paravirtualization vendor.
This change is based on:
Microsoft Hypervisor CPUID Leaves:
http://msdn.microsoft.com/en-us/library/windows/hardware/ff542428%28v=vs.85%29.aspx
Linux kernel change starts with:
http://fixunix.com/kernel/538707-use-cpuid-communicate-hypervisor.html
Al
Signed-off-by: Don Slutz
---
target-i386/cpu.c | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/target-i386/cpu.c b/target-i386/cpu.c
index 4594693..72a8442 100644
--- a/target-i386/cpu.c
+++ b/target-i386/cpu.c
@@ -1991,6 +1991,17 @@ void cpu_x86_cpuid(CPUX86St
Also known as Paravirtualization vendor.
This is EBX, ECX, EDX data for 0x4000.
QEMU knows this is KVM_CPUID_SIGNATURE (0x4000).
This is based on:
Microsoft Hypervisor CPUID Leaves:
http://msdn.microsoft.com/en-us/library/windows/hardware/ff542428%28v=vs.85%29.aspx
Linux kernel chang
Looking at http://lkml.indiana.edu/hypermail/linux/kernel/1205.0/00100.html
The new value for EAX is 0x4001.
This depends on
http://lists.gnu.org/archive/html/qemu-devel/2012-09/msg02497.html
As far as I known it is #5. It depends on (1), (2), (3) and (4).
Based on cpu-queue[1] branch.
(Fr
>From http://lkml.indiana.edu/hypermail/linux/kernel/1205.0/00100.html
EAX should be KVM_CPUID_FEATURES (0x4001) not 0.
Added hypervisor-vendor=kvm0 to get the older CPUID result. kvm1 selects the
newer one.
Signed-off-by: Don Slutz
---
target-i386/cpu.c | 17 +
1 files c
On 09/20/2012 03:37 PM, Alex Williamson wrote:
On Thu, 2012-09-20 at 15:08 -0400, Etienne Martineau wrote:
On 09/20/2012 02:16 PM, Alex Williamson wrote:
On Thu, 2012-09-20 at 13:27 -0400, Etienne Martineau wrote:
In hw/kvm/pci-assign.c a pread() error part of assigned_dev_pci_read()
result in
On 09/12/2012 06:39 PM, Marcelo Tosatti wrote:
HW TSC scaling is a feature of AMD processors that allows a
multiplier to be specified to the TSC frequency exposed to the guest.
KVM also contains provision to trap TSC ("KVM: Infrastructure for
software and hardware based TSC rate scaling" cc578
On Thu, 2012-09-20 at 16:36 -0400, Etienne Martineau wrote:
> On 09/20/2012 03:37 PM, Alex Williamson wrote:
> > On Thu, 2012-09-20 at 15:08 -0400, Etienne Martineau wrote:
> >> On 09/20/2012 02:16 PM, Alex Williamson wrote:
> >>> On Thu, 2012-09-20 at 13:27 -0400, Etienne Martineau wrote:
> I
Hi,
Just a Xen newbie myself, but from what i've gathered and fiddled, Xen
(P)VMs don't come with a graphics card. You'd have to remote to your
Windows HVM to play games. You can fiddle with PCI pass through for
some video cards and there's some VGA passtrough as well, but i don't
think running a
I'm looking to build a new personal computer. I want it to function as
a Linux desktop, provide network services for my home, and lastly,
occasional Windows gaming. From what I've gathered, virtualization
using a Type 1 Hypervisor supporting PCI/VGA pass-through like KVM or
Xen would be an at
On Thu, 2012-09-20 at 17:12 -0400, ShadesOfGrey wrote:
> I'm looking to build a new personal computer. I want it to function as
> a Linux desktop, provide network services for my home, and lastly,
> occasional Windows gaming. From what I've gathered, virtualization
> using a Type 1 Hypervisor
On Fri, Sep 21, 2012 at 12:02:46AM +0300, Dor Laor wrote:
> On 09/12/2012 06:39 PM, Marcelo Tosatti wrote:
> >
> >
> >HW TSC scaling is a feature of AMD processors that allows a
> >multiplier to be specified to the TSC frequency exposed to the guest.
> >
> >KVM also contains provision to trap TSC (
From: Jan Kiszka
If we reset a vcpu on INIT, we so far overwrote dr7 as provided by
KVM_SET_GUEST_DEBUG, and we also cleared switch_db_regs unconditionally.
Fix this by saving the dr7 used for guest debugging and calculating the
effective register value as well as switch_db_regs on any potential
This removes the powerpc "generic" updates of vcpu->cpu in load and
put, and moves them to the various backends.
The reason is that "HV" KVM does its own sauce with that field
and the generic updates might corrupt it. The field contains the
CPU# of the -first- HW CPU of the core always for all the
Currently the code that accounts stolen time tends to overestimate the
stolen time, and will sometimes report more stolen time in a DTL
(dispatch trace log) entry than has elapsed since the last DTL entry.
This can cause guests to underflow the user or system time measured
for some tasks, leading t
The PAPR paravirtualization interface lets guests register three
different types of per-vCPU buffer areas in its memory for communication
with the hypervisor. These are called virtual processor areas (VPAs).
Currently the hypercalls to register and unregister VPAs are handled
by KVM in the kernel,
Subsequent patches implementing in-kernel XICS emulation will make it
possible for IPIs to arrive at secondary threads at arbitrary times.
This fixes some races in how we start the secondary threads, which
if not fixed could lead to occasional crashes of the host kernel.
This makes sure that (a) w
When a Book3S HV KVM guest is running, we need the host to be in
single-thread mode, that is, all of the cores (or at least all of
the cores where the KVM guest could run) to be running only one
active hardware thread. This is because of the hardware restriction
in POWER processors that all of the
This is a repost of 10 patches out of a series of 12 that I posted
more than three weeks ago that have had no comments but have not yet
been applied. They have been rediffed against Alex Graf's current
kvm-ppc-next branch.
This series contains various fixes collected during the process of
getting
There were a few places where we were traversing the list of runnable
threads in a virtual core, i.e. vc->runnable_threads, without holding
the vcore spinlock. This extends the places where we hold the vcore
spinlock to cover everywhere that we traverse that list.
Since we possibly need to sleep
When making a vcpu non-runnable we incorrectly changed the
thread IDs of all other threads on the core, just remove that
code.
Signed-off-by: Benjamin Herrenschmidt
Signed-off-by: Paul Mackerras
---
arch/powerpc/kvm/book3s_hv.c |6 --
1 file changed, 6 deletions(-)
diff --git a/arch/po
In the case where the host kernel is using a 64kB base page size and
the guest uses a 4k HPTE (hashed page table entry) to map an emulated
MMIO device, we were calculating the guest physical address wrongly.
We were calculating a gfn as the guest physical address shifted right
16 bits (PAGE_SHIFT)
If a thread in a virtual core becomes runnable while other threads
in the same virtual core are already running in the guest, it is
possible for the latecomer to join the others on the core without
first pulling them all out of the guest. Currently this only happens
rarely, when a vcpu is first st
Currently the Book3S HV code implements a policy on multi-threaded
processors (i.e. POWER7) that requires all of the active vcpus in a
virtual core to be ready to run before we run the virtual core.
However, that causes problems on reset, because reset stops all vcpus
except vcpu 0, and can also re
This enables userspace to get and set all the guest floating-point
state using the KVM_[GS]ET_ONE_REG ioctls. The floating-point state
includes all of the traditional floating-point registers and the
FPSCR (floating point status/control register), all the VMX/Altivec
vector registers and the VSCR
This enables userspace to get and set various SPRs (special-purpose
registers) using the KVM_[GS]ET_ONE_REG ioctls. With this, userspace
can get and set all the SPRs that are part of the guest state, either
through the KVM_[GS]ET_REGS ioctls, the KVM_[GS]ET_SREGS ioctls, or
the KVM_[GS]ET_ONE_REG
Changlog:
changes from Avi's comments:
- comment for FNAME(fetch)
- add annotations (__acquires, __releases) for page_fault_start and
page_fault_end
changes from Marcelo's comments:
- remove mmu_is_invalid
- make release noslot pfn path more readable
The last patch which introduces page_fa
We can not directly call kvm_release_pfn_clean to release the pfn
since we can meet noslot pfn which is used to cache mmio info into
spte
Signed-off-by: Xiao Guangrong
---
arch/x86/kvm/mmu.c |6 --
arch/x86/kvm/paging_tmpl.h |6 --
2 files changed, 8 insertions(+), 4 dele
Remove mmu_is_invalid and use is_invalid_pfn instead
Signed-off-by: Xiao Guangrong
---
arch/x86/kvm/mmu.c |5 -
arch/x86/kvm/paging_tmpl.h |4 ++--
2 files changed, 2 insertions(+), 7 deletions(-)
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 0f56169..3e9728b 10
It helps us to cleanup release pfn in the later patches
Signed-off-by: Xiao Guangrong
---
arch/x86/kvm/mmu.c | 29 ++---
arch/x86/kvm/paging_tmpl.h | 18 --
2 files changed, 26 insertions(+), 21 deletions(-)
diff --git a/arch/x86/kvm/mmu.c b/a
Let it return emulate state instead of spte like __direct_map
Signed-off-by: Xiao Guangrong
---
arch/x86/kvm/paging_tmpl.h | 31 ---
1 files changed, 12 insertions(+), 19 deletions(-)
diff --git a/arch/x86/kvm/paging_tmpl.h b/arch/x86/kvm/paging_tmpl.h
index 56f808
The only difference between FNAME(update_pte) and FNAME(pte_prefetch)
is that the former is allowed to prefetch gfn from dirty logged slot,
so introduce a common function to prefetch spte
Signed-off-by: Xiao Guangrong
---
arch/x86/kvm/paging_tmpl.h | 58 ++--
91 matches
Mail list logo
