Am Montag, 5. November 2007 schrieb Arnd Bergmann:
> Read again what I wrote above. I'm suggesting to have just one external
> interrupt for virtio and use the generic IRQ abstraction to handle
> everything that comes below that.
So you basically suggest to implement wrapper code around extint and
On Monday 05 November 2007, Carsten Otte wrote:
> > Actually, you have neither irq numbers nor vectors on s390 right now.
> > I/O subchannels are do not fit into the IRQ handling in Linux at
> > all, and external interrupts are sufficiently different that you
> > should not treat them as IRQ lines
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?
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 field
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
> 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?
Eddie
-
This SF.net email is
Carsten Otte wrote:
> 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 d
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
[EMAIL PROTECTED] wrote:
> 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 facil
Carsten Otte wrote:
> 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 faciliti
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
Carsten Otte wrote:
>
>>> In addition, I would love to be able to specify which target CPUs
>>> may receive that interrupt because our IPI equivalent comes out just
>>> like a regular interrupt on just one target CPU.
>>>
>>> That boils down to something like this:
>>> struct kvm_interrupt_data {
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
Carsten Otte wrote:
> 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
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
Carsten Otte wrote:
> I think we'll have to come up with a more modular approach later on:
> various aspects are of interest to various architectures and/or
> platforms. The generic kernel has CONFIG_FEATURE toggles for that.
> The portability patches are not intended to split kvm into components
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
OK, so how can a device inform kernel for an IRQ in S390?
>-Original Message-
>From: Carsten Otte [mailto:[EMAIL PROTECTED]
>Sent: 2007年10月30日 19:30
>To: Dong, Eddie
>Cc: Avi Kivity; Zhang, Xiantao; Hollis Blanchard;
>kvm-devel@lists.sourceforge.net
>Subject: Re:
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
>> 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 not.
>
Dong, Eddie wrote:
>
>
>
>> -Original Message-
>> From: [EMAIL PROTECTED]
>> [mailto:[EMAIL PROTECTED] On Behalf Of
>> Carsten Otte
>> Sent: 2007年10月26日 20:02
>> To: Avi Kivity; Zhang, Xiantao; Hollis Blanchard
>> Cc: kvm-devel@li
>-Original Message-
>From: [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED] On Behalf Of
>Carsten Otte
>Sent: 2007年10月26日 20:02
>To: Avi Kivity; Zhang, Xiantao; Hollis Blanchard
>Cc: kvm-devel@lists.sourceforge.net
>Subject: Re: [kvm-devel] RFC/patch portabilit
Acked-by: Hollis Blanchard <[EMAIL PROTECTED]>
On Fri, 2007-10-26 at 14:01 +0200, Carsten Otte wrote:
> This patch splits kvm_vm_ioctl into archtecture independent parts, and
> x86 specific parts which go to kvm_arch_vcpu_ioctl in x86.c.
> The patch has been updated to current git, and it leaves
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
This patch splits kvm_vm_ioctl into archtecture independent parts, and
x86 specific parts which go to kvm_arch_vcpu_ioctl in x86.c.
The patch has been updated to current git, and it leaves out memory slot
registration work which is currently subject to a detailed discussion.
Common ioctls for all
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 userspace allocated memory address,
>
> then we will will have to each arch "arch speci
Carsten Otte wrote:
> This patch splits kvm_vm_ioctl into archtecture independent parts, and
> x86 specific parts which go to kvm_arch_vcpu_ioctl in x86.c.
>
> Common ioctls for all architectures are:
> KVM_CREATE_VCPU, KVM_GET_DIRTY_LOG, KVM_SET_USER_MEMORY_REGION
>
> KVM_SET_USER_MEMORY_REGION
Hollis Blanchard wrote:
> On Thu, 2007-10-25 at 17:48 +0200, Izik Eidus wrote:
>
>> On Thu, 2007-10-25 at 17:48 +0200, Carsten Otte wrote:
>>
>>> This patch splits kvm_vm_ioctl into archtecture independent parts, and
>>> x86 specific parts which go to kvm_arch_vcpu_ioctl in x86.c.
>>>
>>>
On Thu, 2007-10-25 at 11:22 -0500, Hollis Blanchard wrote:
> On Thu, 2007-10-25 at 17:48 +0200, Izik Eidus wrote:
> > On Thu, 2007-10-25 at 17:48 +0200, Carsten Otte wrote:
> > > This patch splits kvm_vm_ioctl into archtecture independent parts, and
> > > x86 specific parts which go to kvm_arch_vcp
On Thu, 2007-10-25 at 17:48 +0200, Izik Eidus wrote:
> On Thu, 2007-10-25 at 17:48 +0200, Carsten Otte wrote:
> > This patch splits kvm_vm_ioctl into archtecture independent parts, and
> > x86 specific parts which go to kvm_arch_vcpu_ioctl in x86.c.
> >
> > Common ioctls for all architectures are
On Thu, 2007-10-25 at 17:48 +0200, Carsten Otte wrote:
> This patch splits kvm_vm_ioctl into archtecture independent parts, and
> x86 specific parts which go to kvm_arch_vcpu_ioctl in x86.c.
>
> Common ioctls for all architectures are:
> KVM_CREATE_VCPU, KVM_GET_DIRTY_LOG, KVM_SET_USER_MEMORY_REG
Carsten Otte wrote:
>
>
> 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_S
Carsten Otte wrote:
>
> 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_SE
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:
> 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 a
Carsten Otte wrote:
> This patch splits kvm_vm_ioctl into archtecture independent parts, and
> x86 specific parts which go to kvm_arch_vcpu_ioctl in x86.c.
>
> Common ioctls for all architectures are:
> KVM_CREATE_VCPU, KVM_GET_DIRTY_LOG
>
> I'd really like to see more commonalities, but all other
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 h
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
>> me
Carsten Otte wrote:
> This patch splits kvm_vm_ioctl into archtecture independent parts, and
> x86 specific parts which go to kvm_arch_vcpu_ioctl in x86.c.
>
> Common ioctls for all architectures are:
> KVM_CREATE_VCPU, KVM_GET_DIRTY_LOG
>
> I'd really like to see more commonalities, but all othe
Carsten Otte wrote:
> This patch splits kvm_vm_ioctl into archtecture independent parts, and
> x86 specific parts which go to kvm_arch_vcpu_ioctl in x86.c.
>
> Common ioctls for all architectures are:
> KVM_CREATE_VCPU, KVM_GET_DIRTY_LOG
>
> I'd really like to see more commonalities, but all other
Am Freitag, den 12.10.2007, 15:37 +0200 schrieb Arnd Bergmann:
> I assume the contents are ok, since you're just moving code around, but
> please
> write this 'Signed-off-by' and 'Reviewed-by' (capital letters), and
> include a diffstat for any patch that doesn't fit on a few pages
> of mail client
On Friday 12 October 2007, Carsten Otte wrote:
> This patch splits kvm_vm_ioctl into archtecture independent parts, and
> x86 specific parts which go to kvm_arch_vcpu_ioctl in x86.c.
>
I assume the contents are ok, since you're just moving code around, but
please
> signed-off-by: Carsten Otte <
43 matches
Mail list logo
