Casey Jeffery wrote:
I've tried out the last few versions of KVM and think it's great. It's
much easier to use and understand than Xen and performance is
surprisingly good.
One of the things I'd like to do is modify it to allow PMI generation
based on the Intel performance counter
* Rusty Russell [EMAIL PROTECTED] wrote:
It's also something for the Linux community in general to decide: if
we want separate interfaces for paravirtualization and full
virtualization (lhype and kvm) or a merged interface. I can see
arguments in favor of both positions.
Yeah, me
Ingo Molnar wrote:
i really really think KVM and lhype should merge, creating KVM/HVM
(Hardware Virtual Machine) and KVM/LL (Linux on Linux).
This is only sufficient if either KVM with paravirt Linux kernels has no
performance penalty or lhype becomes able to execute paravirt Linux kernels.
I
* Ulrich Drepper [EMAIL PROTECTED] wrote:
Ingo Molnar wrote:
i really really think KVM and lhype should merge, creating KVM/HVM
(Hardware Virtual Machine) and KVM/LL (Linux on Linux).
This is only sufficient if either KVM with paravirt Linux kernels has
no performance penalty or lhype
On Wed, 2007-01-10 at 10:47 +0100, Ingo Molnar wrote:
* Rusty Russell [EMAIL PROTECTED] wrote:
regarding ABI: agreed that it's experimental right now and should stay
so for some time, but i dont see a reason why the hypercall API that
i've posted in the past few days couldnt be evolved in
Hello all,
hard and software virtualisation has been with us since the mid 1960's, as
I am sure you are all aware of.
See http://en.wikipedia.org/wiki/VM/CMS
JC
On Wed, January 10, 2007 11:46, Rusty Russell wrote:
On Wed, 2007-01-10 at 10:47 +0100, Ingo Molnar wrote:
* Rusty Russell
Ingo Molnar wrote:
* Avi Kivity [EMAIL PROTECTED] wrote:
If you have a CONFIG_PARAVIRT guest, I believe it will always be
faster to run it without hardware assisted virtualization:
- you cannot eliminate vmexits due to host interrupts
- a hypercall will (probably) keep being more
Ingo Molnar wrote:
* Avi Kivity [EMAIL PROTECTED] wrote:
For i386 Xen does not switch cr3 IIRC. [...]
correct.
[...] Perhaps even not for x86_64 if it can use the segment limits
which AMD re-added (I think it does?)
i'm not sure. Older ones definitely used cr3
Anthony Liguori wrote:
Avi Kivity wrote:
Ingo Molnar wrote:
* Avi Kivity [EMAIL PROTECTED] wrote:
If you have a CONFIG_PARAVIRT guest, I believe it will always be
faster to run it without hardware assisted virtualization:
- you cannot eliminate vmexits due to host interrupts
- a
Avi Kivity wrote:
[[Can't a paravirtualized kernel use a vdso to use int $0x80 instead of
syscall?]]
No. The ABI is to inline syscall instructions. That's possible since
it's not as limited/broken as sysenter.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
On Thu, 2007-01-11 at 01:49 +0100, Ingo Molnar wrote:
* Rusty Russell [EMAIL PROTECTED] wrote:
- cr3 switches for CONFIG_PARAVIRT syscalls (which are necessary
on x86_64) will probably become very cheap with tagged tlbs
but irq overhead is nothing in importance compared to basic
* Rusty Russell [EMAIL PROTECTED] wrote:
Err no, this isn't true. See Documentation/lhype.txt or various blog
entries on the subject 8) Both Xen and lhype get native syscall speeds
(within measurement error).
i was talking about 64-bit. (we dont really design for 32-bit
if (is_writeble_pte(*shadow_ent))
-return 0;
+return 1;
With this patch, it looks like my guest is surviving the load that
triggered the oops before. So I think this fixes the issue I saw as well.
I assume you'll send this in for 2.6.20?
- R.
On Tuesday 09 January 2007 14:37, Avi Kivity wrote:
struct kvm_vcpu_area {
u32 vcpu_area_size;
u32 exit_reason;
sigset_t sigmask; // for use during vcpu execution
Since Jeff brought up the point of 32 bit compatibility:
When this structure is shared between 64 bit kernel and
32
14 matches
Mail list logo
