On 10/31/2012 12:22 PM, Alexander Graf wrote:
On 31.10.2012, at 02:32, Marcelo Tosatti mtosa...@redhat.com wrote:
On Tue, Oct 30, 2012 at 11:02:13AM +0100, Alexander Graf wrote:
Hi Avi / Marcelo,
This is my current patch queue for ppc. Please pull.
Headline changes are:
* Fix
On 10/31/2012 12:34 PM, Alexander Graf wrote:
On 31.10.2012, at 11:26, Avi Kivity a...@redhat.com wrote:
On 10/31/2012 12:22 PM, Alexander Graf wrote:
On 31.10.2012, at 02:32, Marcelo Tosatti mtosa...@redhat.com wrote:
On Tue, Oct 30, 2012 at 11:02:13AM +0100, Alexander Graf wrote
On 10/18/2012 03:49 PM, Alexander Graf wrote:
On 18.10.2012, at 15:48, Christoffer Dall wrote:
On Wed, Oct 17, 2012 at 7:58 PM, Benjamin Herrenschmidt
b...@kernel.crashing.org wrote:
On Thu, 2012-10-18 at 09:10 +1100, Paul Mackerras wrote:
With the XICS, there are two types of irqchip:
On 10/16/2012 10:03 PM, Anthony Liguori wrote:
This forces userspace to dedicate a thread for the HPT.
If no changes are available, does read return a size 0? I don't think
it's necessary to support polling. The kernel should always be able to
respond to userspace here. The only catch
On 10/16/2012 11:52 PM, Paul Mackerras wrote:
On Tue, Oct 16, 2012 at 03:06:33PM +0200, Avi Kivity wrote:
On 10/16/2012 01:58 PM, Paul Mackerras wrote:
On Tue, Oct 16, 2012 at 12:06:58PM +0200, Avi Kivity wrote:
Does/should the fd support O_NONBLOCK and poll? (=waiting for an entry
On 10/16/2012 04:49 PM, Alexander Graf wrote:
If there is a lot of prioritization and/or queuing logic, then yes. But
what about MSI? Doesn't that have a direct path?
Nope. Well, yes, in a certain special case where the MPIC pushes the
interrupt vector on interrupt delivery into a special
On 10/16/2012 05:59 AM, Paul Mackerras wrote:
The mmu_notifier_retry() function, used to test whether any page
invalidations are in progress, currently takes a vcpu pointer, though
the code only needs the VM's struct kvm pointer. Forthcoming patches
to the powerpc Book3S HV code will need to
On 10/16/2012 06:01 AM, Paul Mackerras wrote:
A new ioctl, KVM_PPC_GET_HTAB_FD, returns a file descriptor. Reads on
this fd return the contents of the HPT (hashed page table), writes
create and/or remove entries in the HPT. There is a new capability,
KVM_CAP_PPC_HTAB_FD, to indicate the
On 10/15/2012 02:02 PM, Alexander Graf wrote:
In order to support vhost, we need to be able to support ioeventfd.
This patch set adds support for ioeventfd to PPC and makes it possible to
do so without implementing irqfd along the way, as it requires an in-kernel
irqchip which we don't have
On 10/16/2012 12:59 PM, Alexander Graf wrote:
On 16.10.2012, at 12:56, Avi Kivity wrote:
On 10/15/2012 02:02 PM, Alexander Graf wrote:
In order to support vhost, we need to be able to support ioeventfd.
This patch set adds support for ioeventfd to PPC and makes it possible to
do so
On 10/16/2012 01:58 PM, Paul Mackerras wrote:
On Tue, Oct 16, 2012 at 12:06:58PM +0200, Avi Kivity wrote:
On 10/16/2012 06:01 AM, Paul Mackerras wrote:
+4.78 KVM_PPC_GET_HTAB_FD
+
+Capability: KVM_CAP_PPC_HTAB_FD
+Architectures: powerpc
+Type: vm ioctl
+Parameters: Pointer to struct
On 10/16/2012 01:06 PM, Alexander Graf wrote:
On 16.10.2012, at 13:01, Avi Kivity wrote:
On 10/16/2012 12:59 PM, Alexander Graf wrote:
On 16.10.2012, at 12:56, Avi Kivity wrote:
On 10/15/2012 02:02 PM, Alexander Graf wrote:
In order to support vhost, we need to be able to support
On 10/05/2012 11:21 PM, Alexander Graf wrote:
Hi Avi / Marcelo,
Apparently I messed up while sending the pull request yesterday and didn't CC
kvm@vger. Do you want me to resend or is this good enough for you? :)
This is fine now you've copied the list. Do any of the small bug
fixes want to
On 10/07/2012 01:41 AM, Alexander Graf wrote:
SPRs on PowerPC are the equivalent to MSRs on x86. They usually
control behavior inside a core, so the best place to emulate them
traditionally has been the kernel side of kvm.
However, some SPRs should be emulated by user space. For example
the
On 10/07/2012 03:19 PM, Alexander Graf wrote:
On 07.10.2012, at 15:13, Avi Kivity wrote:
On 10/07/2012 01:41 AM, Alexander Graf wrote:
SPRs on PowerPC are the equivalent to MSRs on x86. They usually
control behavior inside a core, so the best place to emulate them
traditionally has been
On 10/07/2012 03:26 PM, Alexander Graf wrote:
Ah, yes. I forgot to add this exit to that section of the spec.
Patch submitted :).
Ugh, the whole point of finding problems in patches is that I don't have
to think about them for a while. Posting a new patch in a few minutes
negates this
On 10/07/2012 03:30 PM, Alexander Graf wrote:
Yup. The new APIC MSR registers would also have the same problem, right?
Which new APIC MSR registers?
I thought x2apic can be accessed through MSRs? If you want to emulate that in
user space, you need something similar.
It's emulated in
On 10/01/2012 12:59 PM, Alexander Graf wrote:
On 30.09.2012, at 13:29, Avi Kivity wrote:
On 09/27/2012 09:59 PM, Alexander Graf wrote:
Do you have the auto-autotest setup ready? I guess we can do it
manually until it is.
I do have a local autotest setup. Or what exactly are you
On 09/27/2012 09:59 PM, Alexander Graf wrote:
Do you have the auto-autotest setup ready? I guess we can do it
manually until it is.
I do have a local autotest setup. Or what exactly are you referring to?
Getting autotest to run automatically and produce readable reports, and
On 09/27/2012 06:03 PM, Marcelo Tosatti wrote:
On Tue, Sep 25, 2012 at 09:46:01AM +0200, Alexander Graf wrote:
On 23.08.2012, at 03:04, Scott Wood wrote:
We were only allocating half the bytes we need, which was made more
obvious by a recent fix to the memset in clear_tlb1_bitmap().
On 08/17/2012 09:39 PM, Marcelo Tosatti wrote:
Yes. Well, Avi mentioned earlier that there are users for change of GPA
base. But, if my understanding is correct, the code that emulates
change of BAR in QEMU is:
/* now do the real mapping */
if (r-addr != PCI_BAR_UNMAPPED)
On 08/13/2012 07:34 PM, Marcelo Tosatti wrote:
Avi, Gleb, Alex, do you know why it is necessary to support change of
GPA base again?
BAR moving around.
Without taking into consideration backwards compatibility, userspace
can first delete the slot and later create a new one.
Current qemu
On 08/15/2012 02:04 AM, Alexander Graf wrote:
From: Alan Cox a...@linux.intel.com
Put the parameters the right way around
Addresses https://bugzilla.kernel.org/show_bug.cgi?id=44031
Should this go to 3.6 (and backports etc.)?
--
error compiling committee.c: too many arguments to
On 08/15/2012 01:09 PM, Alexander Graf wrote:
On 15.08.2012, at 12:07, Avi Kivity wrote:
On 08/15/2012 02:04 AM, Alexander Graf wrote:
From: Alan Cox a...@linux.intel.com
Put the parameters the right way around
Addresses https://bugzilla.kernel.org/show_bug.cgi?id=44031
Should
On 08/09/2012 08:02 PM, Alexander Graf wrote:
On 09.08.2012, at 12:36, Avi Kivity a...@redhat.com wrote:
On 08/09/2012 01:34 PM, Takuya Yoshikawa wrote:
On Tue, 7 Aug 2012 12:57:13 +0200
Alexander Graf ag...@suse.de wrote:
+struct kvm_memory_slot *hva_to_memslot(struct kvm *kvm
On 08/12/2012 02:03 PM, Alexander Graf wrote:
Well, for now I just dropped the whole thing. In general, chances are pretty
good that an HVA we get notified on with mmu notifiers is representing guest
memory. And flushing a few times too often shouldn't hurt.
That is not the case, actually.
On 08/09/2012 01:34 PM, Takuya Yoshikawa wrote:
On Tue, 7 Aug 2012 12:57:13 +0200
Alexander Graf ag...@suse.de wrote:
+struct kvm_memory_slot *hva_to_memslot(struct kvm *kvm, hva_t hva)
+{
+struct kvm_memslots *slots = kvm_memslots(kvm);
+struct kvm_memory_slot *memslot;
+
+
On 08/08/2012 12:09 AM, Benjamin Herrenschmidt wrote:
On Tue, 2012-08-07 at 16:13 +0300, Avi Kivity wrote:
Peter has started to fix up this naming mess in qemu. I guess we should
do the same for the kernel (except for ABIs) and document it, because it
keeps generating confusion.
Ok so
On 08/08/2012 03:49 AM, David Gibson wrote:
We never have irqchip in kernel (because we haven't written that yet)
but we still sleep in-kernel for CEDE. I haven't spotted any problem
with that, but now I'm wondering if there is one, since x86 don't do
it in what seems like the analogous
On 08/08/2012 02:59 PM, David Gibson wrote:
No, you're correct. HLT could have been emulated in userspace, it just
wasn't. The correct statement is that HLT was arbitrarily chosen to be
emulated in userspace with the synchronous model, but the asynchronous
model forced it into the kernel.
On 08/06/2012 11:25 PM, Scott Wood wrote:
On 08/05/2012 04:00 AM, Avi Kivity wrote:
On 08/04/2012 01:32 AM, Benjamin Herrenschmidt wrote:
On Fri, 2012-08-03 at 15:05 -0300, Marcelo Tosatti wrote:
See kvm_arch_process_async_events() call to qemu_system_reset_request()
in target-i386/kvm.c
On 08/07/2012 04:32 AM, David Gibson wrote:
On Tue, Aug 07, 2012 at 06:57:57AM +1000, Benjamin Herrenschmidt wrote:
On Mon, 2012-08-06 at 13:13 +1000, David Gibson wrote:
So, I'm still trying to nut out the implications for H_CEDE, and think
if there are any other hypercalls that might want
On 08/07/2012 03:14 PM, David Gibson wrote:
On Tue, Aug 07, 2012 at 11:46:35AM +0300, Avi Kivity wrote:
On 08/07/2012 04:32 AM, David Gibson wrote:
On Tue, Aug 07, 2012 at 06:57:57AM +1000, Benjamin Herrenschmidt wrote:
On Mon, 2012-08-06 at 13:13 +1000, David Gibson wrote:
So, I'm still
On 08/07/2012 01:57 PM, Alexander Graf wrote:
The e500 target has lived without mmu notifiers ever since it got
introduced, but fails for the user space check on them with hugetlbfs.
So in order to get that one working, implement mmu notifiers in a
reasonably dumb fashion and be happy. On
On 08/07/2012 01:57 PM, Alexander Graf wrote:
Some archs need to ensure that their icache is flushed when mapping a new
page. Add a callback to the generic code for an arch to implement any cache
flush logic it may need.
Signed-off-by: Alexander Graf ag...@suse.de
---
virt/kvm/kvm_main.c
On 08/07/2012 04:44 PM, Alexander Graf wrote:
Is this the correct place? Who says the caller of hva_to_pfn() is going
to map it?
I don't think anyone is. However, we need the struct page, and all the
generic kvm mm code tries hard to hide it from its users. The alternative
would be
On 08/07/2012 05:08 PM, Alexander Graf wrote:
On 07.08.2012, at 15:58, Avi Kivity a...@redhat.com wrote:
On 08/07/2012 04:44 PM, Alexander Graf wrote:
Is this the correct place? Who says the caller of hva_to_pfn() is going
to map it?
I don't think anyone is. However, we need
On 08/07/2012 04:52 PM, Alexander Graf wrote:
+/* MMU Notifiers */
+
+int kvm_unmap_hva(struct kvm *kvm, unsigned long hva)
+{
+/* Is this a guest page? */
+if (!hva_to_memslot(kvm, hva))
+return 0;
+
+/*
+ * Flush all shadow tlb entries
On 08/07/2012 05:14 PM, Alexander Graf wrote:
On 07.08.2012, at 16:10, Avi Kivity a...@redhat.com wrote:
On 08/07/2012 05:08 PM, Alexander Graf wrote:
On 07.08.2012, at 15:58, Avi Kivity a...@redhat.com wrote:
On 08/07/2012 04:44 PM, Alexander Graf wrote:
Is this the correct
On 08/07/2012 05:24 PM, Alexander Graf wrote:
Pre-map? How?
In arch code before you install the page in a pte/tlbe.
So how do I get to the struct page in there?
pfn_to_page()
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the
On 08/01/2012 11:59 AM, Takuya Yoshikawa wrote:
This has been already discussed on other threads and the concept itself
is not so controversial.
But since I know that the last patch of this series conflicts with
Paul's recent work, I want to find a way to synchronize with his work
at this
On 08/02/2012 11:29 PM, Benjamin Herrenschmidt wrote:
On Thu, 2012-08-02 at 16:05 +0300, Avi Kivity wrote:
Yeah, we stumbled over this chunk as well. So you're saying we
should delay the reset by invoking a self-signal if we're in such an
operation?
Yes. Qemu of course already supports
On 08/04/2012 01:32 AM, Benjamin Herrenschmidt wrote:
On Fri, 2012-08-03 at 15:05 -0300, Marcelo Tosatti wrote:
See kvm_arch_process_async_events() call to qemu_system_reset_request()
in target-i386/kvm.c.
The whole thing is fragile, though: we rely on the order events
are processed
On 08/01/2012 11:59 AM, Takuya Yoshikawa wrote:
This has been already discussed on other threads and the concept itself
is not so controversial.
Looks good.
But since I know that the last patch of this series conflicts with
Paul's recent work, I want to find a way to synchronize with his
On 08/01/2012 06:17 AM, Benjamin Herrenschmidt wrote:
Hi Avi !
We identified a problem on powerpc which seems to actually be a generic
issue, and Alex suggested we propose a generic fix. I want to make sure
we are on the right track first before proposing an actual patch as we
would like
On 08/02/2012 03:59 PM, Alexander Graf wrote:
On 02.08.2012, at 14:35, Avi Kivity wrote:
On 08/01/2012 06:17 AM, Benjamin Herrenschmidt wrote:
Hi Avi !
We identified a problem on powerpc which seems to actually be a generic
issue, and Alex suggested we propose a generic fix. I want
On 07/11/2012 03:56 AM, Alexander Graf wrote:
Hi Avi,
This is my current patch queue for ppc. Please pull.
It contains the following changes:
* VERY IMPORTANT (please forward to -stable):
Fix H_CEDE with PR KVM and newer guest kernels
* Prepare some of the booke code for 64 bit
On 07/11/2012 03:56 AM, Alexander Graf wrote:
Hi Avi,
This is my current patch queue for ppc. Please pull.
It contains the following changes:
* VERY IMPORTANT (please forward to -stable):
Fix H_CEDE with PR KVM and newer guest kernels
If it's important please separate it and put
On 07/11/2012 03:56 AM, Alexander Graf wrote:
Hi Avi,
This is my current patch queue for ppc. Please pull.
* Book3S HV: Fix locks (should be in your tree already?)
Indeed it's in 3.5 already. The way to check it to look for it in
auto-next, which includes master, upstream, and next.
On 07/11/2012 06:38 PM, Alexander Graf wrote:
Hi Avi,
This is my current patch queue for ppc against master.
It contains an important bug fix which can lead to guest freezes when
using PAPR guests with PR KVM.
Please pull.
Thanks, pulled.
--
error compiling committee.c: too many
On 06/29/2012 04:46 AM, Takuya Yoshikawa wrote:
On Thu, 28 Jun 2012 20:53:47 +0300
Avi Kivity a...@redhat.com wrote:
Note: in the new code we could not use trace_kvm_age_page(), so we just
dropped the point from kvm_handle_hva_range().
Can't it be pushed to handler()?
Yes
On 07/01/2012 04:18 PM, Takuya Yoshikawa wrote:
On Sun, 01 Jul 2012 10:41:05 +0300
Avi Kivity a...@redhat.com wrote:
Note: in the new code we could not use trace_kvm_age_page(), so we just
dropped the point from kvm_handle_hva_range().
Can't it be pushed to handler()?
Yes
On 06/28/2012 06:45 AM, Takuya Yoshikawa wrote:
On Thu, 28 Jun 2012 11:12:51 +0800
Xiao Guangrong xiaoguangr...@linux.vnet.ibm.com wrote:
struct kvm_arch_memory_slot {
+ unsigned long *rmap_pde[KVM_NR_PAGE_SIZES - 1];
struct kvm_lpage_info *lpage_info[KVM_NR_PAGE_SIZES - 1];
};
On 06/28/2012 05:02 AM, Takuya Yoshikawa wrote:
When we invalidate a THP page, we call the handler with the same
rmap_pde argument 512 times in the following loop:
for each guest page in the range
for each level
unmap using rmap
This patch avoids these extra handler calls by
On 06/25/2012 03:26 PM, Mihai Caraman wrote:
Add KVM_SREGS_E_64 feature and EPCR spr support in get/set sregs
for 64-bit hosts.
Signed-off-by: Mihai Caraman mihai.cara...@freescale.com
---
arch/powerpc/kvm/booke.c | 14 ++
1 files changed, 14 insertions(+), 0 deletions(-)
On 06/25/2012 04:24 PM, Caraman Mihai Claudiu-B02008 wrote:
-Original Message-
From: Avi Kivity [mailto:a...@redhat.com]
Sent: Monday, June 25, 2012 4:00 PM
To: Caraman Mihai Claudiu-B02008
Cc: kvm-ppc@vger.kernel.org; k...@vger.kernel.org; linuxppc-
d...@lists.ozlabs.org; qemu
On 06/19/2012 04:46 PM, Takuya Yoshikawa wrote:
On Mon, 18 Jun 2012 15:11:42 +0300
Avi Kivity a...@redhat.com wrote:
Potential for improvement: don't do 512 iterations on same large page.
Something like
if ((gfn ^ prev_gfn) mask(level))
ret |= handler(...)
with clever
On 06/19/2012 01:50 PM, Alexander Graf wrote:
On 06.06.2012, at 17:52, Alexander Graf wrote:
On 06/06/2012 02:28 PM, Avi Kivity wrote:
On 06/01/2012 01:20 PM, Paul Mackerras wrote:
At the moment we call kvmppc_pin_guest_page() in kvmppc_update_vpa()
with two spinlocks held: the vcore lock
On 06/15/2012 02:31 PM, Takuya Yoshikawa wrote:
This restricts hva handling in mmu code and makes it easier to extend
kvm_handle_hva() so that it can treat a range of addresses later in this
patch series.
kvm_for_each_memslot(memslot, slots) {
- unsigned long start =
On 06/15/2012 02:32 PM, Takuya Yoshikawa wrote:
When guest's memory is backed by THP pages, MMU notifier needs to call
kvm_unmap_hva(), which in turn leads to kvm_handle_hva(), in a loop to
invalidate a range of pages which constitute one huge page:
for each guest page
for each
On 06/01/2012 01:20 PM, Paul Mackerras wrote:
At the moment we call kvmppc_pin_guest_page() in kvmppc_update_vpa()
with two spinlocks held: the vcore lock and the vcpu-vpa_update_lock.
This is not good, since kvmppc_pin_guest_page() calls down_read() and
get_user_pages_fast(), both of which
On 06/05/2012 04:58 AM, Anthony Liguori wrote:
On 06/05/2012 08:52 AM, Andreas Färber wrote:
Am 04.06.2012 07:46, schrieb Anthony Liguori:
On 05/22/2012 12:37 AM, Avi Kivity wrote:
Please pull from:
git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git uq/master
Pulled. Thanks
On 06/05/2012 12:02 PM, Anthony Liguori wrote:
On 06/05/2012 03:42 PM, Avi Kivity wrote:
On 06/05/2012 04:58 AM, Anthony Liguori wrote:
On 06/05/2012 08:52 AM, Andreas Färber wrote:
Am 04.06.2012 07:46, schrieb Anthony Liguori:
On 05/22/2012 12:37 AM, Avi Kivity wrote:
Please pull from
On 05/25/2012 06:12 AM, Benjamin Herrenschmidt wrote:
BTW. This is a qemu patch, and that hypercall isn't KVM related at all,
ie, it's implemented in qemu and is used with or without KVM, so
documenting it in the kernel tree makes little sense. Same goes with
H_RTAS.
I'll add a doc to
On 05/21/2012 10:24 AM, Benjamin Herrenschmidt wrote:
This adds a kvm-specific hypervisor call to the pseries machine
which allows to do what amounts to memmove, memcpy and xor over
regions of physical memory such as the framebuffer.
This is the simplest way to get usable framebuffer speed
On 05/21/2012 01:04 PM, Benjamin Herrenschmidt wrote:
On Mon, 2012-05-21 at 12:47 +0300, Avi Kivity wrote:
On 05/21/2012 10:24 AM, Benjamin Herrenschmidt wrote:
This adds a kvm-specific hypervisor call to the pseries machine
which allows to do what amounts to memmove, memcpy and xor over
On 05/21/2012 02:48 PM, Benjamin Herrenschmidt wrote:
On Mon, 2012-05-21 at 13:07 +0300, Avi Kivity wrote:
Now I'm adding another one, so yes, it's looking like a trend :-) I'll
look into it, at this stage with only those two, adding some comments in
the header might be plenty enough
On 05/16/2012 04:05 PM, Alexander Graf wrote:
Hi Avi,
There are a few bugs in 3.4 that really should be fixed before people can
be all happy and fuzzy about KVM on PowerPC. These fixes are:
* fix POWER7 bare metal with PR=y
* fix deadlock on HV=y book3s_64 mode in low memory cases
*
On 05/16/2012 04:28 PM, Alexander Graf wrote:
On 05/16/2012 03:23 PM, Avi Kivity wrote:
On 05/16/2012 04:05 PM, Alexander Graf wrote:
Hi Avi,
There are a few bugs in 3.4 that really should be fixed before
people can
be all happy and fuzzy about KVM on PowerPC. These fixes are:
* fix
On 05/10/2012 08:49 PM, Alexander Graf wrote:
+#if defined(TARGET_PPC64)
+if (def-sps)
+memcpy(env-sps, def-sps, sizeof(*def-sps));
I never know if *def-... would dereference def or the complete
construct.
'man operator'
How about sizeof(env-sps)?
How about
env-sps =
On 04/30/2012 07:40 AM, Paul Mackerras wrote:
On Sun, Apr 29, 2012 at 04:37:33PM +0300, Avi Kivity wrote:
How difficult is it to have the kernel resize the HPT on demand?
Quite difficult, unfortunately. The guest kernel knows the size of
the HPT, and the paravirt interface for updating
On 04/30/2012 02:54 PM, Paul Mackerras wrote:
It's not practical to grow the HPT after the guest has started
booting. It is possible to have two HPTs: one that the guest sees,
which can be in pageable memory, and another shadow HPT that the
hardware uses, which has to be in
On 04/17/2012 09:26 AM, Xiao Guangrong wrote:
On 04/16/2012 11:49 PM, Takuya Yoshikawa wrote:
Although O(1) is actually O(1) for GET_DIRTY_LOG thread, it adds some
overheads to page fault handling. We may need to hold mmu_lock for properly
handling O(1)'s write protection and ~500 write
On 04/17/2012 03:37 PM, Takuya Yoshikawa wrote:
On Tue, 17 Apr 2012 10:51:40 +0300
Avi Kivity a...@redhat.com wrote:
That's true with the write protect everything approach we use now. But
it's not true with range-based write protection, where you issue
GET_DIRTY_LOG on a range of pages
On 04/17/2012 05:54 PM, Takuya Yoshikawa wrote:
On Tue, 17 Apr 2012 15:41:39 +0300
Avi Kivity a...@redhat.com wrote:
Since there are many known algorithms to predict hot memory pages,
the userspace will be able to tune the frequency of GET_DIRTY_LOG for such
parts not to get too many
On 04/16/2012 06:49 PM, Takuya Yoshikawa wrote:
This doesn't work for EPT, which lacks a dirty bit. But we can emulate
it: take a free bit and call it spte.NOTDIRTY, when it is set, we also
clear spte.WRITE, and teach the mmu that if it sees spte.NOTDIRTY and
can just set spte.WRITE and
On 04/06/2012 03:02 PM, Takuya Yoshikawa wrote:
On Thu, 05 Apr 2012 20:02:44 +0300
Avi Kivity a...@redhat.com wrote:
In a recent conversation, Linus persuaded me that it's time for change
in our git workflow; the following will bring it in line with the
current practices of most trees
On 04/05/2012 08:02 PM, Avi Kivity wrote:
I'll publish the new branches tomorrow, with any luck.
There wasn't any luck, so it's only ready today. To allow chance for
review, I'm publishing next as next-candidate.
Paul/Alex, please review the powerpc bits. Specifically:
system.h is gone, so
On 04/03/2012 03:22 PM, Paul Mackerras wrote:
On Tue, Apr 03, 2012 at 10:03:05PM +1000, Paul Mackerras wrote:
The following changes since commit 592f5d87b3feee9d60411f19d583038c0c7670ad:
OK, I messed up the git request-pull command. The request should have
looked like this:
The
In a recent conversation, Linus persuaded me that it's time for change
in our git workflow; the following will bring it in line with the
current practices of most trees.
The current 'master' branch will be abandoned (still available for
reviewing history). The new branch structure will be as
On 04/03/2012 03:22 PM, Paul Mackerras wrote:
On Tue, Apr 03, 2012 at 10:03:05PM +1000, Paul Mackerras wrote:
The following changes since commit 592f5d87b3feee9d60411f19d583038c0c7670ad:
OK, I messed up the git request-pull command. The request should have
looked like this:
The
On 03/28/2012 11:04 PM, Benjamin Herrenschmidt wrote:
On Wed, 2012-03-28 at 12:51 +0200, Avi Kivity wrote:
Ah, then it's not a guest problem, it's how the chip was designed.
Newer chips do allow a workaround (GR31 bit 6):
6 System Source Location (Revision A): If this bit is ‘1
On 03/29/2012 07:15 AM, Takuya Yoshikawa wrote:
On Wed, 28 Mar 2012 11:37:38 +0200
Avi Kivity a...@redhat.com wrote:
Now I see that x86 just seems to flush everything, which is quite heavy
handed considering how often cirrus does it, but maybe it doesn't have a
choice (lack of reverse
On 03/29/2012 05:21 PM, Takuya Yoshikawa wrote:
On Thu, 29 Mar 2012 11:44:12 +0200
Avi Kivity a...@redhat.com wrote:
Even without using reverse mapping we can restrict that flush easily:
http://www.spinics.net/lists/kvm/msg68695.html
[PATCH] KVM: Avoid zapping unrelated shadows
On 03/28/2012 09:24 AM, Benjamin Herrenschmidt wrote:
So I was chasing a bug today when I realized that some drivers in qemu
do interesting things with memory regions.
They're usually called devices, drivers live in the guest.
More specifically, cirrus emulation constantly flips the linear
On 03/28/2012 11:59 AM, Benjamin Herrenschmidt wrote:
On Wed, 2012-03-28 at 11:37 +0200, Avi Kivity wrote:
Now I see that x86 just seems to flush everything, which is quite heavy
handed considering how often cirrus does it, but maybe it doesn't have a
choice (lack of reverse mapping
On 03/28/2012 12:17 PM, Benjamin Herrenschmidt wrote:
On Wed, 2012-03-28 at 12:05 +0200, Avi Kivity wrote:
That's strange, the cirrus BAR allows the framebuffer and bitblt region
to coexist:
-7ffe (prio 0, RW): pci
000a-000b (prio
On 03/15/2012 02:10 PM, Alexander Graf wrote:
Hi Avi,
This is my current patch queue for ppc. Please pull.
Pulled, thanks.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line unsubscribe kvm-ppc in
the body of a message to
On 03/16/2012 09:55 AM, Benjamin Herrenschmidt wrote:
This is necessary for qemu to be able to pass the right information
to the guest, as the supported sizes and encodings can vary depending
on the machine, the type of KVM used (PR vs HV) and the version of KVM
Signed-off-by: Benjamin
On 02/16/2012 10:41 PM, Scott Wood wrote:
Sharing the data structures is not need. Simply synchronize them before
lookup, like we do for ordinary registers.
Ordinary registers are a few bytes. We're talking of dozens of kbytes here.
A TLB way is a few dozen bytes, no?
I think you
On 02/17/2012 02:19 AM, Alexander Graf wrote:
Or we try to be less clever unless we have a really compelling reason.
qemu monitor and gdb support aren't compelling reasons to optimize.
The goal here was simplicity with a grain of performance concerns.
Shared memory is simple in one
On 02/16/2012 03:55 PM, Danny Kukawka wrote:
arch/powerpc/kvm/book3s_hv.c: included 'linux/sched.h' twice,
remove the duplicate.
Thanks, applied.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line unsubscribe kvm-ppc in
the body of
On 02/16/2012 09:34 PM, Alexander Graf wrote:
On 16.02.2012, at 20:24, Avi Kivity wrote:
On 02/15/2012 04:08 PM, Alexander Graf wrote:
Well, the scatter/gather registers I proposed will give you just one
register or all of them.
One register is hardly any use. We either need all
On 02/15/2012 01:57 PM, Alexander Graf wrote:
Is an extra syscall for copying TLB entries to user space prohibitively
expensive?
The copying can be very expensive, yes. We want to have the possibility of
exposing a very large TLB to the guest, in the order of multiple kentries.
Every
On 02/07/2012 03:08 AM, Alexander Graf wrote:
I don't like the idea too much. On s390 and ppc we can set other vcpu's
interrupt status. How would that work in this model?
It would be a vm-wide syscall. You can also do that on x86 (through
KVM_IRQ_LINE).
I really do like the ioctl model
On 02/07/2012 03:40 PM, Alexander Graf wrote:
Not sure we'll ever get there. For PPC, it will probably take another 1-2
years until we get the 32-bit targets stabilized. By then we will have new 64-bit
support though. And then the next gen will come out giving us even more new
constraints.
On 01/23/2012 12:42 PM, Takuya Yoshikawa wrote:
The last one is an RFC patch:
I think it is better to refactor the rmap things, if needed, before
other architectures than x86 starts large pages support.
Not commenting about the meat of the patches (not sufficiently recovered
yet), but other
On 01/16/2012 03:18 PM, Alexander Graf wrote:
Avi?
ACK!
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line unsubscribe kvm-ppc in
the body of a message to majord...@vger.kernel.org
More majordomo info at
On 01/12/2012 01:39 AM, Alexander Graf wrote:
On 12.01.2012, at 00:37, Scott Wood wrote:
Instead of keeping separate copies of struct kvm_vcpu_arch_shared (one in
the code, one in the docs) that inevitably fail to be kept in sync
(already sr[] is missing from the doc version), just point
On 01/05/2012 06:07 AM, Alexander Graf wrote:
Hrm. Interesting idea. So you would basically reduce everything to __u64 by
padding smaller registers and splitting bigger ones into separate IDs? That
really is appealing, but might uglify the code quite a bit when remerging
bigger
1 - 100 of 316 matches
Mail list logo
