On 2012-07-24 10:54, Peter Maydell wrote:
> On 24 July 2012 09:50, Avi Kivity wrote:
>> On 07/23/2012 08:58 PM, Peter Maydell wrote:
>>> The other related thing that
>>> might be surprising for x86-background people is that being
>>> able to present the guest with a virtual CPU that looks like
>>>
On 07/23/2012 06:19 PM, Peter Maydell wrote:
> On 23 July 2012 13:26, Avi Kivity wrote:
>> On 07/21/2012 11:54 AM, Peter Maydell wrote:
>>> The reason I want to get rid of common-code uses of kvm_irqchip_in_kernel()
>>> is because I think they're all similar to this -- the common code is
>>> using
On 24 July 2012 09:50, Avi Kivity wrote:
> On 07/23/2012 08:58 PM, Peter Maydell wrote:
>> The other related thing that
>> might be surprising for x86-background people is that being
>> able to present the guest with a virtual CPU that looks like
>> a pre-virtualization CPU (eg the A9) isn't reall
On 07/23/2012 08:58 PM, Peter Maydell wrote:
> On 23 July 2012 15:30, Avi Kivity wrote:
>> But I was only joking. Nested virtualization is interesting technically
>> but so far I haven't seen any huge or even small uptake.
>
> Yes; that (as I understand it) is why it wasn't an expected use
> cas
On 23 July 2012 15:30, Avi Kivity wrote:
> But I was only joking. Nested virtualization is interesting technically
> but so far I haven't seen any huge or even small uptake.
Yes; that (as I understand it) is why it wasn't an expected use
case for the architecture extensions. The other related th
On 2012-07-23 19:41, Peter Maydell wrote:
> On 23 July 2012 17:55, Jan Kiszka wrote:
>> On 2012-07-23 17:19, Peter Maydell wrote:
>>> OK, let's see if we can get some agreement about naming here.
>>>
>>> First, some test-functions I think we definitely need:
>>>
>>> kvm_interrupts_are_async()
>>>
On 23 July 2012 17:55, Jan Kiszka wrote:
> On 2012-07-23 17:19, Peter Maydell wrote:
>> OK, let's see if we can get some agreement about naming here.
>>
>> First, some test-functions I think we definitely need:
>>
>> kvm_interrupts_are_async()
>>-- true if interrupt delivery is asynchronous
>
On 2012-07-23 17:19, Peter Maydell wrote:
> On 23 July 2012 13:26, Avi Kivity wrote:
>> On 07/21/2012 11:54 AM, Peter Maydell wrote:
>>> The reason I want to get rid of common-code uses of kvm_irqchip_in_kernel()
>>> is because I think they're all similar to this -- the common code is
>>> using th
On 23 July 2012 13:26, Avi Kivity wrote:
> On 07/21/2012 11:54 AM, Peter Maydell wrote:
>> The reason I want to get rid of common-code uses of kvm_irqchip_in_kernel()
>> is because I think they're all similar to this -- the common code is
>> using the check as a proxy for something else, and it sh
On Mon, 23 Jul 2012 17:27:47 +0300
Avi Kivity wrote:
> On 07/23/2012 04:55 PM, Cornelia Huck wrote:
> >> > Basically, we have some flags in our control block we can set so that
> >> > the cpu drops out of SIE whenever external/I/O/... interrupts are
> >> > enabled and then have the host do the lo
On 07/23/2012 04:50 PM, Peter Maydell wrote:
>>
>> Yet.
>
> There is no mechanism in the virtualization extensions to either
> trap on or present a false value for guest accesses to the CPSR
> mode bits. So you can't make the guest OS think it is in Hypervisor
> mode. Therefore you can't provide t
On 07/23/2012 04:55 PM, Cornelia Huck wrote:
>> > Basically, we have some flags in our control block we can set so that
>> > the cpu drops out of SIE whenever external/I/O/... interrupts are
>> > enabled and then have the host do the lowcore updates, psw swaps, etc.
>>
>> Can you write them from a
On Mon, 23 Jul 2012 16:14:02 +0300
Avi Kivity wrote:
> On 07/23/2012 04:06 PM, Cornelia Huck wrote:
> > On Mon, 23 Jul 2012 15:18:49 +0300
> > Avi Kivity wrote:
> >
> >> > So, for example, if a specific subchannel (=device) has pending status
> >> > and an I/O interrupt is to be generated, this
On 23 July 2012 14:38, Avi Kivity wrote:
> On 07/23/2012 04:27 PM, Peter Maydell wrote:
>> That seems reasonable, although we have an awkward ordering issue
>> in KVM as it stands: KVM_CREATE_IRQCHIP needs to be called before
>> we start creating VCPU threads (at the moment it is done via kvm_init
On 07/23/2012 04:27 PM, Peter Maydell wrote:
> On 23 July 2012 14:09, Avi Kivity wrote:
>> On 07/23/2012 03:58 PM, Peter Maydell wrote:
>>> So should we be using something other than KVM_CREATE_IRQCHIP to
>>> ask the kernel to create a GIC model for us (and leave KVM_CREATE_IRQCHIP
>>> as a dummy
On 23 July 2012 14:09, Avi Kivity wrote:
> On 07/23/2012 03:58 PM, Peter Maydell wrote:
>> So should we be using something other than KVM_CREATE_IRQCHIP to
>> ask the kernel to create a GIC model for us (and leave KVM_CREATE_IRQCHIP
>> as a dummy "always succeed" ioctl)?
>
> Some time ago I sugges
On 07/23/2012 04:06 PM, Cornelia Huck wrote:
> On Mon, 23 Jul 2012 15:18:49 +0300
> Avi Kivity wrote:
>
>> > So, for example, if a specific subchannel (=device) has pending status
>> > and an I/O interrupt is to be generated, this interrupt remains pending
>> > until an arbitrary cpu is enabled f
On 07/23/2012 03:58 PM, Peter Maydell wrote:
> On 23 July 2012 13:26, Avi Kivity wrote:
>> Really, "irqchip in kernel" means asynchronous interrupts - you can
>> inject an interrupt from outside the vcpu thread. Obviously if the vcpu
>> is sleeping you need to wake it up and that pulls in idle ma
On Mon, 23 Jul 2012 15:18:49 +0300
Avi Kivity wrote:
> > So, for example, if a specific subchannel (=device) has pending status
> > and an I/O interrupt is to be generated, this interrupt remains pending
> > until an arbitrary cpu is enabled for I/O interrupts. If several cpus
> > are enabled for
On 23 July 2012 13:26, Avi Kivity wrote:
> Really, "irqchip in kernel" means asynchronous interrupts - you can
> inject an interrupt from outside the vcpu thread. Obviously if the vcpu
> is sleeping you need to wake it up and that pulls in idle management.
>
> "irqchip" for x86 really means the l
On 07/23/2012 03:31 PM, Avi Kivity wrote:
> On 07/23/2012 03:25 PM, Peter Maydell wrote:
>> On 23 July 2012 13:18, Avi Kivity wrote:
>>> While you don't have an irqchip, you do have asynchronous interrupt
>>> injection, yes? That's what irqchip really is all about.
>>
>> This seems an odd point
On 07/23/2012 03:25 PM, Peter Maydell wrote:
> On 23 July 2012 13:18, Avi Kivity wrote:
>> While you don't have an irqchip, you do have asynchronous interrupt
>> injection, yes? That's what irqchip really is all about.
>
> This seems an odd point of view -- async interrupt injection
> doesn't h
On 07/21/2012 11:54 AM, Peter Maydell wrote:
> On 21 July 2012 07:57, Jan Kiszka wrote:
>> On 2012-07-20 21:14, Peter Maydell wrote:
>>> I'm sure this isn't the only x86ism in the KVM generic source
>>> files. However the thing I'm specifically trying to do is
>>> nuke all the uses of kvm_irqchip_
On 23 July 2012 13:18, Avi Kivity wrote:
> While you don't have an irqchip, you do have asynchronous interrupt
> injection, yes? That's what irqchip really is all about.
This seems an odd point of view -- async interrupt injection
doesn't have anything to do with whether we're modelling
the irq
On 07/23/2012 03:04 PM, Cornelia Huck wrote:
>
> OK, so I was reading through this thread since I want to add irqfd
> support for s390, but we don't have any kind of "irqchip".
>
> The understanding I got so far is that !s390 architectures have some
> kind of mechanism that allows them to "route"
On Sat, 21 Jul 2012 15:16:56 +0200
Jan Kiszka wrote:
> On 2012-07-21 14:57, Peter Maydell wrote:
> > On 21 July 2012 13:35, Jan Kiszka wrote:
> >> On 2012-07-21 14:17, Peter Maydell wrote:
> >>> You still haven't really explained why we can't just ignore irqfd
> >>> for now. I don't see how it w
On 2012-07-21 14:57, Peter Maydell wrote:
> On 21 July 2012 13:35, Jan Kiszka wrote:
>> On 2012-07-21 14:17, Peter Maydell wrote:
>>> You still haven't really explained why we can't just ignore irqfd
>>> for now. I don't see how it would particularly affect the design
>>> of the kernel implementat
On 21 July 2012 13:35, Jan Kiszka wrote:
> On 2012-07-21 14:17, Peter Maydell wrote:
>> You still haven't really explained why we can't just ignore irqfd
>> for now. I don't see how it would particularly affect the design
>> of the kernel implementation very much, and the userspace interface
>> se
On 2012-07-21 14:17, Peter Maydell wrote:
> On 21 July 2012 12:08, Jan Kiszka wrote:
>> On 2012-07-21 12:53, Peter Maydell wrote:
>>> This is still sounding like "there is an extra feature which you should
>>> probably implement at some point and should certainly design with the
>>> intention of s
On 21 July 2012 12:08, Jan Kiszka wrote:
> On 2012-07-21 12:53, Peter Maydell wrote:
>> This is still sounding like "there is an extra feature which you should
>> probably implement at some point and should certainly design with the
>> intention of supporting", not "you cannot have an irqchip with
On 2012-07-21 12:53, Peter Maydell wrote:
> On 21 July 2012 11:22, Jan Kiszka wrote:
>> On 2012-07-21 11:56, Peter Maydell wrote:
>>> Or are you trying to talk about defining interrupt routes when the
>>> source and destination are both kernel code but the route needs to
>>> be set by userspace (i
On 21 July 2012 11:22, Jan Kiszka wrote:
> On 2012-07-21 11:56, Peter Maydell wrote:
>> Or are you trying to talk about defining interrupt routes when the
>> source and destination are both kernel code but the route needs to
>> be set by userspace (ie is machine specific not cpu specific)?
>
> It
On 2012-07-21 11:56, Peter Maydell wrote:
> On 21 July 2012 10:44, Jan Kiszka wrote:
>> On 2012-07-21 11:30, Peter Maydell wrote:
>>> On 21 July 2012 10:14, Jan Kiszka wrote:
On 2012-07-21 10:54, Peter Maydell wrote:
> On 21 July 2012 07:57, Jan Kiszka wrote:
Naming is x86 specific
On 21 July 2012 10:44, Jan Kiszka wrote:
> On 2012-07-21 11:30, Peter Maydell wrote:
>> On 21 July 2012 10:14, Jan Kiszka wrote:
>>> On 2012-07-21 10:54, Peter Maydell wrote:
On 21 July 2012 07:57, Jan Kiszka wrote:
>>> Naming is x86 specific, semantic not. It means that KVM doesn't prevent
On 2012-07-21 11:30, Peter Maydell wrote:
> On 21 July 2012 10:14, Jan Kiszka wrote:
>> On 2012-07-21 10:54, Peter Maydell wrote:
>>> On 21 July 2012 07:57, Jan Kiszka wrote:
On 2012-07-20 21:14, Peter Maydell wrote:
> I'm sure this isn't the only x86ism in the KVM generic source
> f
On 21 July 2012 10:14, Jan Kiszka wrote:
> On 2012-07-21 10:54, Peter Maydell wrote:
>> On 21 July 2012 07:57, Jan Kiszka wrote:
>>> On 2012-07-20 21:14, Peter Maydell wrote:
I'm sure this isn't the only x86ism in the KVM generic source
files. However the thing I'm specifically trying t
On 2012-07-21 10:54, Peter Maydell wrote:
> On 21 July 2012 07:57, Jan Kiszka wrote:
>> On 2012-07-20 21:14, Peter Maydell wrote:
>>> I'm sure this isn't the only x86ism in the KVM generic source
>>> files. However the thing I'm specifically trying to do is
>>> nuke all the uses of kvm_irqchip_in_
On 21 July 2012 07:57, Jan Kiszka wrote:
> On 2012-07-20 21:14, Peter Maydell wrote:
>> I'm sure this isn't the only x86ism in the KVM generic source
>> files. However the thing I'm specifically trying to do is
>> nuke all the uses of kvm_irqchip_in_kernel() in common code,
>
> No, "irqchip in ker
On 2012-07-20 21:14, Peter Maydell wrote:
> kvm_allows_irq0_override() is a totally x86 specific concept:
> move it to the target-specific source file where it belongs.
> This means we need a new header file for the prototype:
> kvm_i386.h, in line with the existing kvm_ppc.h.
First of all, the pa
kvm_allows_irq0_override() is a totally x86 specific concept:
move it to the target-specific source file where it belongs.
This means we need a new header file for the prototype:
kvm_i386.h, in line with the existing kvm_ppc.h.
Signed-off-by: Peter Maydell
---
I'm sure this isn't the only x86ism
40 matches
Mail list logo
