Jes Sorensen wrote:
Zhang, Xiantao wrote:
Hi Jes, Good news! On my machine, without the patch, smp guest can't
build one whole kernel at all. So if you can build it without errors
and use it to boot up the guest, I think it should work well. Xiantao
Yep, compiles, boots, the works ...
Zhang, Xiantao wrote:
Hi Jes,
Good news! On my machine, without the patch, smp guest can't build one whole kernel at all. So if you can build it without errors and use it to boot up the guest, I think it should work well.
Xiantao
Yep, compiles, boots, the works ...
Avi, I think we can
Zhang, Xiantao wrote:
Hi, Jes
Have you verified whether it works for you ? You may run kernel build in
the guest with 4 vcpus, if it can be done successfully without any error, it
should be Okay I think, otherwise, we may need to investigate it further. :)
Xiantao
Hi Xiantao,
I was
Jes Sorensen wrote:
Zhang, Xiantao wrote:
Hi, Jes
Have you verified whether it works for you ? You may run kernel
build in the guest with 4 vcpus, if it can be done successfully
without any error, it should be Okay I think, otherwise, we may need
to investigate it further. :) Xiantao
Avi Kivity wrote:
Zhang, Xiantao wrote:
Fine to me. But seems the change in qemu_iovec_from_buffer is lost in
this patch or that change is also not unnecessary ?
I think the fixed unmap handles that case. Can you test to make sure?
Avi and I went through the code and verified that it was
: Jes Sorensen [mailto:j...@sgi.com]
Sent: Tuesday, June 02, 2009 6:57 PM
To: Avi Kivity
Cc: Zhang, Xiantao; kvm@vger.kernel.org; kvm-i...@vger.kernel.org; Hollis
Blanchard
Subject: Re: [PATCH] qemu-kvm: Flush icache after dma operations for ia64
Avi Kivity wrote:
Zhang, Xiantao wrote:
Fine
Zhang, Xiantao wrote:
Avi Kivity wrote:
Jes Sorensen wrote:
Ok,
Trying once more. After spending a couple of hours trying to follow
the QEMU dma codeflow, I have convinced myself Avi is right and those
two functions don't need to do the flushing as they all end up
calling
Avi Kivity wrote:
Jes Sorensen wrote:
Ok,
Trying once more. After spending a couple of hours trying to follow
the QEMU dma codeflow, I have convinced myself Avi is right and those
two functions don't need to do the flushing as they all end up
calling dma_bdrv_cb() which calls
Jes Sorensen wrote:
Ok,
Trying once more. After spending a couple of hours trying to follow
the QEMU dma codeflow, I have convinced myself Avi is right and those
two functions don't need to do the flushing as they all end up calling
dma_bdrv_cb() which calls dma_brdv_unmap(). I have added a
Hi,
Looking at Avi's comments, I came up with a slightly modified version
of this patch, which avoids the #ifdef __ia64__ problem by introducing
dma_flush_range().
I have made it a noop on non ia64, but it may need to be changed for
PPC? Hollis would you check if you guys need this too?
It
ARGH!
I think the attachment was lost :-( Trying again.
Jes
Jes == Jes Sorensen j...@sgi.com writes:
Jes Hi, Looking at Avi's comments, I came up with a slightly modified
Jes version of this patch, which avoids the #ifdef __ia64__ problem
Jes by introducing dma_flush_range().
Jes I have
Jes Sorensen wrote:
+/*
+ * Is this correct for PPC?
+ */
+#define dma_flush_range(start, end) \
+do { (void) (start); (void) (end); } while (0)
Correct or not, should be a function/
+#define dma_flush_range(start, end) \
+do { (void) (start);
Ok,
Trying once more. After spending a couple of hours trying to follow
the QEMU dma codeflow, I have convinced myself Avi is right and those
two functions don't need to do the flushing as they all end up calling
dma_bdrv_cb() which calls dma_brdv_unmap(). I have added a couple
comments to the
Zhang, Xiantao wrote:
Avi
This is the new patch for icache flush after DMA emualtion for ia64, and it should address Hollis's comments.
Xiantao
From 60a27e2ea9758c97e974aa5bb1925ad4ed045c5f Mon Sep 17 00:00:00 2001
From: Xiantao Zhang xiantao.zh...@intel.com
Date: Mon, 11 May 2009
14 matches
Mail list logo