Avi Kivity wrote:
> Too much Kconfig for this. Since I want to do some Kconfig changes
> anyway, I'll do this another way.
I think you overlooked something here. Actually this should change too
if we don't have pio:
-...case KVM_GET_VCPU_MMAP_SIZE:
-...-...r = -EINVAL;
-...-.
Andrea Arcangeli wrote:
> On Tue, Jan 22, 2008 at 04:38:49PM +0200, Avi Kivity wrote:
>> Andrea Arcangeli wrote:
This is arch independent code, I'm surprised mmu_lock is visible here?
>>> The mmu_lock is arch independent as far as I can tell. Pretty much
>>> like the mm->page_table_l
Jan Kiszka wrote:
> The PIT may not be limited to x86 platforms. So I would propose to make
> the setup more generic and flexible. And I would move the code out of
> arch/x86, just the speaker support should remain there.
It should also not be common among all archs. On s390 we have CPU
timer, whi
Hollis Blanchard wrote:
> There are a bunch of x86-specific fields in struct kvm_run:
> /* in */
> __u8 request_interrupt_window;
> __u8 padding1[7];
>
> /* out */
> __u8 if_flag;
> __u8 padding2[2];
>
> /* in (pre_kvm_run), out (post_kvm_run) */
>
Zhang, Xiantao wrote:
> I don't think this is a issue. Since this makefile is located at
> arch/{$arch}/kvm. So, you can choose to include it or not.
> That is, you can define your own common objs.
Ah :-). Thanks for the explanation.
--
Avi Kivity wrote:
> Zhang, Xiantao wrote:
>> common-objs = $(addprefix ../../../virt/kvm/, kvm_main.o)
>> +common-objs += $(addprefix ../../../virt/kvm/, ioapic.o)
>>
>
> Just add ioapic.o behind kvm_main.o; it's a list.
But this is'nt really common since ppc and s390 won't have it. How are
w
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 Source
udes kvm.h, and
> vmx.c 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 ser
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
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->pgo
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
sin
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 t
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
> #include
Why do we have that
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
fro
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 Busin
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
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 w
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
structure in generic code the definition moved from kvm.h to x86.h.
>
> Signed-off-by: Christian Ehrhardt <[EMAIL PROTECTED]>
Acked-by: Carsten Otte <[EMAIL PROTECTED]>
-
SF.Net email is sponsored by: The Future of
that variable in the code in future 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]>
-
86.h.
>
> Signed-off-by: Christian 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
ed-off-by: Zhang Xiantao <[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 i
g Xiantao <[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
main
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
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 h
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 tha
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 bi
Avi Kivity wrote:
> No, definitely not define a hypercall ABI. The feature bit should say
> "this device understands a hypervisor-specific way of kicking. consult
> your hypervisor manual and cpuid bits for further details. should you
> not be satisfied with this method, port io is still avai
Zhang, Xiantao wrote:
> Sorry for confusing you. 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 via r
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
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 s39
defined 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
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_
Signed-off-by: Zhang Xiantao <[EMAIL 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.at
Avi Kivity wrote:
> Well, I hate to say it, but the resulting code doesn't look too well
> (all the kvm_x86 variables), and it's entirely my fault as I recommended
> this approach. Not like it was difficult to predict.
>
> I'm thinking again of
>
> struct kvm {
> struct kvm_arch a;
>
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 s
), 33 deletions(-)
I don't think we'll want the rmap part 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. Wel
Arnd Bergmann wrote:
> Not sure if I'm following the reasoning here. Shouldn't the method be
> inherent to the virtio bus driver?
>
> When you use a PCI based virtio bus, the natural choice would be PIO
> in some way, but you could also have a different virtio implementation
> on PCI that uses hca
Jerone Young wrote:
> This patch is a continuation of the 7 patches sent earlier. This
> patch moves all x86 specific macros from include/linux/kvm.h to
> include/asm-x86/kvm.h.
>
> Signed-off-by: Jerone Young <[EMAIL PROTECTED]>
Acked-by: Carsten O
on the list.
>
> Signed-off-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 challen
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
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.
Stup
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
&
Zhang, Xiantao wrote:
> Patch [3/3] Add the hook kvm_arch_set_memory_region. In this patch,
> introduce a function kvm_caculate_mmu_pages to compute mmu pages in
> total, once memory region changes.diff --git a/drivers/kvm/kvm_main.c
> b/drivers/kvm/kvm_main.c
index bda733a..a4a32bd 100644
--- a
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 2
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 kvm_vm_ioctl_s
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:
> 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]>
--
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 grep
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
: Carsten Otte <[EMAIL PROTECTED]>
Zhang, Xiantao wrote:
> From: Zhang Xiantao <[EMAIL PROTECTED]>
> Move-some-x86-specific-part-from-kvm_init-to-kvm_arch
> Signed-off-by: Zhang Xiantao <[EMAIL PROTECTED]>
> ---
> drivers/kvm/kvm.h |5 +++--
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 migh
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: Splun
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]>
> ---
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 do
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]>
> 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
*Ouch*. Looks like I caused that. Very good.
Acked-by: Carsten Otte <[EMAIL PROTECTED]>
Zhang, Xiantao wrote:
> From: Zhang Xiantao <[EMAIL PROTECTED]>
> Move some includes to x86.c from kvm_main.c, since the related functions
> have been moved to x86.c
> Signed-off-b
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 c
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 com
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
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
I agree with the gernal idea of this patch. Just a few minor things to
pick on:
Zhang, Xiantao wrote:
> diff --git a/drivers/kvm/kvm.h b/drivers/kvm/kvm.h
> index 4b2421a..33b4629 100644
> --- a/drivers/kvm/kvm.h
> +++ b/drivers/kvm/kvm.h
> @@ -494,9 +494,9 @@ void vcpu_load(struct kvm_vcpu *vcpu
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, unsi
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 patche
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
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
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 h
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 f
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.
O
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
>&g
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
eries, 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
, emulator_get/set_dr,
kvm_report_emulation_failure, emulate_instruction
The following data type is moved to x86.c:
struct x86_emulate_ops emulate_ops
Signed-off-by: Carsten Otte <[EMAIL PROTECTED]>
---
kvm_main.c | 358
x86.c
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
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 b
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 kn
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
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
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, b
Dong, Eddie wrote:
> BTW, how S390 user/kernel interrupt signal is communicated?
Our s90host prototype does inject it from userspace, so there is no
need to have a call for that.
Nevertheless, I really love the lightweight exits that kvm has
invented and I want to use it on s390 with kvm too. In
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 understa
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
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:
> 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
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 PROTEC
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 f
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 <[EM
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 Blanc
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 one.
Izik Eidus wrote:
> yep,
> another cleanup is needed for:
> the rmap part, and the mmu cache size setting that found it way to the
> memory slot allocation function.
That's true, but can be subject of one of the next portability paches.
I want to keep each of them trivial and easily reviewable.
-
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 al
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).
Zhang, Xiantao wrote:
> I don't think we can move the whole function to arch-specific part,
> because it should work well (or with few issues) for most archs.
> Basically, IA64 mostly can use it directly. If we move them as
> arch-specific, it will introduces many duplicates. As you said, S390 has
Hollis Blanchard wrote:
> Izik's idea (as I understand it) is to have one ioctl registering all of
> RAM, and then multiple "configure slot" ioctls that tell the kernel how
> to divide that area into the guest physical address space. That seems
> more awkward to me and I don't seem a benefit.
I thi
Avi Kivity wrote:
> Carsten Otte wrote:
>> 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
>>
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
255
+---
x86.c | 258
+
3 files changed, 271 insertions(+), 249 deletions(-)
Signed-off-by: Carsten Otte <[EMAIL PROTECTED]>
---
diff --git a/drivers/kvm/kvm.h b/driver
Avi Kivity wrote:
> I was talking about x86.
>
> On x86, you need contiguous userspace, contiguous guest, but again,
> what's the problem with one memory slot?
There is no problem with one memory slot: it works. It's just that
Izik's idea gives us the opportunity to have common code for all four
Avi Kivity wrote:
> I don't really see a big difference between what we have now (sparse
> userspace, sparse guest) and Izik's idea (contiguous userspace, sparse
> guest). In both cases you need something like memory slots to describe
> the different sections.
We don't on s390: we receive a pag
101 - 200 of 323 matches
Mail list logo
