On Thu, Jul 30, 2009 at 02:47:30PM +0300, Gleb Natapov wrote:
> On Thu, Jul 30, 2009 at 02:46:59PM +0300, Avi Kivity wrote:
> > On 07/30/2009 02:24 PM, Gleb Natapov wrote:
> >>> Good (it was one of the goals of the original interrupt rework, ~2 years
> >>> ago)
> >>>
> >>>
> >> But if we emul
On Thu, Jul 30, 2009 at 02:46:59PM +0300, Avi Kivity wrote:
> On 07/30/2009 02:24 PM, Gleb Natapov wrote:
>>> Good (it was one of the goals of the original interrupt rework, ~2 years
>>> ago)
>>>
>>>
>> But if we emulate an injection by playing with guest memory and
>> registers we have to be
On 07/30/2009 02:24 PM, Gleb Natapov wrote:
Good (it was one of the goals of the original interrupt rework, ~2 years
ago)
But if we emulate an injection by playing with guest memory and
registers we have to be sure we do it only once.
Once we've successfully updated the stack, injec
On Thu, Jul 30, 2009 at 02:26:24PM +0300, Avi Kivity wrote:
> On 07/30/2009 02:16 PM, Gleb Natapov wrote:
>>> I think there's little reason now. One thing we need to do is make it
>>> possible to call the injection code twice without entering the guest. I
>>> think right now it assumes nothing ha
On 07/30/2009 02:16 PM, Gleb Natapov wrote:
I think there's little reason now. One thing we need to do is make it
possible to call the injection code twice without entering the guest. I
think right now it assumes nothing has been injected.
I Looked at this and it seems the current code
On Thu, Jul 30, 2009 at 02:16:30PM +0300, Avi Kivity wrote:
> On 07/29/2009 05:07 PM, Marcelo Tosatti wrote:
>>> The downside is that we're moving a vmx specific hack to common code.
>>>
>>> I think this could be simplified if interrupt injection happened outside
>>> the critical section. This is
On 07/29/2009 05:07 PM, Marcelo Tosatti wrote:
The downside is that we're moving a vmx specific hack to common code.
I think this could be simplified if interrupt injection happened outside
the critical section. This is needed anyway because emulated interrupt
injection needs to access guest me
On Wed, Jul 29, 2009 at 11:07:16AM -0300, Marcelo Tosatti wrote:
> On Wed, Jul 29, 2009 at 03:44:20PM +0300, Avi Kivity wrote:
> > On 07/29/2009 03:24 PM, Marcelo Tosatti wrote:
> >> On Thu, Jul 23, 2009 at 06:45:53PM -0300, Marcelo Tosatti wrote:
> >>
> >>> On Wed, Jul 22, 2009 at 11:53:26PM +
On Wed, Jul 29, 2009 at 03:44:20PM +0300, Avi Kivity wrote:
> On 07/29/2009 03:24 PM, Marcelo Tosatti wrote:
>> On Thu, Jul 23, 2009 at 06:45:53PM -0300, Marcelo Tosatti wrote:
>>
>>> On Wed, Jul 22, 2009 at 11:53:26PM +0200, Jan Kiszka wrote:
>>>
Release and re-acquire preemption an
On 07/29/2009 03:24 PM, Marcelo Tosatti wrote:
On Thu, Jul 23, 2009 at 06:45:53PM -0300, Marcelo Tosatti wrote:
On Wed, Jul 22, 2009 at 11:53:26PM +0200, Jan Kiszka wrote:
Release and re-acquire preemption and IRQ lock in the same order as
vcpu_enter_guest does.
This should h
On Thu, Jul 23, 2009 at 06:45:53PM -0300, Marcelo Tosatti wrote:
> On Wed, Jul 22, 2009 at 11:53:26PM +0200, Jan Kiszka wrote:
> > Release and re-acquire preemption and IRQ lock in the same order as
> > vcpu_enter_guest does.
>
> This should happen in vcpu_enter_guest, before it decides to disable
On 07/26/2009 05:55 PM, Jan Kiszka wrote:
Presumably there's a reschedule interrupt queued; I think if you set the
reschedule bit you have to IPI the cpu running the task.
Yeah. But as we preempt_disable first, that one might have been
processed already.
Ah, yes. Thanks.
--
error
Avi Kivity wrote:
> On 07/26/2009 05:38 PM, Jan Kiszka wrote:
>> Avi Kivity wrote:
>>
>>> On 07/26/2009 05:23 PM, Jan Kiszka wrote:
>>>
> btw, what does it fix? a debug warning?
>
>
>
I haven't seen anything in the wild, and I don't think it would raise a
>>>
On 07/26/2009 05:38 PM, Jan Kiszka wrote:
Avi Kivity wrote:
On 07/26/2009 05:23 PM, Jan Kiszka wrote:
btw, what does it fix? a debug warning?
I haven't seen anything in the wild, and I don't think it would raise a
warning. All it should cause is a potential delay of some
Avi Kivity wrote:
> On 07/26/2009 05:23 PM, Jan Kiszka wrote:
>>> btw, what does it fix? a debug warning?
>>>
>>>
>>
>> I haven't seen anything in the wild, and I don't think it would raise a
>> warning. All it should cause is a potential delay of some pending
>> reschedule as preempt_enable
On 07/26/2009 05:23 PM, Jan Kiszka wrote:
btw, what does it fix? a debug warning?
I haven't seen anything in the wild, and I don't think it would raise a
warning. All it should cause is a potential delay of some pending
reschedule as preempt_enable will not fire under local_irq_disable.
Avi Kivity wrote:
> On 07/24/2009 10:00 AM, Jan Kiszka wrote:
>> Marcelo Tosatti wrote:
>>
>>> On Wed, Jul 22, 2009 at 11:53:26PM +0200, Jan Kiszka wrote:
>>>
Release and re-acquire preemption and IRQ lock in the same order as
vcpu_enter_guest does.
>>> This should ha
On 07/24/2009 10:00 AM, Jan Kiszka wrote:
Marcelo Tosatti wrote:
On Wed, Jul 22, 2009 at 11:53:26PM +0200, Jan Kiszka wrote:
Release and re-acquire preemption and IRQ lock in the same order as
vcpu_enter_guest does.
This should happen in vcpu_enter_guest, before it decides to
Marcelo Tosatti wrote:
> On Wed, Jul 22, 2009 at 11:53:26PM +0200, Jan Kiszka wrote:
>> Release and re-acquire preemption and IRQ lock in the same order as
>> vcpu_enter_guest does.
>
> This should happen in vcpu_enter_guest, before it decides to disable
> preemption/irqs (so you consolidate the c
On Wed, Jul 22, 2009 at 11:53:26PM +0200, Jan Kiszka wrote:
> Release and re-acquire preemption and IRQ lock in the same order as
> vcpu_enter_guest does.
This should happen in vcpu_enter_guest, before it decides to disable
preemption/irqs (so you consolidate the control there).
Maybe add a new m
20 matches
Mail list logo
