Zhang, Xiantao wrote:
diff --git a/drivers/kvm/kvm_main.c b/drivers/kvm/kvm_main.c
index 530c391..2d2ff55 100644
--- a/drivers/kvm/kvm_main.c
+++ b/drivers/kvm/kvm_main.c
@@ -670,7 +670,7 @@ static int kvm_vcpu_fault(struct vm_area_struct
*vma, struct vm_fault *vmf)
if (vmf-pgoff ==
and svm.c only needs to include x86.h
One mmu.h is created to solve inter-dependent issues.
With these two seires of pacthes, a clear arch-independent pictures
described! :)
Tested on x86_32 boot up, and x86_64 build.
Very nice patch series :-).
Acked-by: Carsten Otte [EMAIL PROTECTED
Avi Kivity wrote:
kvm_vcpu_fault() isn't for mapping guest pages, but for mapping the
kernel/userspace vcpu communication area. Moving that snippet to an
arch hook should be enough.
Oh thanks for clearing my confusion. Indeed, hm... but we won't have a
PIO_PAGE at all. On the other hand, we
Avi Kivity wrote:
Indeed, I'll rearrange the directory layout tomorrow and then we can
finally see actual arch support instead of preparations!
Yipieh :-).
-
SF.Net email is sponsored by:
Check out the new
Avi Kivity wrote:
In the case of x86, we'll have 16 arch dependent files (i8259.[ch],
irq.[ch], lapic.c, mmu.c, paging_tmpl.[ch], svm.[ch], vmx.[ch],
x86.[ch], x86_emulate.[ch]) which warrant a kvm/ subdirectory IMO.
I think a subdirectory makes sense too. We'll end up with more than a
Avi Kivity wrote:
What about merging kvm_cpu_has_interrupt() into _runnable()?
My feeling is that we can keep it separated.
On s390 there is a difference between has_interrupt and not runnable:
CPUs can be in stopped state, and they can be in enabled wait (enabled
for interrupts, similar to
Hollis Blanchard wrote:
Signed-off-by: Hollis Blanchard [EMAIL PROTECTED]
Acked-by: Carsten Otte [EMAIL PROTECTED]
We'll need this too on big iron.
-
SF.Net email is sponsored by: The Future of Linux Business White Paper
Hollis Blanchard wrote:
Signed-off-by: Hollis Blanchard [EMAIL PROTECTED]
These types work for us too.
Acked-by: Carsten Otte [EMAIL PROTECTED]
-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from
Hollis Blanchard wrote:
Signed-off-by: Hollis Blanchard [EMAIL PROTECTED]
Looks good.
Acked-by: Carsten Otte [EMAIL PROTECTED]
-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell. From
Hollis Blanchard wrote:
diff --git a/drivers/kvm/kvm_main.c b/drivers/kvm/kvm_main.c
--- a/drivers/kvm/kvm_main.c
+++ b/drivers/kvm/kvm_main.c
@@ -18,6 +18,7 @@
#include kvm.h
#include x86.h
#include irq.h
+#include iodev.h
#include linux/kvm.h
#include linux/module.h
Why do we
Avi Kivity wrote:
But you do need the vcpu cache, right?
I think about organizing our SIE control blocks in it, just like vmx
and svm do with their hardware structures backing a vcpu state.
They're 512 bytes in size, and need to start on a 512-byte boundary.
Sorry about my previous answer, I
Avi Kivity wrote:
Why is that? Do other archs not want kvm_vcpu_cache, or is it just the
alignment?
On s390, our nice colleagues in the hardware depeartment take care of
caching vcpu related data on a phyical one. No need to do anything for
us in that area, except enjoying the benefits. This
that it's x86 only.
Equivalent to perl -p -i -e s/kvm_vcpu_cache/kvm_x86_vcpu_cache/g
drivers/kvm/*
Signed-off-by: Christian Ehrhardt [EMAIL PROTECTED]
---
Acked-by: Carsten Otte [EMAIL PROTECTED]
-
SF.Net email is sponsored
-by: Carsten Otte [EMAIL PROTECTED]
-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell. From the desktop to the data center, Linux is going
mainstream. Let it simplify your IT future.
http
PROTECTED]
Acked-by: Carsten Otte [EMAIL PROTECTED]
-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell. From the desktop to the data center, Linux is going
mainstream. Let it simplify your
Ehrhardt [EMAIL PROTECTED]
Acked-by: Carsten Otte [EMAIL PROTECTED]
-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell. From the desktop to the data center, Linux is going
mainstream. Let
]
Acked-by: Carsten Otte [EMAIL PROTECTED]
-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell. From the desktop to the data center, Linux is going
mainstream. Let it simplify your IT future
Zhang, Xiantao wrote:
Since IA64's irqchip is always in kernel side, so we don't need
kvm_vcpu_ioctl_interrupt for irq delivery. Should we moved it to arch?
Otherwise, we have to define two unnecessary fields(irq_summary and
irq_pending) for vcpu structure for compile pass.
We don't have
Zhang, Xiantao wrote:
You mean you also need these two fields to hold irqs ?
No we don't. I think they can go to x86.
-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell. From the desktop
Avi Kivity wrote:
Unfortunately, we have to care for platform differences, subarch
differences (vmx/svm), hypervisor differences (with virtio), and guest
differences (Linux/Windows/pvLinux, 32/64). Much care is needed when
designing the ABI here.
Yea, I agree.
[actually thinking a bit,
Avi Kivity wrote:
We intend to bind our virtio devices to PCI too, so that they look the
same in Linux userland across architectures.
Ouch.
That was my initial opinion too, but HPA has come up with a lean and
clean PCI binding for lguest. I think we should seriously consider
using that
Zhang, Xiantao wrote:
Sorry for confusing you. snip Is it clear now?
Thanks, yea this makes your intention clear to me. I think what you
describe is an odd way to initialize both modules, and I'd like to
suggest to try to come up with the reverse approach where kvm.ko loads
your other module
Zhang, Xiantao wrote:
No, THIS_MODULE just stands for itself. But for IA64, we need another
module, and it will register some information to kvm module. So, we have
to keep it.
That answer confuses me. kvm_arch_init() for ia64 will reside in
kvm.ko just like kvm_init(), right?
So THIS_MODULE
PROTECTED]
Acked-by: Carsten Otte [EMAIL PROTECTED]
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01
This patch removes the include of asm/desc.h in kvm_main.c, which is
only available for x86 and not needed anymore.
Signed-off-by: Carsten Otte [EMAIL PROTECTED]
---
kvm_main.c |1 -
1 file changed, 1 deletion(-)
Index: kvm/drivers/kvm/kvm_main.c
by irq.h has been renamed to kvm_cpu_has_irq.
Signed-off-by: Carsten Otte [EMAIL PROTECTED]
---
irq.c |4 ++--
irq.h |2 +-
kvm_main.c |3 +--
svm.c |2 +-
vmx.c |2 +-
x86.c |4
x86.h |2 ++
7 files changed, 12 insertions(+), 7 deletions
Avi Kivity wrote:
I generally understand irq to mean the interrupt request line, and
interrupt to mean a vectored interrupt (post interrupt controller).
In those terms the naming in correct. However I'm not at all certain
this naming convention is generally accepted.
I think on s390 we'll
Hollis Blanchard wrote:
These patches are based on Xiantao's work to create struct kvm_x86. Patch 1
replaces his KVM Portability split: Splitting kvm structure (V2), and
patches 2 and 3 build on it.
Looks like a clean approach with to to_kvm_x86 macro. Whole series:
Acked-by: Carsten Otte
-by: Jerone Young [EMAIL PROTECTED]
Whole series looks good to me.
Acked-by: Carsten Otte [EMAIL PROTECTED]
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com
in common for s390, but I am
not sure just yet. If it turns out to be the case, I might submit an
add on patch that moves it to arch on day. Other then that, this split
looks good to me. Well done, Xiantao!
Acked-by: Carsten Otte [EMAIL PROTECTED
Zhang, Xiantao wrote:
Based on privious discussion, I made this patch to split struct kvm.
In this patch, strcut kvm only holds common fields, and struct kvm_x86
will keep x86-specific fields. In this way, struct kvm will be a
sub-filed in struct kvm_x86, and we can use to_kvm_x86 to get
Zhang, Xiantao wrote:
Move kvm_vcpu_ioctl_get_dirty_log to arch, and still keep the interface
in common.
diff --git a/drivers/kvm/kvm_main.c b/drivers/kvm/kvm_main.c
index 45b18e1..3400265 100644
--- a/drivers/kvm/kvm_main.c
+++ b/drivers/kvm/kvm_main.c
@@ -419,19 +419,14 @@ int
Zhang, Xiantao wrote:
Move kvm_mmu init and exit functionality to arch.
Acked-by: Carsten Otte [EMAIL PROTECTED]
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http
Avi Kivity wrote:
Carsten Otte wrote:
Zhang, Xiantao wrote:
Move kvm_vcpu_ioctl_get_dirty_log to arch, and still keep the interface
in common.
diff --git a/drivers/kvm/kvm_main.c b/drivers/kvm/kvm_main.c
index 45b18e1..3400265 100644
--- a/drivers/kvm/kvm_main.c
+++ b/drivers/kvm
Carsten Otte wrote:
Yea, I agree that it would make sense in case it works for power too. We
could have an
#ifdef CONFIG_ARCH_S390
return cool_big_iron_get_dirty_log(args);
#endif
at the beginning of that function. It would'nt hurt readability too much.
Stupid suggestion. We could
Zhang, Xiantao wrote:
User-allocation should be what we are heading. But considering
compatibility with old user-space support, I think kernel-allocation
approach should exist for a long time.
That's right. This is why I would prefer to have the corresponding
code out of kvm_main.c: it may
Zhang, Xiantao wrote:
How about attached patch? Agree to keep this ioctl in common, and
instead define an arch-specific function in x86.
Yea, that looks good to me.
Acked-by: Carsten Otte [EMAIL PROTECTED]
-
This SF.net
Acked-by: Carsten Otte [EMAIL PROTECTED]
Zhang, Xiantao wrote:
From: Zhang Xiantao [EMAIL PROTECTED]
Move kvm_x86_ops to x86.c
Signed-off-by: Zhang Xiantao [EMAIL PROTECTED]
---
drivers/kvm/kvm_main.c |1 -
drivers/kvm/x86.c |2 ++
drivers/kvm/x86.h |2 ++
3 files
Zhang, Xiantao wrote:
I rebased this series of patches to further split kvm_main.c. In
this version, I mainly improved the 3th patch, and make
kvm_arch_vcpu_create to hold more logics according to community's
response. Thanks Hollis and Carsteno for Acks. :)
Hi Xiantao,
these patches
Acked-by: Carsten Otte [EMAIL PROTECTED]
Zhang, Xiantao wrote:
From: Zhang Xiantao [EMAIL PROTECTED]
Combine kvm_init and kvm_init_x86 into one function, and will be called
when arch register.
Signed-off-by: Zhang Xiantao [EMAIL PROTECTED]
---
drivers/kvm/kvm.h |4 +-
drivers/kvm
Zhang, Xiantao wrote:
Moving KVM_CHECK_EXTENSION case to arch, since different archs should
have different capabilities.
Acked-by: Carsten Otte [EMAIL PROTECTED]
-
This SF.net email is sponsored by: Splunk Inc.
Still
Zhang, Xiantao wrote:
Moving KVM_CHECK_EXTENSION case to arch, since different archs should
have different capabilities.
I believe we want to keep the existence of the ioctl
KVM_CHECK_EXTENSION common. Just the extension flags should be arch
specific. This patch has the danger, that we might
I still do strongly agree with the general idea of this patch, and
most of the split comes out just right now. However, there is one
thing I'd like to pick on:
decache_vcpus_on_cpu should be an arch callback, and rather than
kvm_arch_vcpu_decache. There's no reason for s390 to grab locks and
Zhang, Xiantao wrote:
So we have to expose kvm_lock, and vm_list out. Is it OK?
I think that should be ok. We're within the very same module.
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log
Zhang, Xiantao wrote:
Agree. I am working on this now. I think we should move all mmu code
to arch specific.
Yea, I think ppc does'nt need it as well. Hollis?
-
This SF.net email is sponsored by: Splunk Inc.
Still
Avi Kivity wrote:
For the present discussion, I agree, but in general we should be
prepared to accept some no-op callouts.
Oh sure, I don't mind those. We'll have plenty of them, where other
architectures will need to take action and s390 won't. It's just that
in the current location, the
Hollis Blanchard wrote:
On Thu, 2007-11-08 at 14:49 +0100, Carsten Otte wrote:
Zhang, Xiantao wrote:
+void kvm_arch_vcpu_free(struct kvm_vcpu *vcpu);
+void kvm_arch_vcpu_decache(struct kvm_vcpu *vcpu);
+void kvm_arch_vcpu_load(struct kvm_vcpu *vcpu, int cpu);
+void kvm_arch_vcpu_put(struct
Zhang, Xiantao wrote:
Thanks for your suggestions. It is a surely good idea to create a
IA64 mailing list to talk about the IA64-KVM. But now we have to rebase
them to latest commits before sending out, since the kvm source layout
changed much recently. Once the final source layout comes
Acked-by: Carsten Otte [EMAIL PROTECTED]
Zhang, Xiantao wrote:
From fc56bda0f599ccd00d992bf196654101e82d1413 Mon Sep 17 00:00:00 2001
From: Zhang Xiantao [EMAIL PROTECTED]
Date: Wed, 7 Nov 2007 11:39:23 +0800
Subject: [PATCH] move some header files form kvm_main.c to x86.c, since
the
related
Zhang, Xiantao wrote:
This series of patches are intended to further split x86 specific code
from kvm_main.c, and make kvm_main.c arch-independent.
For easy review, I splitted them into small patches. With these patches,
we almost finish the first stage work for code split.
These patches
Acked-by: Carsten Otte [EMAIL PROTECTED]
Zhang, Xiantao wrote:
From 7473192cc0c529b8ce35c13d0e83a9b663072831 Mon Sep 17 00:00:00 2001
From: Zhang Xiantao [EMAIL PROTECTED]
Date: Wed, 7 Nov 2007 11:41:50 +0800
Subject: [PATCH] mov kvm_x86_ops to x86.c for next step's work
Signed-off-by: Zhang
Zhang, Xiantao wrote:
+void kvm_arch_vcpu_free(struct kvm_vcpu *vcpu);
+void kvm_arch_vcpu_decache(struct kvm_vcpu *vcpu);
+void kvm_arch_vcpu_load(struct kvm_vcpu *vcpu, int cpu);
+void kvm_arch_vcpu_put(struct kvm_vcpu *vcpu);
+struct kvm_vcpu *kvm_arch_vcpu_create(struct kvm *kvm, unsigned
Acked-by: Carsten Otte [EMAIL PROTECTED]
Zhang, Xiantao wrote:
From 2d6ee07b96f1a91cef9327f241077af3698ed4dc Mon Sep 17 00:00:00 2001
From: Zhang Xiantao [EMAIL PROTECTED]
Date: Thu, 8 Nov 2007 13:37:38 +0800
Subject: [PATCH] Make kvm_init as arch-indepenent, through defining a
void
pointer
Christian Borntraeger wrote:
It is not yet updated to latest virtio latest kvm.
This version uses a pci device for virtio. Since I'm think Rusty's
config space does not matches
pci config space I might consider changing it. (Preferably not, maybe
I'll start using it until we'll have the
Dong, Eddie wrote:
BTW, why we use vector here? shouldn't it be irq_line or irq_no?
Maybe you mean the Channel Subsystem (1st piece of knowledge and
surprise known from s390 doc) are emulated in Qemu, correct?
The vector field was introduced by Avi's comment. I just copied that
over.
On
Arnd Bergmann wrote:
On Monday 05 November 2007, Carsten Otte wrote:
Dong, Eddie wrote:
BTW, why we use vector here? shouldn't it be irq_line or irq_no?
Maybe you mean the Channel Subsystem (1st piece of knowledge and
surprise known from s390 doc) are emulated in Qemu, correct?
The vector
Dong, Eddie wrote:
Why KVM_IRQ_LINE is X86b specific? The original idea are based on ACPI spec
which
I assume to be generic though S390 may not take.
ACPI is not present on s390 and ppc. In fact, I doubt it is present on
any architecture except those two intel ones: at least my mips router
Avi Kivity wrote:
Why KVM_IRQ_LINE is X86b specific? The original idea are based on ACPI spec
which
I assume to be generic though S390 may not take.
ia64 can probably share much. ppc will probably want KVM_IRQ_LINE with
with different parameters. s390, as far as I understand, will
Dong, Eddie wrote:
OK, so how can a device inform kernel for an IRQ in S390?
Oooh, that is a looong explanation. If you want to peek at it, see
http://publibz.boulder.ibm.com/epubs/pdf/a2278324.pdf . Chapter 6
covers Interruptions. I'd recommend to start with reading external
interruptions,
Avi Kivity wrote:
But that doesn't make the code portable. The s390 userspace has to know
how to encode the number, and x86 will do it differently.
If it's really different, let's keep it different. Unless you can push
the encoding so far back it's transparent to userspace (e.g. qemu).
I
Avi Kivity wrote:
A bitmap would do it, but what size? Expandable ones are messy.
We could have a #define KVM_CPU_BITMAP_SIZE in the arch specific
header files that go to include/asm/. For s390, we have one of our
rocket science virtualization accelerating facilities that limits us
to 64 cpus
Dong, Eddie wrote:
IA64/KVM will handle interrupt in kernel including IPI IMO, so what
user level need to tell kernel is which platform IRQ pin is set/cleared.
Can't S390 do in similar way? From platform point of view, each
irq can have a unique # and the device itself doesn;t need to know
This patch moves the implementation of the functions of kvm_get/set_msr,
kvm_get/set_msr_common, and set_efer from kvm_main.c to x86.c. The
definition of EFER_RESERVED_BITS is moved too.
Signed-off-by: Carsten Otte [EMAIL PROTECTED]
---
kvm_main.c | 133
Thanks to Xiantao and Hollis for your quick review of last patch series.
Thanks Avi for finding time to pick up last patches on your trip to
Japan.
This series of patches moves more code from kvm_main.c to x86.c. I start
seeing the light at the end of the tunnel, I think these should be the
last
, is removed from kvm_main.c now because it is not needed anymore.
Signed-off-by: Carsten Otte [EMAIL PROTECTED]
---
kvm_main.c | 248 -
x86.c | 243 +++
x86.h |1
3
Zhang, Xiantao wrote:
Basically, It doesn't impact our side. For patch 2/3, we had better find
an approach to handle mmio-realted functions, becasue they may exist in
most archs.
For IA64, if this move happens, we have to duplicate them in IA64 side.
Thanks for your feedback. This matches
Hollis Blanchard wrote:
On Tue, 2007-10-30 at 22:53 +0100, Carsten Otte wrote:
Zhang, Xiantao wrote:
Basically, It doesn't impact our side. For patch 2/3, we had better find
an approach to handle mmio-realted functions, becasue they may exist in
most archs.
For IA64, if this move happens
Avi Kivity wrote:
Zhang, Xiantao wrote:
Avi Kivity wrote:
Wht about aliases? Aliases allow you go have two different physical
addresses for the same page. This is useful for mapping the
framebuffer on x86 (both at the pci region and at 0xa, the
traditional ISA location).
Are they
Izik Eidus wrote:
my idea was to let kvm register userspace memory that will hold the
guest memory,
and then much like qemu do with its cpu_register_physical_memory
function, run ioctls
that will tell the kernel how to map this memory,
what i wanted to achieved is making the memory
This patch series continues the split of kvm_main.c for portability. The
first patch that splits kvm_vm_ioctl is unchanged since last submit, but
has not yet been picked up upstream. There are no more ongoing
discussions regarding it's content, therefore I'd like to ask for
integration of that
ioctls are:
KVM_SET_MEMORY_REGION,
KVM_GET/SET_NR_MMU_PAGES, KVM_SET_MEMORY_ALIAS, KVM_CREATE_IRQCHIP,
KVM_CREATE_IRQ_LINE, KVM_GET/SET_IRQCHIP
KVM_SET_TSS_ADDR
Signed-off-by: Carsten Otte [EMAIL PROTECTED]
Reviewed-by: Christian Borntraeger [EMAIL PROTECTED]
Acked-by: Hollis Blanchard [EMAIL
This patch moves the definition of segment_descriptor_64 for AMD64 and
EM64T from kvm_main.c to segment_descriptor.h. It also adds a proper
#ifndef...#define...#endif around that header file.
The implementation of segment_base is moved from kvm_main.c to x86.c.
Signed-off-by: Carsten Otte [EMAIL
This patch moves the implementation of get_apic_base and set_apic_base
from kvm_main.c to x86.c
Signed-off-by: Carsten Otte [EMAIL PROTECTED]
Reviewed-by: Christian Borntraeger [EMAIL PROTECTED]
---
kvm_main.c | 19 ---
x86.c | 19 +++
2 files changed, 19
in kvm_main.c and
x86.c for now, the version in kvm_main.c should disappear once the last
user of it is gone too.
The function load_pdptrs is no longer static, and now defined in x86.h
for the time being, until the last user of it is gone from kvm_main.c.
Signed-off-by: Carsten Otte [EMAIL PROTECTED]
Reviewed
Izik Eidus wrote:
i think KVM_SET_MEMORY_ALIAS, is useful not just to x86,
avi talked with the ia64 guys and they told him that they have use for
this function.
is it that bad for you?
KVM_SET_USER_MEMORY_REGION is a superset of KVM_SET_MEMORY_ALIAS, at
least that's how I read Avi's reply
Hollis Blanchard wrote:
AFAICS, you can just issue two KVM_SET_USER_MEMORY_REGION ioctls in a
row, changing 'guest_phys_addr' and leaving 'userspace_addr' the same.
That will create an alias.
That was also my understanding of Avi's comment.
Izik Eidus wrote:
btw, if you look at kvmctl, we already do it,
so it is good question if it better to leave this work to userspace
(like it do now)
or do the mapping to userspace from the kernel to userspace (using the
mmap syscall)
(i like the secoend option beacuse it would be easier
Avi Kivity wrote:
Hollis Blanchard wrote:
On Fri, 2007-10-26 at 00:12 +0200, Izik Eidus wrote:
ok i was thinking,
maybe we can rewrite the way kvm hold memory so more code would be shared,
lets say we throw away all the slots and arch depended stuff, and we let kvm
just hold the
Carsten Otte wrote:
That's why memory allocation/preparation needs to be arch dependent:
i386 needs a memory layout different from userspace page table due to
your argument, and s390 needs to use the userspace page table due to
hardware features we want to exploit.
As Xiantao pointed out
Izik Eidus wrote:
beside moving the memory allocation to userspace (this is first step in
share memory between VMs using smart file system)
there is not much advance.
about sharing memory between VM and host, we improved it by adding
partial swapping support,
so the host can take memory
Avi Kivity wrote:
Why aren't memory slots common too? Only their number is different,
while the implementation is the same.
Your approach makes the meaning of memory slot somewhat useless on
s390, if that one may be sparse and may be result of different
allocations: On x86, there has to be
Hollis Blanchard wrote:
This patch can now execute guest userspace (I'm not saying it's complete
or stable or anything though). I need to put together a more
full-featured ramdisk to test userspace more completely.
Congratulations Hollis, cool stuff :-).
Anthony Liguori wrote:
While both PPC and x86 may be able to use it, I doubt there will
actually be common code that ever touches it.
Common code could figure whether or not it needs to save/restore the
fpu register set, and call back to an arch specific callback to do so.
On the other hand,
Laurent Vivier wrote:
This patches can be applied only on kvm-updates-2.6.24 and kvm-updates-2.6.25
as it needs smp_call_function_mask().
There's one thing I don't understand: How is this locked versus cpu
hotplug? Isn't there an obvious race involved where a cpu unplugged
after cpu_set()?
Hollis Blanchard wrote:
I must be misunderstanding, because this seems completely backwards to
me. With your nesting, any time architecture code wants to access
architecture state (which is almost all the time), you'd *need*
container_of:
void arch_func(struct kvm_vcpu *vcpu) {
Mike Lampard wrote:
There was a commit ab9c232286c2b77be78441c2d8396500b045777e regarding libata
on linus's master tree that happened on Friday, that was pulled into kvm git
over the weekend.. I dont know if that may be affecting you.. there is/was
also chatter on LKML regarding some
Aurelien Jarno wrote:
Could you please precise what is corrupted? The guest disk image?
As stated, we actually did not run any guests and did not load the kvm
kernel modules.
The host root file system gets corrupted to an extend not correctable
by the file system checker (we gave it 24h to
Carsten Otte wrote:
First thing we do, is figure whether or not 2.6.23.1 as released breaks
our system too. This way, we can either focus on differences between
Linus and Avi, or turn on the big red warning sign saying regression.
Looks like 2.6.23.1 works fine on that box. We'll leave
Carsten Otte wrote:
2.6.23 is broken, 2.6.23-rc8 works for us.
Actually, the working version was 2.6.23-rc6, git-head of kvm.git as
of October 11.
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log
Avi Kivity wrote:
We need to distinguish between x86 specific (only x86 has this) and s390
special (everyone has it except s390). In the latter case it should
still be in common code to avoid duplication, with a guard to disable
compilation on s390.
KVM_SET_MEMORY_REGION is in theory
Anthony Liguori wrote:
So does MADV_REMOVE remove the backing page but still allow for memory
to be faulted in? That is, after calling MADV_REMOVE, there's no
guarantee that the contents of a give VA range will remain the same (but
it won't SEGV the app if it accesses that memory)?
If
Gerd Hoffmann wrote:
With VT you can attempt to make that invisible to the guest using the
tsc offset field. Probably svm can do that too (didn't check docs
though). kvm-lite can't (what is the status btw?). Xen solves that
by not doing power management *evil grin*.
On s390, we've had an
Anthony Liguori wrote:
While the pic/apic related functions are obviously x86 specific, some
other ioctls seem to be common at a first glance.
KVM_SET_(USER)_MEMORY_REGION for example. We've got a total different
address layout on s390: we cannot support multiple slots, and a user
memory
Zhang, Xiantao wrote:
I don't know why we not put KVM_SET_MEMORY_REGION,
KVM_SET_USER_MEMORY_REGION as common, although
I have read the reasons you listed. I think they should work for most of
archs, although it is not very friendly with s390. If we put them
as arch-specific ones, we have
Zhang, Xiantao wrote:
struct kvm_vcpu {
struct kvm *kvm;
struct preempt_notifier preempt_notifier;
int vcpu_id;
struct mutex mutex;
int cpu;
- u64 host_tsc;
struct kvm_run *run;
int interrupt_window_open;
This one should go to arch.
int guest_mode;
Avi Kivity wrote:
We need to distinguish between x86 specific (only x86 has this) and s390
special (everyone has it except s390). In the latter case it should
still be in common code to avoid duplication, with a guard to disable
compilation on s390.
KVM_SET_MEMORY_REGION is in theory
Avi Kivity wrote:
Using previous terminology, mmio is s390 special. Everyone else does
have them. We can #ifndef them on s390, but we won't duplicate mmio on
all other archs.
No need to duplicate the code for all other archs: we should think
about a functional split here, like having an
Avi Kivity wrote:
I agree 100%, I'm just using the keep the patch dead simple excuse to
delay the change. We can have a 'add kvm_ prefix' patch round later.
Let's complete the separation first.
Okay, fine with me.
There are some bigger offenders too, like set_crX(), which don't even
start
Zhang, Xiantao wrote:
I orgirnally mean we have to wrap all functions related to kvm_x86_ops.
But seems it doesn't introduce
extra maintain effort, if other architectures implment these functions
directly. Good method!
That was my idea at first too, until Hollis has beaten me up on this.
Zhang, Xiantao wrote:
Thank you, I will resend it :)
I do greatly appreciate it. We'll do this together, please do also
pick on my patches whenever you see something that does'nt fit what
you need for ia64.
thanks,
Carsten
101 - 200 of 267 matches
Mail list logo
