On 4/19/08, Anthony Liguori [EMAIL PROTECTED] wrote:
Blue Swirl wrote:
On 4/17/08, Anthony Liguori [EMAIL PROTECTED] wrote:
Yes, the vector version of packet receive is tough. I'll take a look
at
your patch. Basically, you need to associate a set of RX vectors with
each
Hollis Blanchard wrote:
1 file changed, 5 insertions(+), 6 deletions(-)
arch/powerpc/kvm/Kconfig | 11 +--
Don't allow building as a module (asm-offsets dependencies).
Also, automatically select KVM_BOOKE_HOST until we better separate the guest
and host layers.
Applied,
Hollis Blanchard wrote:
Applied, thanks.
--
Do not meddle in the internals of kernels, for they are subtle and quick to
panic.
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's
Marcelo Tosatti wrote:
Now that threads are spinned up before machine-init(), clearing
of HF_HALTED_MASK for irqchip in kernel case needs to be moved
to actual vcpu startup.
Applied, thanks.
--
Do not meddle in the internals of kernels, for they are subtle and quick to
panic.
Anthony Liguori wrote:
I'd prefer you not do an emulate_instruction loop at all. Just
emulate one instruction on vmentry failure and let VT tell you what
instructions you need to emulate.
It's only four instructions so I don't think the performance is going
to matter. Take a look at
Marcelo Tosatti wrote:
kvm_pv_mmu_op should not take mmap_sem. All gfn_to_page() callers down
in the MMU processing will take it if necessary, so as it is it can
deadlock.
Apparently a leftover from the days before slots_lock.
Applied, thanks.
--
Do not meddle in the internals of
Pump it all night long with our new winning formula that gives you the extra
boost you need. http://www.tritwat.com/
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event.
Muli Ben-Yehuda wrote:
Why avoid rmap on mmio pages? Sure it's unnecessary work, but
having less cases improves overall reliability.
The rmap functions already have a check to bail out if the pte is not
an rmap pte, so in that sense, we aren't adding a new case for the
David Abrahams wrote:
Versions of kvm producing this sort of output are common in
archaeological digs. Please try a more recent release.
Well, I'll try Hardy Heron soon enough, I suppose. It's due out in 2
weeks.
I'm sure you understand that most people can't afford to
Marcelo Tosatti wrote:
Introduce QEMUDevice, making the ioport/iomem-device relationship visible.
At the moment it only contains a lock, but could be extended.
With it the following is possible:
- vcpu's to read/write via ioports/iomem while the iothread is working on
some
On Friday 18 April 2008 23:54:04 Anthony Liguori wrote:
Yang, Sheng wrote:
On Friday 18 April 2008 21:30:14 Anthony Liguori wrote:
Yang, Sheng wrote:
@@ -1048,17 +1071,18 @@ static void mmu_set_spte(struct kvm_vcpu *vcpu,
u64 *shadow_pte,
* whether the guest actually used the pte (in
Avi Kivity wrote:
For the majority of deployments posix aio should be sufficient. The few
that need something else can use Linux aio.
Does that mean for the majority of deployments, the slow version is
sufficient. The few that care about performance can use Linux AIO?
I'm under the
Jamie Lokier wrote:
Avi Kivity wrote:
For the majority of deployments posix aio should be sufficient. The few
that need something else can use Linux aio.
Does that mean for the majority of deployments, the slow version is
sufficient. The few that care about performance can use
On Sun, Apr 20, 2008 at 02:16:52PM +0300, Avi Kivity wrote:
The iperf numbers are pretty good. Performance of UP guests increase
slightly but SMP
is quite significant.
I expect you're seeing contention induced by memcpy()s and inefficient
emulation. With the dma api, I expect the benefit
On Sunday 20 April 2008, Avi Kivity wrote:
Also, I'd presume that those that need 10K IOPS and above will not place
their high throughput images on a filesystem; rather on a separate SAN LUN.
i think that too; but still that LUN would be accessed by the VM's via one of
these IO emulation
Hi,
This should be submitted to upstream (but not to kvm-devel list), but
this is only the test code that I want to quickly send out for
comments. In case it looks OK, I will send it to upstream later.
Inspired by extboot and conversations with Anthony and HPA, this
linuxboot option ROM is a
Forget to say that this patch is against kvm-66.
Thanks,
Q
On Mon, Apr 21, 2008 at 12:32 PM, Nguyen Anh Quynh [EMAIL PROTECTED] wrote:
Hi,
This should be submitted to upstream (but not to kvm-devel list), but
this is only the test code that I want to quickly send out for
comments. In
Hmm, the last patch includes a binary. So please take this patch instead.
Thanks,
Q
# diffstat linuxboot1.diff
Makefile | 13 -
linuxboot/Makefile | 40 +++
linuxboot/boot.S | 54 +
linuxboot/farvar.h | 130
I added the traces and captured data over another apparent lockup of the guest.
This seems to be representative of the sequence (pid/vcpu removed).
(+4776) VMEXIT [ exitcode = 0x, rip = 0x c016127c ]
(+ 0) PAGE_FAULT [ errorcode = 0x0003, virt = 0x
19 matches
Mail list logo
