On Tue, Jul 30, 2013 at 09:02:04PM +0800, Xiao Guangrong wrote:
> Relax the tlb flush condition since we will write-protect the spte out of mmu
> lock. Note lockless write-protection only marks the writable spte to readonly
> and the spte can be writable only if both SPTE_HOST_WRITEABLE and
> SPTE_
- Original Message -
> On 08/23/2013 07:24 AM, Andrew Jones wrote:
> > The comment in kvm_max_vcpus() states that it's using the recommended
> > procedure from the kernel API documentation to get the max number
> > of vcpus that kvm supports. It is, but by always returning the
> > maximum
On 08/28/2013 03:23 PM, Gleb Natapov wrote:
> On Tue, Jul 30, 2013 at 09:02:04PM +0800, Xiao Guangrong wrote:
>> Relax the tlb flush condition since we will write-protect the spte out of mmu
>> lock. Note lockless write-protection only marks the writable spte to readonly
>> and the spte can be writ
If we want to remove a vcpu from vm, we should not be only to
put kvm, we need to decrease online vcpus and free struct kvm_vcpu
when closing a vcpu file descriptor.
Signed-off-by: Chen Fan
---
arch/x86/kvm/x86.c | 14 ++
include/linux/kvm_host.h | 1 +
virt/kvm/kvm_main.c
On Tue, Jul 30, 2013 at 09:02:05PM +0800, Xiao Guangrong wrote:
> Change the algorithm to:
> 1) always add new desc to the first desc (pointed by parent_ptes/rmap)
>that is good to implement rcu-nulls-list-like lockless rmap
>walking
>
> 2) always move the entry in first desc to the the po
On Wed, Aug 28, 2013 at 04:08:10PM +0800, Chen Fan wrote:
> If we want to remove a vcpu from vm, we should not be only to
> put kvm, we need to decrease online vcpus and free struct kvm_vcpu
> when closing a vcpu file descriptor.
>
It much more complicated that what you do here. kvm->vcpus[] is ac
On 08/28/2013 04:12 PM, Gleb Natapov wrote:
>> +
>> +rmap_printk("pte_list_add: %p %llx many->many\n", spte, *spte);
>> +desc = (struct pte_list_desc *)(*pte_list & ~1ul);
>> +
>> +/* No empty position in the desc. */
>> +if (desc->sptes[PTE_LIST_EXT - 1]) {
>> +struct
This reserves a capability number for upcoming support
of VFIO-IOMMU DMA operations in real mode.
This reserves a number for a new "SPAPR TCE IOMMU" KVM device
which is going to manage lifetime of SPAPR TCE IOMMU object.
This defines an attribute of the "SPAPR TCE IOMMU" KVM device
which is going
On Tue, Jul 30, 2013 at 09:02:06PM +0800, Xiao Guangrong wrote:
> It likes nulls list and we use the pte-list as the nulls which can help us to
> detect whether the "desc" is moved to anther rmap then we can re-walk the rmap
> if that happened
>
> Signed-off-by: Xiao Guangrong
> ---
> arch/x86/k
The TCE tables handling may differ for real and virtual modes so
additional ppc_md.tce_build_rm/ppc_md.tce_free_rm/ppc_md.tce_flush_rm
handlers were introduced earlier.
So this adds the following:
1. support for the new ppc_md calls;
2. ability to iommu_tce_build to process mupltiple entries per
c
The current VFIO-on-POWER implementation supports only user mode
driven mapping, i.e. QEMU is sending requests to map/unmap pages.
However this approach is really slow, so we want to move that to KVM.
Since H_PUT_TCE can be extremely performance sensitive (especially with
network adapters where eac
This adds real mode handlers for the H_PUT_TCE_INDIRECT and
H_STUFF_TCE hypercalls for user space emulated devices such as IBMVIO
devices or emulated PCI. These calls allow adding multiple entries
(up to 512) into the TCE table in one call which saves time on
transition to/from real mode.
This ad
The existing TCE machine calls (tce_build and tce_free) only support
virtual mode as they call __raw_writeq for TCE invalidation what
fails in real mode.
This introduces tce_build_rm and tce_free_rm real mode versions
which do mostly the same but use "Store Doubleword Caching Inhibited
Indexed" in
It does not make much sense to have KVM in book3s-64bit and
not to have IOMMU bits for PCI pass through support as it costs little
and allows VFIO to function on book3s-kvm.
Having IOMMU_API always enabled makes it unnecessary to have a lot of
"#ifdef IOMMU_API" in arch/powerpc/kvm/book3s_64_vio*.
This adds hash_for_each_possible_rcu_notrace() which is basically
a notrace clone of hash_for_each_possible_rcu() which cannot be
used in real mode due to its tracing/debugging capability.
Signed-off-by: Alexey Kardashevskiy
---
Changes:
v8:
* fixed warnings from check_patch.pl
---
include/linu
This is to reserve a capablity number for upcoming support
of H_PUT_TCE_INDIRECT and H_STUFF_TCE pseries hypercalls
which support mulptiple DMA map/unmap operations per one call.
Signed-off-by: Alexey Kardashevskiy
---
Changes:
2013/07/16:
* changed the number
---
include/uapi/linux/kvm.h | 1 +
This accelerates VFIO DMA operations on POWER by moving them
into kernel.
This depends on VFIO external API patch which is on its way to upstream.
Changes:
v9:
* replaced the "link logical bus number to IOMMU group" ioctl to KVM
with a KVM device doing the same thing, i.e. the actual changes are
The current implementation of IOMMU on sPAPR does not use iommu_ops
and therefore does not call IOMMU API's bus_set_iommu() which
1) sets iommu_ops for a bus
2) registers a bus notifier
Instead, PCI devices are added to IOMMU groups from
subsys_initcall_sync(tce_iommu_init) which does basically the
KVM is going to use VFIO's external API. However KVM can operate even VFIO
is not compiled or loaded so KVM is linked to VFIO dynamically.
This adds proxy functions for VFIO external API.
Signed-off-by: Alexey Kardashevskiy
---
arch/powerpc/kvm/book3s_64_vio.c | 49 +
Book3S KVM implements in-kernel TCE tables via kvmppc_spapr_tce_table
structs list (created per KVM). Entries in the list are per LIOBN
(logical bus number) and have a TCE table so DMA hypercalls (such as
H_PUT_TCE) can convert LIOBN to a TCE table.
The entry in the list is created via KVM_CREATE_
This allows the host kernel to handle H_PUT_TCE, H_PUT_TCE_INDIRECT
and H_STUFF_TCE requests targeted an IOMMU TCE table without passing
them to user space which saves time on switching to user space and back.
Both real and virtual modes are supported. The kernel tries to
handle a TCE request in t
This adds special support for huge pages (16MB) in real mode.
The reference counting cannot be easily done for such pages in real
mode (when MMU is off) so we added a hash table of huge pages.
It is populated in virtual mode and get_page is called just once
per a huge page. Real mode handlers chec
On 08/28/2013 04:40 PM, Gleb Natapov wrote:
>> static unsigned long *__gfn_to_rmap(gfn_t gfn, int level,
>> @@ -1200,7 +1221,7 @@ static u64 *rmap_get_first(unsigned long rmap, struct
>> rmap_iterator *iter)
>> */
>> static u64 *rmap_get_next(struct rmap_iterator *iter)
>> {
>> -if (iter
On Wed, Aug 28, 2013 at 04:37:32PM +0800, Xiao Guangrong wrote:
> On 08/28/2013 04:12 PM, Gleb Natapov wrote:
>
> >> +
> >> + rmap_printk("pte_list_add: %p %llx many->many\n", spte, *spte);
> >> + desc = (struct pte_list_desc *)(*pte_list & ~1ul);
> >> +
> >> + /* No empty position in the desc.
On 08/28/2013 04:58 PM, Gleb Natapov wrote:
> On Wed, Aug 28, 2013 at 04:37:32PM +0800, Xiao Guangrong wrote:
>> On 08/28/2013 04:12 PM, Gleb Natapov wrote:
>>
+
+ rmap_printk("pte_list_add: %p %llx many->many\n", spte, *spte);
+ desc = (struct pte_list_desc *)(*pte_list & ~1ul);
>
On Tue, Jul 30, 2013 at 09:02:07PM +0800, Xiao Guangrong wrote:
> The basic idea is from nulls list which uses a nulls to indicate
> whether the desc is moved to different pte-list
>
> Thanks to SLAB_DESTROY_BY_RCU, the desc can be quickly reused
>
> Signed-off-by: Xiao Guangrong
> ---
> arch/x
On 08/28/2013 05:20 PM, Gleb Natapov wrote:
> On Tue, Jul 30, 2013 at 09:02:07PM +0800, Xiao Guangrong wrote:
>> The basic idea is from nulls list which uses a nulls to indicate
>> whether the desc is moved to different pte-list
>>
>> Thanks to SLAB_DESTROY_BY_RCU, the desc can be quickly reused
>>
On Wed, Aug 28, 2013 at 05:33:49PM +0800, Xiao Guangrong wrote:
> > Or what if desc is moved to another rmap, but then it
> > is moved back to initial rmap (but another place in the desc list) so
> > the check here will not catch that we need to restart walking?
>
> It is okay. We always add the n
On 08/28/2013 05:46 PM, Gleb Natapov wrote:
> On Wed, Aug 28, 2013 at 05:33:49PM +0800, Xiao Guangrong wrote:
>>> Or what if desc is moved to another rmap, but then it
>>> is moved back to initial rmap (but another place in the desc list) so
>>> the check here will not catch that we need to restart
On Wed, Aug 28, 2013 at 06:13:43PM +0800, Xiao Guangrong wrote:
> On 08/28/2013 05:46 PM, Gleb Natapov wrote:
> > On Wed, Aug 28, 2013 at 05:33:49PM +0800, Xiao Guangrong wrote:
> >>> Or what if desc is moved to another rmap, but then it
> >>> is moved back to initial rmap (but another place in the
On 08/28/2013 06:49 PM, Gleb Natapov wrote:
> On Wed, Aug 28, 2013 at 06:13:43PM +0800, Xiao Guangrong wrote:
>> On 08/28/2013 05:46 PM, Gleb Natapov wrote:
>>> On Wed, Aug 28, 2013 at 05:33:49PM +0800, Xiao Guangrong wrote:
> Or what if desc is moved to another rmap, but then it
> is moved
On 08/28/2013 01:45 AM, Andrew Jones wrote:
>> What I'm more worried about is what number is libvirt supposed to show
>> to the end user, and should libvirt enforce the lower recommended max,
>> or the larger kernel absolute max? Which of the two values does the QMP
>> 'MachineInfo' type return in
Il 28/08/2013 04:52, Marcelo Tosatti ha scritto:
> On Thu, Aug 22, 2013 at 07:05:20PM +0200, Paolo Bonzini wrote:
>> Il 20/08/2013 20:20, Marcelo Tosatti ha scritto:
>>>
>>> The offset to add to the hosts monotonic time, kvmclock_offset, is
>>> calculated against the monotonic time at KVM_SET_CLOCK
Hello everyone,
I started a thread on this list on July 12, named "AMD integrated
graphics passthrough to KVM guest," so if you should have a deja-vu,
that's probably why, since the heart of the problem is still the same.
I've got an AMD A10 6800 APU with integrated graphics, running on aan
ASRoc
On Wed, Aug 28, 2013 at 08:15:36PM +0800, Xiao Guangrong wrote:
> On 08/28/2013 06:49 PM, Gleb Natapov wrote:
> > On Wed, Aug 28, 2013 at 06:13:43PM +0800, Xiao Guangrong wrote:
> >> On 08/28/2013 05:46 PM, Gleb Natapov wrote:
> >>> On Wed, Aug 28, 2013 at 05:33:49PM +0800, Xiao Guangrong wrote:
>
On 17.07.2013, at 17:10, Thadeu Lima de Souza Cascardo wrote:
> err was overwritten by a previous function call, and checked to be 0. If
> the following page allocation fails, 0 is going to be returned instead
> of -ENOMEM.
>
> Signed-off-by: Thadeu Lima de Souza Cascardo
Thanks, applied to kv
On 05.08.2013, at 07:50, Chen Gang wrote:
> On 08/05/2013 12:34 PM, Paul Mackerras wrote:
>> On Mon, Jul 22, 2013 at 02:32:35PM +0800, Chen Gang wrote:
'rmls' is 'unsigned long', lpcr_rmls() will return negative number when
failure occurs, so it need a type cast for comparing.
>>>
From: Liu Jinsong
This patch is to fix the bug https://bugs.launchpad.net/qemu-kvm/+bug/1207623
IA32_FEATURE_CONTROL is pointless if not expose VMX or SMX bits to
cpuid.1.ecx of vcpu. Current qemu-kvm will error return when kvm_put_msrs
or kvm_get_msrs.
Signed-off-by: Liu Jinsong
Signed-off-by
From: Wei Yang
get_real_device() has 5 parameters with the last 4 is contained in the first
structure.
This patch removes the last 4 parameters and directly use them from the first
parameter.
Acked-by: Alex Williamson
Signed-off-by: Wei Yang
Signed-off-by: Paolo Bonzini
---
hw/i386/kvm/pci-
From: Paolo Bonzini
Non-KVM targets fail compilation on the uq/master branch.
Fix the prototype of kvm_irqchip_add_irqfd_notifier to match
the one in kvm-all.c.
Signed-off-by: Paolo Bonzini
Signed-off-by: Gleb Natapov
---
kvm-stub.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Anthony,
This obsoletes "[PULL v2 0/9] KVM changes for 2013-08-23"
The following changes since commit f03d07d4683b2e8325a7cb60b4e14b977b1a869c:
Merge remote-tracking branch 'quintela/migration.next' into staging
(2013-07-23 10:57:23 -0500)
are available in the git repository at:
git://gi
From: Paolo Bonzini
Signed-off-by: Paolo Bonzini
---
target-i386/cpu.h | 192 ++---
1 file changed, 96 insertions(+), 96 deletions(-)
diff --git a/target-i386/cpu.h b/target-i386/cpu.h
index 3a52f94..af4c0f7 100644
--- a/target-i386/cpu.h
+++ b/
From: Vincenzo Maffione
Added an EventNotifier* parameter to
kvm-all.c:kvm_irqchip_add_irqfd_notifier(), in order to give KVM
another eventfd to be used as "resamplefd". See the documentation
in the linux kernel sources in Documentation/virtual/kvm/api.txt
(section 4.75) for more details.
When th
From: Marcelo Tosatti
maxcpus, which specifies the maximum number of hotpluggable CPUs,
should not exceed KVM's vcpu limit.
Signed-off-by: Marcelo Tosatti
[Reword message. - Paolo]
Signed-off-by: Paolo Bonzini
---
kvm-all.c |7 +++
1 file changed, 7 insertions(+)
diff --git a/kvm-all
From: Arthur Chunqi Li
The recent KVM patch adds IA32_FEATURE_CONTROL support. QEMU needs
to clear this MSR when reset vCPU and keep the value of it when
migration. This patch add this feature.
Signed-off-by: Arthur Chunqi Li
Signed-off-by: Gleb Natapov
---
target-i386/cpu.h |2 ++
ta
From: Jan Kiszka
Now that cpu_in/out is just a wrapper around address_space_rw, we can
also call the latter directly. As host endianness == guest endianness,
there is no need for the memory access helpers st*_p/ld*_p as well.
Signed-off-by: Jan Kiszka
Signed-off-by: Paolo Bonzini
---
kvm-all.
From: Marcelo Tosatti
The configuration of the timer represented by MSR_IA32_TSCDEADLINE depends on:
- APIC LVT Timer register.
- TSC value.
Change the order to respect the dependency.
Signed-off-by: Marcelo Tosatti
Signed-off-by: Paolo Bonzini
---
target-i386/kvm.c | 29 +
On Wed, 2013-08-28 at 15:11 +0200, Gustav Sorenson wrote:
> Hello everyone,
>
> I started a thread on this list on July 12, named "AMD integrated
> graphics passthrough to KVM guest," so if you should have a deja-vu,
> that's probably why, since the heart of the problem is still the same.
>
> I'v
From: Paolo Bonzini
Reviewed-by: Gleb Natapov
Signed-off-by: Paolo Bonzini
---
target-i386/cpu.h | 23
target-i386/kvm.c | 93 ++---
target-i386/machine.c | 44 +++
3 files changed, 155 insertions(+), 5
On Tue, Aug 27, 2013 at 11:55:29PM -0300, Marcelo Tosatti wrote:
>
> The offset to add to the hosts monotonic time, kvmclock_offset, is
> calculated against the monotonic time at KVM_SET_CLOCK ioctl time.
>
> Request a master clock update at this time, to reduce a potentially
> unbounded differen
Having PCIe/PCI-X capability isn't enough to assume that there are
extended capabilities. Both specs define that the first capability
header is all zero if there are no extended capabilities. Testing
for this avoids an erroneous message about hiding capability 0x0 at
offset 0x100.
Signed-off-by:
Hi Alex,
thanks for your answer.
Do you happen to know someone who might be able to judge whether or
not the radeon driver could be patched to support passthrough? Also,
could you please point me to the fixes to i915 you mentioned? I think
I might write to the radeon list to see whether they have
On Wed, 2013-08-28 at 17:12 +0200, Gustav Sorenson wrote:
> Hi Alex,
>
> thanks for your answer.
>
> Do you happen to know someone who might be able to judge whether or
> not the radeon driver could be patched to support passthrough? Also,
> could you please point me to the fixes to i915 you ment
Hi Alex,
thanks for the info you provided, although I have to admit I didn't
understand all of it - just so you don't overestimate my knowledge. :)
Here's the output you requested:
[0.32] vgaarb: device added:
PCI::00:01.0,decodes=io+mem,owns=io+mem,locks=none
[0.321120] vgaarb:
On Wed, 2013-08-28 at 18:29 +0200, Gustav Sorenson wrote:
> Hi Alex,
>
> thanks for the info you provided, although I have to admit I didn't
> understand all of it - just so you don't overestimate my knowledge. :)
>
> Here's the output you requested:
>
> [0.32] vgaarb: device added:
> PC
On 2013-08-28 16:28, Lluís Vilanova wrote:
> Hi,
>
> I want to get the following setup, but don't know how (or if it's even
> possible):
>
> * A guest VM with two AHCI controllers, with one device each. One of the AHCI
> controllers provides the VM's disk ("system"), while the other provides
>
Hello,
yes, 1:00.0 is the GTX 660, and yes, I'm running X on the host.
When I boot into runlevel 1 (on Mint, which is Debian-based, so that
corresponds to a single-user runlevel without X, although I saw a
not-very-fancy boot splashscreen), this is what dmesg | grep -i vga
gives me:
[0.00
On 08/26/2013 03:48:36 AM, Raghavendra K T wrote:
KVM_HC_KICK_CPU hypercall added to wakeup halted vcpu in paravirtual
spinlock
enabled guest.
KVM_FEATURE_PV_UNHALT enables guest to check whether pv spinlock can
be enabled
in guest.
Thanks Vatsa for rewriting KVM_HC_KICK_CPU
Cc: Rob Landl
On Wed, 2013-08-28 at 19:42 +0200, Gustav Sorenson wrote:
> Hello,
>
> yes, 1:00.0 is the GTX 660, and yes, I'm running X on the host.
> When I boot into runlevel 1 (on Mint, which is Debian-based, so that
> corresponds to a single-user runlevel without X, although I saw a
> not-very-fancy boot sp
On 2013-08-28 20:12, Lluís Vilanova wrote:
> Jan Kiszka writes:
> [...]
>>> Is it possible to give a nested guest direct access to a device on the
>>> guest?
>>> (more specifically, an AHCI controller).
>
>> Nope, we are lacking support for emulating or (securely) forwarding
>> VT-d/IOMMU feature
Jan Kiszka writes:
[...]
>> Is it possible to give a nested guest direct access to a device on the guest?
>> (more specifically, an AHCI controller).
> Nope, we are lacking support for emulating or (securely) forwarding
> VT-d/IOMMU features to the first level guest. Would be cool to have,
> just
Jan Kiszka writes:
> On 2013-08-28 20:12, Lluís Vilanova wrote:
>> Jan Kiszka writes:
>> [...]
Is it possible to give a nested guest direct access to a device on the
guest?
(more specifically, an AHCI controller).
>>
>>> Nope, we are lacking support for emulating or (securely) for
Hello Alex,
> Ok, so it's probably X. You might be able to start your guest from here
> and get VGA through the gtx660 (assuming nothing else is broken with
> radeon VGA arbiter support). You could also run startx to confirm that
> it's X doing all those VGA arbiter writes. Thanks,
After I iss
On Tue, Aug 20, 2013 at 02:31:57PM -0700, Andrew Morton wrote:
> On Fri, 16 Aug 2013 23:09:06 + "Nicholas A. Bellinger"
> wrote:
> > + /*
> > +* Bitmap of cpus that (may) have tags on their percpu freelists:
> > +* steal_tags() uses this to decide when to steal tags, and which cpus
Fixup patch, addressing Andrew's review feedback:
Signed-off-by: Kent Overstreet
---
include/linux/idr.h | 2 +-
lib/idr.c | 38 +-
2 files changed, 22 insertions(+), 18 deletions(-)
diff --git a/include/linux/idr.h b/include/linux/idr.h
index f0db
On Wed, 28 Aug 2013 12:53:17 -0700 Kent Overstreet wrote:
> > > + while (1) {
> > > + spin_lock(&pool->lock);
> > > +
> > > + /*
> > > + * prepare_to_wait() must come before steal_tags(), in case
> > > + * percpu_ida_free() on another cpu flips a bit in
> > > +
On Wed, 28 Aug 2013 12:55:17 -0700 Kent Overstreet wrote:
> Fixup patch, addressing Andrew's review feedback:
Looks reasonable.
> lib/idr.c | 38 +-
I still don't think it should be in this file.
You say that some as-yet-unmerged patches will tie
On Wed, Aug 28, 2013 at 01:23:32PM -0700, Andrew Morton wrote:
> On Wed, 28 Aug 2013 12:53:17 -0700 Kent Overstreet wrote:
>
> > > > + while (1) {
> > > > + spin_lock(&pool->lock);
> > > > +
> > > > + /*
> > > > +* prepare_to_wait() must come befo
On Wed, 28 Aug 2013 13:44:54 -0700 Kent Overstreet wrote:
> > > > What guarantees that this wait will terminate?
> > >
> > > It seems fairly clear to me from the break statement a couple lines up;
> > > if we were passed __GFP_WAIT we terminate iff we succesfully allocated a
> > > tag. If we wer
On Wed, Aug 28, 2013 at 01:25:50PM -0700, Andrew Morton wrote:
> On Wed, 28 Aug 2013 12:55:17 -0700 Kent Overstreet wrote:
>
> > Fixup patch, addressing Andrew's review feedback:
>
> Looks reasonable.
>
> > lib/idr.c | 38 +-
>
> I still don't thin
On Wed, 28 Aug 2013 14:00:10 -0700 Kent Overstreet wrote:
> On Wed, Aug 28, 2013 at 01:25:50PM -0700, Andrew Morton wrote:
> > On Wed, 28 Aug 2013 12:55:17 -0700 Kent Overstreet
> > wrote:
> >
> > > Fixup patch, addressing Andrew's review feedback:
> >
> > Looks reasonable.
> >
> > > lib/id
On Wed, Aug 28, 2013 at 01:50:42PM -0700, Andrew Morton wrote:
> On Wed, 28 Aug 2013 13:44:54 -0700 Kent Overstreet wrote:
>
> > > > > What guarantees that this wait will terminate?
> > > >
> > > > It seems fairly clear to me from the break statement a couple lines up;
> > > > if we were passed
On Wed, 28 Aug 2013 14:12:17 -0700 Kent Overstreet wrote:
> How's this look?
>
> diff --git a/lib/idr.c b/lib/idr.c
> index 15c021c..a3f8e9a 100644
> --- a/lib/idr.c
> +++ b/lib/idr.c
> @@ -1288,6 +1288,11 @@ static inline unsigned alloc_local_tag(struct
> percpu_ida *pool,
> * Safe to be cal
On Wed, Aug 28, 2013 at 02:10:19PM -0700, Andrew Morton wrote:
> On Wed, 28 Aug 2013 14:00:10 -0700 Kent Overstreet wrote:
>
> > On Wed, Aug 28, 2013 at 01:25:50PM -0700, Andrew Morton wrote:
> > > On Wed, 28 Aug 2013 12:55:17 -0700 Kent Overstreet
> > > wrote:
> > >
> > > > Fixup patch, addre
On Wed, 28 Aug 2013 14:23:58 -0700 Kent Overstreet wrote:
> > I found things to be quite the opposite - it took 5 minutes of staring,
> > head-scratching, double-checking and penny-dropping before I was
> > confident that the newly-added code actually has nothing at all to do
> > with the current
On 06.08.2013, at 06:16, Paul Mackerras wrote:
> Currently PR-style KVM keeps the volatile guest register values
> (R0 - R13, CR, LR, CTR, XER, PC) in a shadow_vcpu struct rather than
> the main kvm_vcpu struct. For 64-bit, the shadow_vcpu exists in two
> places, a kmalloc'd struct and in the PA
On 06.08.2013, at 06:18, Paul Mackerras wrote:
> This reworks kvmppc_mmu_book3s_64_xlate() to make it check the large
> page bit in the hashed page table entries (HPTEs) it looks at, and
> to simplify and streamline the code. The checking of the first dword
> of each HPTE is now done with a sing
On 06.08.2013, at 06:14, Paul Mackerras wrote:
> Currently the code assumes that once we load up guest FP/VSX or VMX
> state into the CPU, it stays valid in the CPU registers until we
> explicitly flush it to the thread_struct. However, on POWER7,
> copy_page() and memcpy() can use VMX. These f
On 06.08.2013, at 06:15, Paul Mackerras wrote:
> It turns out that if we exit the guest due to a hcall instruction (sc 1),
> and the loading of the instruction in the guest exit path fails for any
> reason, the call to kvmppc_ld() in kvmppc_get_last_inst() fetches the
> instruction after the hcal
On 06.08.2013, at 06:13, Paul Mackerras wrote:
> Commit 8e44ddc3f3 ("powerpc/kvm/book3s: Add support for H_IPOLL and
> H_XIRR_X in XICS emulation") added a call to get_tb() but didn't
> include the header that defines it, and on some configs this means
> book3s_xics.c fails to compile:
>
> arch/
On 06.08.2013, at 06:18, Paul Mackerras wrote:
> This adds the code to interpret 64k HPTEs in the guest hashed page
> table (HPT), 64k SLB entries, and to tell the guest about 64k pages
> in kvm_vm_ioctl_get_smmu_info(). Guest 64k pages are still shadowed
> by 4k pages.
>
> This also adds anoth
On 06.08.2013, at 06:19, Paul Mackerras wrote:
> Currently, PR KVM uses 4k pages for the host-side mappings of guest
> memory, regardless of the host page size. When the host page size is
> 64kB, we might as well use 64k host page mappings for guest mappings
> of 64kB and larger pages and for gu
On 8/26/2013 8:04 AM, Gleb Natapov wrote:
> On Sun, Aug 25, 2013 at 09:26:47PM -0400, Chris Metcalf wrote:
>> On 8/25/2013 7:39 AM, Gleb Natapov wrote:
>>> On Mon, Aug 12, 2013 at 04:24:11PM -0400, Chris Metcalf wrote:
This change provides the initial framework support for KVM on tilegx.
This commit enables a special configure option to build the kernel to
run at PL1. In this mode, the client can run under a KVM host kernel;
it can also run under the older Tilera hypervisor that ran the
operating system at PL1 by default.
The PL1 kernel runs with half the virtual address space an
This change enables support for a virtio-based console,
network support, and block driver support.
We remove some debug code in relocate_kernel_64.S that made raw
calls to the hv_console_putc Tilera hypervisor API, since everything
now should funnel through the early_hv_write() API.
Signed-off-by
On Wed, 2013-08-28 at 11:21 +0300, Gleb Natapov wrote:
> On Wed, Aug 28, 2013 at 04:08:10PM +0800, Chen Fan wrote:
> > If we want to remove a vcpu from vm, we should not be only to
> > put kvm, we need to decrease online vcpus and free struct kvm_vcpu
> > when closing a vcpu file descriptor.
> >
>
On Thu, Aug 29, 2013 at 11:06:47AM +0800, chenfan wrote:
> On Wed, 2013-08-28 at 11:21 +0300, Gleb Natapov wrote:
> > On Wed, Aug 28, 2013 at 04:08:10PM +0800, Chen Fan wrote:
> > > If we want to remove a vcpu from vm, we should not be only to
> > > put kvm, we need to decrease online vcpus and fre
Am 29.08.2013 04:09, schrieb Chen Fan:
> After ACPI get a signal to eject a vcpu, then it will notify
> the vcpu thread of needing to exit, before the vcpu exiting,
> will release the vcpu related objects.
>
> Signed-off-by: Chen Fan
> ---
> cpus.c | 36
On Thu, Aug 29, 2013 at 12:56:40AM +0200, Alexander Graf wrote:
>
> On 06.08.2013, at 06:18, Paul Mackerras wrote:
>
> > #ifdef CONFIG_PPC_BOOK3S_64
> > - /* default to book3s_64 (970fx) */
> > + /*
> > +* Default to the same as the host if we're on a POWER7[+],
> > +* otherwise defau
On Thu, Aug 29, 2013 at 12:00:53AM +0200, Alexander Graf wrote:
>
> On 06.08.2013, at 06:16, Paul Mackerras wrote:
>
> > kvm_start_lightweight:
> > + /* Copy registers into shadow vcpu so we can access them in real mode */
> > + GET_SHADOW_VCPU(r3)
> > + bl FUNC(kvmppc_copy_to_svcpu)
>
On Thu, Aug 29, 2013 at 01:24:04AM +0200, Alexander Graf wrote:
>
> On 06.08.2013, at 06:19, Paul Mackerras wrote:
>
> > +#ifdef CONFIG_PPC_64K_PAGES
> > + /*
> > +* Mark this as a 64k segment if the host is using
> > +* 64k pages, the host MMU supports 64k pages and
> > +* the gues
On 08/28/2013 09:36 PM, Gleb Natapov wrote:
> On Wed, Aug 28, 2013 at 08:15:36PM +0800, Xiao Guangrong wrote:
>> On 08/28/2013 06:49 PM, Gleb Natapov wrote:
>>> On Wed, Aug 28, 2013 at 06:13:43PM +0800, Xiao Guangrong wrote:
On 08/28/2013 05:46 PM, Gleb Natapov wrote:
> On Wed, Aug 28, 201
92 matches
Mail list logo
