On the gname archive its even worse the @@ get converted to
at at as they must think its an email address. So it looks
like the archives are a poor place to pickup patches, at least
for me.
..
Sorry for any confusion but the upshot is still that the archives are
unable to be used for
Davide Libenzi wrote:
On Thu, 17 May 2007, Avi Kivity wrote:
Davide Libenzi wrote:
On Wed, 16 May 2007, Avi Kivity wrote:
IMO doing eventfd_fget() asap is best. I much prefer refcounted pointers
to
handles in the kernel: it's easier to see what things point to, and
What to do?
Re-test it without using xen's dom0 kernel.
malysh:/var/log# uname -a
Linux malysh 2.6.18-4-xen-amd64 #1 SMP Fri May 4 02:40:51 UTC 2007
x86_64 GNU/Linux
kvm_amd21520 0
kvm68596 1 kvm_amd
Nakajima, Jun wrote:
An updated specification (Rev 1.0 update) of Intel(r) virtualization
technology for Directed I/O is now available on Intel web site:
http://download.intel.com/technology/computing/vptech/Intel(r)_VT_for_Di
rect_IO.pdf
The specification update includes DMA remapping
Gregory Haskins wrote:
Hi All,
I was thinking about some of the issues that we are dealing with
w.r.t. signalling a sleeping userspace (eventfd, signals, etc). I was
wondering if perhaps we were looking at the problem the wrong way. Can we
perform halts in the kernel and
Gregory Haskins wrote:
2) Moved eventfd patch to end of series and dropped it from the public release
(for now). We dont technically need to signal userspace if PIT is enabled
since this wakes us up anyway. We can defer the eventfd/in-kernel-halt
conversation for later.
The PIT will
Avi Kivity [EMAIL PROTECTED] 05/20/07 3:55 AM
The PIT will wake us up, but at a substantial delay, which may cause a
large drop in throughput. It's not enough to get the wakeup, it needs
to be immediate.
I agree fully. To clarify, I just meant we are ok to review v6 without a
solution in
Seems a typo leaking our eyes :-(
Fixing a typo which mixes X86_64 and CONFIG_X86_64 and block 64
bits guest now.
Signed-off-by: Yaozu (Eddie) Dong [EMAIL PROTECTED]
diff --git a/drivers/kvm/vmx.c b/drivers/kvm/vmx.c
index 5f4bdc0..9bf8c04 100644
---
Avi Kivity wrote:
Dong, Eddie wrote:
Avi:
This patch is to avoid saving and restoring of msr_efer on
lightweight vmexit.
With this patch, the Kernel build get 10% increasement for
64bits
on 64 bits, and 5-8% increasement for 32bits on 64 bits.
Vmexit.flat can see
Dong, Eddie wrote:
Here is the reformatted one, with the patch 64bits guest Kernel Build
performance
on my platform exceeds Xen by ~7%.
Hey, this came earlier than I expected :)
+#define msr_efer_save_restore_bits(x) ((x).data
EFER_SAVE_RESTORE_BITS)
+
This needs to be a
For archived messages at http://article.gmane.org/, you can append
/raw to the URL to get an unprocessed copy of the message.
Thanks for the info, at first I didn't catch that article.gmane.org was
referring to as I read your post. So for other newbie's the kvm archive is at
GPSI Announces Market Attack Into $1 Trillion Market!
Global Payment Solutions
Symbol: GPSI
Price: $0.03
GPSI announced its plans to address the huge influx of immigrant workers
into the US that need banking solutions that they otherwise would not
qualify for. This market is expected to
Try again.
Eddie
kvm.h |2 ++
kvm_main.c | 23 +++
vmx.c | 59
+--
3 files changed, 66 insertions(+), 18 deletions(-)
commit 7de9b4bff794317ae05c0f3b2fec9b3d710fed2b
Author: root [EMAIL
[EMAIL PROTECTED] wrote:
Try again.
Wrong attachment. Please use this one.
commit 5ad9d2ec2cd1f324aa75f2bb0fd7a2de1cb769c3
Author: root [EMAIL PROTECTED](none)
Date: Mon May 21 10:37:34 2007 +0800
KVM: VMX: Avoid saving and restoring msr_efer on lightweight vmexit
Dong, Eddie wrote:
[EMAIL PROTECTED] wrote:
Try again.
Wrong attachment. Please use this one.
Applied thanks.
--
Do not meddle in the internals of kernels, for they are subtle and quick to
panic.
-
15 matches
Mail list logo