Re: [kvm-devel] [PATCH 5/9] KVM: Adds ability to signal userspace using a file-descriptor
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 there
is
to context needed for dereferencing.
>>> There are concerns (from Al and Christoph) about file lifetime tracking of
>>> an fd passed down to the kernel.
>>>
>>>
>> What concerns are these?
>>
>> I have my own concerns about bare fds, which can change their backing file,
>> and which are dependent on the context. The kernel appears to be moving away
>> from handles to pointers, as seen by the pid -> task_struck/struct pid
>> conversion.
>>
>
> The concern is that by keeping a reference to the file* you may end up
> with a file that has no more userspace links. Although the file_count()==1
> will tell you that you've the only reference left, this relies on you
> doing the check. I really don't know how this will be used in KVM, so I
> can't really say how well these concerns applies.
>
>
That's perfectly fine for kvm (and as far as I can see, any other
application: the user losing their eventfd reference is equivalent to
the user ignoring any events, which should be survivable by the kernel).
>
>
>
>>> Avi, how about you go the other way around? I expose you something like:
>>>
>>> long eventfd_create(unsigned int count, void (*release)(void *),
>>> void *priv);
>>>
>>> This returns you an eventfd (or error), and lets you install a callback to
>>> be used when the file_operations->release is called (basically, userspace
>>> closed the last file instance).
>>> Can KVM pass back an fd to userspace instead of the other way around?
>>>
>>>
>> That was my original thought, but when I saw your proposal I preferred that
>> as
>> more flexible.
>>
>> If we go this way, I prefer to have a struct file * and do away with the
>> callback, but that brings us back to the file lifetime concerns.
>>
>
> Doing the above requires some care too. Access to your copy of the file*
> must be protected by a lock (you can sleep from inside the callback, so a
> mutex is fine too). I'll sketch you some code:
>
>
> /* Defined in linux/eventfd.h */
> struct eventfd_relcb {
> struct list_head lnk;
> void (*proc)(struct eventfd_relcb *);
> };
>
> /* Your context data */
> struct your_ctx {
> whatever_lock your_lock;
> ...
> struct eventfd_relcb rcb;
> struct file *evfile;
> };
>
> /* Your eventfd release callback */
> void rcb_callback(struct eventfd_relcb *rcb) {
> struct your_ctx *c = container_of(rcb, struct your_ctx, rcb);
>
> whatever_lock_lock(&c->your_lock);
> ...
> c->evfile = NULL;
> whatever_lock_unlock(&c->your_lock);
> }
>
> /* Your notify userspace function */
> void notify_userspace(struct your_ctx *c) {
>
> whatever_lock_lock(&c->your_lock);
> if (c->evfile != NULL)
> eventfd_signal(c->evfile, 1);
> whatever_lock_unlock(&c->your_lock);
> }
>
> /* Your eventfd create/setup function (modulo error checks) */
> void setup_eventfd(struct your_ctx *c) {
> int fd;
>
> c->rcb.proc = rcb_callback;
> fd = eventfd_create(0, &c->rcb);
> c->evfile = eventfd_fget(fd);
> /* Then return fd to userspace in some way */
> ...
> }
>
>
>
> If, by any chance, you need to detach yourself from the eventfd:
>
> void detach_eventfd(struct your_ctx *c) {
>
> whatever_lock_lock(&c->your_lock);
> if (c->evfile != NULL) {
> eventfd_del_release_cb(c->evfile, &c->rcb);
> /* And, optionally ... */
> eventfd_set_shutdown(c->evfile);
> }
> whatever_lock_unlock(&c->your_lock);
> }
>
>
> The eventfd_set_shutdown() function will make a POLLIN signaled to
> userspace, and a read(2) on the eventfd will return 0 (like peer
> disconnected sockets). Then userspace will know that no more eventfs will
> show up in there.
> Tentative patch below (builds, not tested yet).
>
>
>
Looks like a lot of code for what was supposed to be a code reduction...
I think I'll look at Gregory's notification-free suggestion instead.
--
error compiling committee.c: too many arguments to function
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] general protection fault
>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 - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] MSR_EFER acceleration for lighweight VM Exit
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 ~1185 cycles save for 64 bits on 64 bits,
> which is 29%
> save of total VM Exit. It can save ~1206 cycles for 32bits on
> 64bits, which is
> 27.5% save of total.
> BTW, I use 4 core clovertown processor, the total VM Exit time
> reported by
> vmexit.flat is about 2860 cycles now.
>
>
Very impressive speedup!
Comments below.
>
> +void cpuid_fix_nx_cap(struct kvm_vcpu *vcpu)
>
static function, please.
> +{
> + __u64 efer;
> +
> + rdmsrl(MSR_EFER, efer);
> + if ((vcpu->cpuid_nent >= 1) && !(efer & EFER_NX)) {
> + vcpu->cpuid_entries[1].edx &= ~(1<<20);
>
Nothing guarantees that function 1 is in entry 1. You need to iterate
over the loop.
> + printk(KERN_INFO ": guest NX capibility removed\n");
>
The warning should be printed only if the capability is actually present
in the cpuid_entry. Otherwise non-nx capable processors will always
show the warning.
> @@ -41,6 +41,7 @@ static struct page *vmx_io_bitmap_b;
> #else
> #define HOST_IS_64 0
> #endif
> +#define EFER_SR_BITS EFER_SCE
>
I'm guessing "SR" is save/restore? Please use the full name.
>
> static struct vmcs_descriptor {
> int size;
> @@ -56,6 +57,10 @@ static struct vmcs_descriptor {
> .ar_bytes = GUEST_##seg##_AR_BYTES, \
> }
>
> +#define efer_msr_srbits_changed(vcpu)
> \
> + ((vcpu->host_msrs[vcpu->msr_offset_efer].data & EFER_SR_BITS)!=
> \
> + (vcpu->guest_msrs[vcpu->msr_offset_efer].data & EFER_SR_BITS))
>
static function instead of macro.
> +
> static struct kvm_vmx_segment_field {
> unsigned selector;
> unsigned base;
> @@ -264,6 +269,18 @@ static void reload_tss(void)
> #endif
> }
>
> +void load_transition_efer(struct kvm_vcpu *vcpu)
>
static function
> +{
> + __u64 msr_efer_trans;
>
kernel code should use u64, not __u64. __u64 is for kernel code that is
shared with userspace.
>
> static void vmx_load_host_state(struct kvm_vcpu *vcpu)
> @@ -335,6 +354,8 @@ static void vmx_load_host_state(struct kvm_vcpu
> *vcpu)
> }
> save_msrs(vcpu->guest_msrs, vcpu->save_nmsrs);
> load_msrs(vcpu->host_msrs, vcpu->save_nmsrs);
> + if (efer_msr_srbits_changed(vcpu))
> + load_msrs(vcpu->host_msrs+vcpu->msr_offset_efer, 1);
>
space around '+'.
--
error compiling committee.c: too many arguments to function
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] 2 Bugs found for compilation on 32 Bit machine
Daniel Hecken wrote: > Hello, > > I have an Intel Core 2 Duo running Ubuntu Feisty 2.6.20-15 in 32 Bit > mode. If I try to compile kvm-trunk ( kvm-24-gfbfe1dc ) and the modules > from git ( v2.6.22-rc1-gf552bf6 ) I get a few compiler errors and the > compiler stops. > > Please find attached 2 patches to fix the errors. > > Applied, thanks. Please supply Signed-off-by: lines in the future for kernel patches. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] New VT-D spec available
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 capability, Interrupt > remapping capability, queue management, invalidation information and > enhancements. > > We are thinking how this should be enabled for KVM as well especially > when assigning real devices to guests. Suggestions are welcome. > I've had a quick look-see. There are two general approaches which I think make sense: - tightly coupled kvm integration, where kvm is extended with a root-only 'assign pci dev x to this vm'. As the page table format is the same as used by ept (I'm guessing... haven't actually read the ept spec), this should be quite easy to do on once npt/ept support is integrated. - general interface for manipulating VT-d, with the ability to use it with kvm. With this, it is possible to assign pci devices to ordinary userspace processes, some of which could be hosting virtual machines. This may fit will with the UIO patchset. Unless I misread things, VT-d does not honor the U/S bit on the page table entries. That makes the general approach fairly difficult. I would recommend starting with the tightly-coupled, less generic approach first, and generalizing it if/when there is demand for it. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH/RFC] KVM: Adds support for halting in the kernel
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 therefore eliminate the need to signal > userspace all together? I put together a proof-of-concept patch to try out > this idea. This patch replaces the fd-signaling patch previously sent. > > Comments please. > This is a winner. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] KVM configuration for headless speachless guest VMs?
Dimitry Golubovsky wrote: > Hi, > > I am going to use KVM on a headless machine with sound never on (even > not compiled in the kernel). > > I'm just curious if there is a possibility to build the kvm-qemu > without all this sound/video stuff (or with minimum of it). In > particular, without alsa at all. > > Has anybody tried to pass --disable-alsa, --disable-gfx-check to > qemu's configure: would it still work with KVM? Emulation of a graphic > adapter is not necessary either because I am going to communicate with > VMs mostly via ssh, or running x11vnc inside if graphics is needed. > > Any suggestions? I understand that this is a wholly experimental > thing, and I am ready to experiment. Hopefully I am not the first one > - can anybody share their experience with such kind of KVM > configuration? > > I see no reason why it shouldn't work. The out-of-the-box ./configure is oriented at fully featured hosts, but feel free to modify it to your needs. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 0/9] in-kernel APIC v6 (kernel side)
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 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. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 0/9] in-kernel APIC v6 (kernel side)
>>> 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 place. I didn't mean to suggest it was acceptable for checkin without one. :) -Greg -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH] fix a typo
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
--- a/drivers/kvm/vmx.c
+++ b/drivers/kvm/vmx.c
@@ -479,7 +479,7 @@ static void setup_msrs(struct kvm_vcpu *vcpu)
int index, save_nmsrs;
save_nmsrs = 0;
-#ifdef X86_64
+#ifdef CONFIG_X86_64
if (is_long_mode(vcpu)) {
index = __find_msr_index(vcpu, MSR_SYSCALL_MASK);
if (index >= 0)
fix1.patch
Description: fix1.patch
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] fix a typo
Dong, Eddie wrote: > Seems a typo leaking our eyes :-( > > > Fixing a typo which mixes X86_64 and CONFIG_X86_64 and block 64 > bits guest now. > > Ouch. Applied & pushed. Thanks. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] MSR_EFER acceleration for lighweight VM Exit
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 ~1185 cycles save for 64 bits on 64 bits,
which
>> is 29% save of total VM Exit. It can save ~1206 cycles for
32bits
>> on 64bits, which is
>> 27.5% save of total.
>> BTW, I use 4 core clovertown processor, the total VM Exit time
>> reported by vmexit.flat is about 2860 cycles now.
>>
>>
>
> Very impressive speedup!
>
> Comments below.
>
Here is the reformatted one, with the patch 64bits guest Kernel Build
performance
on my platform exceeds Xen by ~7%.
BTW, the previous fix for typo is a predendency.
kvm.h |2 ++
kvm_main.c | 23 +++
vmx.c | 56
++--
3 files changed, 63 insertions(+), 18 deletions(-)
commit 7d3596f123f95d168bbd1721c5d74bf7b13d0099
Author: root <[EMAIL PROTECTED](none)>
Date: Sun May 20 21:35:07 2007 +0800
KVM: VMX: Avoid saving and restoring msr_efer on lightweight
vmexit
MSR_EFER.LME/LMA bits are automatically save/restored by VMX
hardware, KVM only needs to save NX/SCE bits at time of heavy
weight VM Exit. But clearing NX bits in host envirnment may
cause system hang if the host page table is using EXB bits,
thus we leave NX bits as it is. If Host NX=1 and guest NX=0, we
can do guest page table EXB bits check before inserting a shadow
pte (though no guest is expecting to see this kind of gp fault).
If host NX=0, we present guest no Execute-Disable feature to
guest,
thus no host NX=0, guest NX=1 combination.
Signed-off-by: Yaozu (Eddie) Dong <[EMAIL PROTECTED]>
diff --git a/drivers/kvm/kvm.h b/drivers/kvm/kvm.h
index 5f056d9..e35434b 100644
--- a/drivers/kvm/kvm.h
+++ b/drivers/kvm/kvm.h
@@ -254,6 +254,7 @@ struct kvm_stat {
u32 request_irq_exits;
u32 irq_exits;
u32 light_exits;
+ u32 efer_reload;
};
struct kvm_vcpu {
@@ -288,6 +289,7 @@ struct kvm_vcpu {
u64 ia32_misc_enable_msr;
int nmsrs;
int save_nmsrs;
+ int msr_offset_efer;
#ifdef CONFIG_X86_64
int msr_offset_kernel_gs_base;
#endif
diff --git a/drivers/kvm/kvm_main.c b/drivers/kvm/kvm_main.c
index 1288cff..a2ac108 100644
--- a/drivers/kvm/kvm_main.c
+++ b/drivers/kvm/kvm_main.c
@@ -72,6 +72,7 @@ static struct kvm_stats_debugfs_item {
{ "request_irq", STAT_OFFSET(request_irq_exits) },
{ "irq_exits", STAT_OFFSET(irq_exits) },
{ "light_exits", STAT_OFFSET(light_exits) },
+ { "efer_reload", STAT_OFFSET(efer_reload) },
{ NULL }
};
@@ -2377,6 +2378,27 @@ out:
return r;
}
+static void cpuid_fix_nx_cap(struct kvm_vcpu *vcpu)
+{
+ u64 efer;
+ int i;
+ struct kvm_cpuid_entry *e, *entry;
+
+ rdmsrl(MSR_EFER, efer);
+ entry = NULL;
+ for (i = 0; i < vcpu->cpuid_nent; ++i) {
+ e = &vcpu->cpuid_entries[i];
+ if (e->function == 0x8001) {
+ entry = e;
+ break;
+ }
+ }
+ if (entry && (entry->edx & EFER_NX) && !(efer & EFER_NX)) {
+ entry->edx &= ~(1<<20);
+ printk(KERN_INFO ": guest NX capibility removed\n");
+ }
+}
+
static int kvm_vcpu_ioctl_set_cpuid(struct kvm_vcpu *vcpu,
struct kvm_cpuid *cpuid,
struct kvm_cpuid_entry __user
*entries)
@@ -2391,6 +2413,7 @@ static int kvm_vcpu_ioctl_set_cpuid(struct
kvm_vcpu *vcpu,
cpuid->nent * sizeof(struct
kvm_cpuid_entry)))
goto out;
vcpu->cpuid_nent = cpuid->nent;
+ cpuid_fix_nx_cap(vcpu);
return 0;
out:
diff --git a/drivers/kvm/vmx.c b/drivers/kvm/vmx.c
index 9bf8c04..aad5b63 100644
--- a/drivers/kvm/vmx.c
+++ b/drivers/kvm/vmx.c
@@ -41,6 +41,7 @@ static struct page *vmx_io_bitmap_b;
#else
#define HOST_IS_64 0
#endif
+#define EFER_SAVE_RESTORE_BITS EFER_SCE
static struct vmcs_descriptor {
int size;
@@ -56,6 +57,8 @@ static struct vmcs_descriptor {
.ar_bytes = GUEST_##seg##_AR_BYTES, \
}
+#define msr_efer_save_restore_bits(x) ((x).data &
EFER_SAVE_RESTORE_BITS)
+
static struct kvm_vmx_segment_field {
unsigned selector;
unsigned base;
@@ -84,6 +87,13 @@ static const u32 vmx_msr_index[] = {
};
#define NR_VMX_MSR ARRAY_SIZE(vmx_msr_index)
+static inline int msr_efer_need_save_restore(struct kvm_vcpu *vcpu)
+{
+ int efer_offset = vcpu->msr_offset_efer;
+ return msr_efer_save_restore_bits(vcpu->host_msrs[efer_offset])
!=
+
msr_efer_save_restore_bits(vcpu->guest_msrs[efer_o
Re: [kvm-devel] [PATCH] MSR_EFER acceleration for lighweight VM Exit
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 static function too, please. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Gentoo livecd amd64 not working?
> 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 http://news.gmane.org/gmane.comp.emulators.kvm.devel if you click "direct" link at the bottom of the page you get a URL like: http://article.gmane.org/gmane.comp.emulators.kvm.devel/3206 If you now append /raw to that URL: http://article.gmane.org/gmane.comp.emulators.kvm.devel/3206/raw You'll get the "raw" email data and the @ signs are not converted to , but it still looks like they have processed email addresses so they can't be harvested by spammers. So, for instance, Eddie's email in the body of the message becomes: <[EMAIL PROTECTED]> I'm not sure this is always suitable for patching, but it does look like it is processable by git-am. Wink - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] Windows experience and Fixed Income experience is a plus.
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 represent over $1 Trillion dollars to be managed by 2008. GPSI provides viable solutions to this market. This is hot, read the news and watch for more Monday! Get on GPSI first thing Monday! Experience working with colleagues in remote locations. Outstanding OO knowledge and strong UML experience. Experience working with colleagues in remote locations. Experience with multi-tier distributed applications design and development and good knowledge of XML and XSLT is a plus. Ability to work independently in a fast-paced environment. Introduction to Equity Options and Derivatives Markets. Good working knowledge of Equity Algorithmic Trading. Strong Quant knowledge specifically in the area of Execution Analytics. Ability to quickly adapt to a fast-paced market environment. Outstanding OO knowledge and strong UML experience. This role requires advanced knowledge of Java in a real-time Multi-Threaded Equity Trading environment. Experience working with colleagues in remote locations. Experience working with colleagues in remote locations. Linux or Solaris experience is also required. Experience with Hibernate, Spring and Web services. Strong Quant knowledge specifically in the area of Execution Analytics. Good communication skills. This candidate's primary responsibility will be to implement Buy-Side Analytic Trading Algorithms within the context of an Execution Management System using Java. SQL language skills - Equities Trading System Design and Implementation. Services firms demand that software managers and software developers have an extremely solid business background. Outstanding OO knowledge and strong UML experience. Wall Street Technology Jobs - New York Financial District Technical Careers in Equity Trading, Stock Markets, and Financial Services. Wall Street is looking for candidates who can solve real business problems using financial technology. Introduction to Equity Options and Derivatives Markets. For many years, the successful combination of these three entities has been the key to corporate profitability. Wall Street firms, technological advancements, and technology professionals. Knowledge of Java programming. Experience in the financial services industry is a plus. This candidate will also work directly with many parts of the business. Experience working with colleagues in remote locations. Strong grasp of the standard libraries and Middle Tier programming in general. Perl - Time Series Analysis. Windows experience and Fixed Income experience is a plus. Strong Quant knowledge specifically in the area of Execution Analytics. Windows experience and Fixed Income experience is a plus. Wall Street firms, technological advancements, and technology professionals. This individual will work directly with Traders to implement new analytics, tools to price products or trade new strategies and business intelligence functionality using our analytics platform. FIX knowledge - EMS, Execution Management System experience. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] MSR_EFER acceleration for lighweight VM Exit
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 PROTECTED](none)>
Date: Mon May 21 09:05:08 2007 +0800
KVM: VMX: Avoid saving and restoring msr_efer on lightweight vmexit
MSR_EFER.LME/LMA bits are automatically save/restored by VMX
hardware, KVM only needs to save NX/SCE bits at time of heavy
weight VM Exit. But clearing NX bits in host envirnment may
cause system hang if the host page table is using EXB bits,
thus we leave NX bits as it is. If Host NX=1 and guest NX=0, we
can do guest page table EXB bits check before inserting a shadow
pte (though no guest is expecting to see this kind of gp fault).
If host NX=0, we present guest no Execute-Disable feature to guest,
thus no host NX=0, guest NX=1 combination.
Signed-off-by: Yaozu (Eddie) Dong <[EMAIL PROTECTED]>
diff --git a/drivers/kvm/kvm.h b/drivers/kvm/kvm.h
index 5f056d9..e35434b 100644
--- a/drivers/kvm/kvm.h
+++ b/drivers/kvm/kvm.h
@@ -254,6 +254,7 @@ struct kvm_stat {
u32 request_irq_exits;
u32 irq_exits;
u32 light_exits;
+ u32 efer_reload;
};
struct kvm_vcpu {
@@ -288,6 +289,7 @@ struct kvm_vcpu {
u64 ia32_misc_enable_msr;
int nmsrs;
int save_nmsrs;
+ int msr_offset_efer;
#ifdef CONFIG_X86_64
int msr_offset_kernel_gs_base;
#endif
diff --git a/drivers/kvm/kvm_main.c b/drivers/kvm/kvm_main.c
index 1288cff..a2ac108 100644
--- a/drivers/kvm/kvm_main.c
+++ b/drivers/kvm/kvm_main.c
@@ -72,6 +72,7 @@ static struct kvm_stats_debugfs_item {
{ "request_irq", STAT_OFFSET(request_irq_exits) },
{ "irq_exits", STAT_OFFSET(irq_exits) },
{ "light_exits", STAT_OFFSET(light_exits) },
+ { "efer_reload", STAT_OFFSET(efer_reload) },
{ NULL }
};
@@ -2377,6 +2378,27 @@ out:
return r;
}
+static void cpuid_fix_nx_cap(struct kvm_vcpu *vcpu)
+{
+ u64 efer;
+ int i;
+ struct kvm_cpuid_entry *e, *entry;
+
+ rdmsrl(MSR_EFER, efer);
+ entry = NULL;
+ for (i = 0; i < vcpu->cpuid_nent; ++i) {
+ e = &vcpu->cpuid_entries[i];
+ if (e->function == 0x8001) {
+ entry = e;
+ break;
+ }
+ }
+ if (entry && (entry->edx & EFER_NX) && !(efer & EFER_NX)) {
+ entry->edx &= ~(1<<20);
+ printk(KERN_INFO ": guest NX capibility removed\n");
+ }
+}
+
static int kvm_vcpu_ioctl_set_cpuid(struct kvm_vcpu *vcpu,
struct kvm_cpuid *cpuid,
struct kvm_cpuid_entry __user
*entries)
@@ -2391,6 +2413,7 @@ static int kvm_vcpu_ioctl_set_cpuid(struct
kvm_vcpu *vcpu,
cpuid->nent * sizeof(struct
kvm_cpuid_entry)))
goto out;
vcpu->cpuid_nent = cpuid->nent;
+ cpuid_fix_nx_cap(vcpu);
return 0;
out:
diff --git a/drivers/kvm/vmx.c b/drivers/kvm/vmx.c
index 9bf8c04..f8633a8 100644
--- a/drivers/kvm/vmx.c
+++ b/drivers/kvm/vmx.c
@@ -41,6 +41,7 @@ static struct page *vmx_io_bitmap_b;
#else
#define HOST_IS_64 0
#endif
+#define EFER_SAVE_RESTORE_BITS ((u64)EFER_SCE)
static struct vmcs_descriptor {
int size;
@@ -84,6 +85,18 @@ static const u32 vmx_msr_index[] = {
};
#define NR_VMX_MSR ARRAY_SIZE(vmx_msr_index)
+static inline u64 msr_efer_save_restore_bits(struct vmx_msr_entry *msr)
+{
+ return (u64)msr->data & EFER_SAVE_RESTORE_BITS;
+}
+
+static inline int msr_efer_need_save_restore(struct kvm_vcpu *vcpu)
+{
+ int efer_offset = vcpu->msr_offset_efer;
+ return msr_efer_save_restore_bits(vcpu->host_msrs[efer_offset])
!=
+
msr_efer_save_restore_bits(vcpu->guest_msrs[efer_offset]);
+}
+
static inline int is_page_fault(u32 intr_info)
{
return (intr_info & (INTR_INFO_INTR_TYPE_MASK |
INTR_INFO_VECTOR_MASK |
@@ -264,6 +277,19 @@ static void reload_tss(void)
#endif
}
+static void load_transition_efer(struct kvm_vcpu *vcpu)
+{
+ u64 trans_efer;
+ int efer_offset = vcpu->msr_offset_efer;
+
+ trans_efer = vcpu->host_msrs[efer_offset].data;
+ trans_efer &= ~EFER_SAVE_RESTORE_BITS;
+ trans_efer |= msr_efer_save_restore_bits(
+ vcpu->guest_msrs[efer_offset]);
+ wrmsrl(MSR_EFER, trans_efer);
+ vcpu->stat.efer_reload++;
+}
+
static void vmx_save_host_state(struct kvm_vcpu *vcpu)
{
struct vmx_host_state *hs = &vcpu->vmx_host_state;
@@ -307,6 +333,8 @@ static void vmx_save_host_state(struct kvm_vcpu
*vcpu)
}
#endif
load_msrs(vcpu->guest_msrs, vcpu->save_nmsrs);
+ if (msr_efer_need_save_restore(vcpu))
+ load_transition_efer(vcpu);
}
static void vmx_load
Re: [kvm-devel] [PATCH] MSR_EFER acceleration for lighweight VM Exit
[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
MSR_EFER.LME/LMA bits are automatically save/restored by VMX
hardware, KVM only needs to save NX/SCE bits at time of heavy
weight VM Exit. But clearing NX bits in host envirnment may
cause system hang if the host page table is using EXB bits,
thus we leave NX bits as it is. If Host NX=1 and guest NX=0, we
can do guest page table EXB bits check before inserting a shadow
pte (though no guest is expecting to see this kind of gp fault).
If host NX=0, we present guest no Execute-Disable feature to guest,
thus no host NX=0, guest NX=1 combination.
Signed-off-by: Yaozu (Eddie) Dong <[EMAIL PROTECTED]>
diff --git a/drivers/kvm/kvm.h b/drivers/kvm/kvm.h
index 5f056d9..e35434b 100644
--- a/drivers/kvm/kvm.h
+++ b/drivers/kvm/kvm.h
@@ -254,6 +254,7 @@ struct kvm_stat {
u32 request_irq_exits;
u32 irq_exits;
u32 light_exits;
+ u32 efer_reload;
};
struct kvm_vcpu {
@@ -288,6 +289,7 @@ struct kvm_vcpu {
u64 ia32_misc_enable_msr;
int nmsrs;
int save_nmsrs;
+ int msr_offset_efer;
#ifdef CONFIG_X86_64
int msr_offset_kernel_gs_base;
#endif
diff --git a/drivers/kvm/kvm_main.c b/drivers/kvm/kvm_main.c
index 1288cff..a2ac108 100644
--- a/drivers/kvm/kvm_main.c
+++ b/drivers/kvm/kvm_main.c
@@ -72,6 +72,7 @@ static struct kvm_stats_debugfs_item {
{ "request_irq", STAT_OFFSET(request_irq_exits) },
{ "irq_exits", STAT_OFFSET(irq_exits) },
{ "light_exits", STAT_OFFSET(light_exits) },
+ { "efer_reload", STAT_OFFSET(efer_reload) },
{ NULL }
};
@@ -2377,6 +2378,27 @@ out:
return r;
}
+static void cpuid_fix_nx_cap(struct kvm_vcpu *vcpu)
+{
+ u64 efer;
+ int i;
+ struct kvm_cpuid_entry *e, *entry;
+
+ rdmsrl(MSR_EFER, efer);
+ entry = NULL;
+ for (i = 0; i < vcpu->cpuid_nent; ++i) {
+ e = &vcpu->cpuid_entries[i];
+ if (e->function == 0x8001) {
+ entry = e;
+ break;
+ }
+ }
+ if (entry && (entry->edx & EFER_NX) && !(efer & EFER_NX)) {
+ entry->edx &= ~(1<<20);
+ printk(KERN_INFO ": guest NX capibility removed\n");
+ }
+}
+
static int kvm_vcpu_ioctl_set_cpuid(struct kvm_vcpu *vcpu,
struct kvm_cpuid *cpuid,
struct kvm_cpuid_entry __user
*entries)
@@ -2391,6 +2413,7 @@ static int kvm_vcpu_ioctl_set_cpuid(struct
kvm_vcpu *vcpu,
cpuid->nent * sizeof(struct
kvm_cpuid_entry)))
goto out;
vcpu->cpuid_nent = cpuid->nent;
+ cpuid_fix_nx_cap(vcpu);
return 0;
out:
diff --git a/drivers/kvm/vmx.c b/drivers/kvm/vmx.c
index 9bf8c04..8701a79 100644
--- a/drivers/kvm/vmx.c
+++ b/drivers/kvm/vmx.c
@@ -41,6 +41,7 @@ static struct page *vmx_io_bitmap_b;
#else
#define HOST_IS_64 0
#endif
+#define EFER_SAVE_RESTORE_BITS ((u64)EFER_SCE)
static struct vmcs_descriptor {
int size;
@@ -84,6 +85,18 @@ static const u32 vmx_msr_index[] = {
};
#define NR_VMX_MSR ARRAY_SIZE(vmx_msr_index)
+static inline u64 msr_efer_save_restore_bits(struct vmx_msr_entry msr)
+{
+ return (u64)msr.data & EFER_SAVE_RESTORE_BITS;
+}
+
+static inline int msr_efer_need_save_restore(struct kvm_vcpu *vcpu)
+{
+ int efer_offset = vcpu->msr_offset_efer;
+ return msr_efer_save_restore_bits(vcpu->host_msrs[efer_offset])
!=
+
msr_efer_save_restore_bits(vcpu->guest_msrs[efer_offset]);
+}
+
static inline int is_page_fault(u32 intr_info)
{
return (intr_info & (INTR_INFO_INTR_TYPE_MASK |
INTR_INFO_VECTOR_MASK |
@@ -264,6 +277,19 @@ static void reload_tss(void)
#endif
}
+static void load_transition_efer(struct kvm_vcpu *vcpu)
+{
+ u64 trans_efer;
+ int efer_offset = vcpu->msr_offset_efer;
+
+ trans_efer = vcpu->host_msrs[efer_offset].data;
+ trans_efer &= ~EFER_SAVE_RESTORE_BITS;
+ trans_efer |= msr_efer_save_restore_bits(
+ vcpu->guest_msrs[efer_offset]);
+ wrmsrl(MSR_EFER, trans_efer);
+ vcpu->stat.efer_reload++;
+}
+
static void vmx_save_host_state(struct kvm_vcpu *vcpu)
{
struct vmx_host_state *hs = &vcpu->vmx_host_state;
@@ -307,6 +333,8 @@ static void vmx_save_host_state(struct kvm_vcpu
*vcpu)
}
#endif
load_msrs(vcpu->guest_msrs, vcpu->save_nmsrs);
+ if (msr_efer_need_save_restore(vcpu))
+ load_transition_efer(vcpu);
}
static void vmx_load_host_state(struct kvm_vcpu *vcpu)
@@ -335,6 +363,8 @@ static void vmx_load_host_state(struct kvm_vcpu
*vcpu)
}
save_msrs(vc
Re: [kvm-devel] [PATCH] MSR_EFER acceleration for lighweight VM Exit
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. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
