On 04/20/2010 06:32 AM, Sheng Yang wrote:
On Monday 19 April 2010 16:25:17 Avi Kivity wrote:
On 04/17/2010 09:12 PM, Avi Kivity wrote:
I think you were right the first time around.
Re-reading again (esp. the part about treatment of indirect NMI
vmexits), I think this was wron
On Monday 19 April 2010 16:25:17 Avi Kivity wrote:
> On 04/17/2010 09:12 PM, Avi Kivity wrote:
> > I think you were right the first time around.
>
> Re-reading again (esp. the part about treatment of indirect NMI
> vmexits), I think this was wrong, and that the code is correct. I am
> now thoroug
On 04/17/2010 09:12 PM, Avi Kivity wrote:
I think you were right the first time around.
Re-reading again (esp. the part about treatment of indirect NMI
vmexits), I think this was wrong, and that the code is correct. I am
now thoroughly confused.
--
error compiling committee.c: too many
On 04/15/2010 05:08 PM, Sheng Yang wrote:
On Thursday 15 April 2010 18:44:15 Avi Kivity wrote:
On 04/15/2010 01:40 PM, Joerg Roedel wrote:
That means an NMI that happens outside guest code (for example, in the
mmu, or during the exit itself) would be counted as if in guest code.
On Thursday 15 April 2010 18:44:15 Avi Kivity wrote:
> On 04/15/2010 01:40 PM, Joerg Roedel wrote:
> >> That means an NMI that happens outside guest code (for example, in the
> >> mmu, or during the exit itself) would be counted as if in guest code.
> >
> > Hmm, true. The same is true for an NMI th
On 04/15/2010 01:40 PM, Joerg Roedel wrote:
That means an NMI that happens outside guest code (for example, in the
mmu, or during the exit itself) would be counted as if in guest code.
Hmm, true. The same is true for an NMI that happens between VMSAVE and
STGI but that window is smaller.
On Thu, Apr 15, 2010 at 12:48:09PM +0300, Avi Kivity wrote:
> On 04/15/2010 12:44 PM, oerg Roedel wrote:
>>
>>> So, we'd need something like the following:
>>>
>>> if (exit == NMI)
>>> __get_cpu_var(nmi_vcpu) = vcpu;
>>>
>>> stgi();
>>>
>>> if (exit == NMI) {
>>> while (
On 04/15/2010 12:44 PM, oerg Roedel wrote:
So, we'd need something like the following:
if (exit == NMI)
__get_cpu_var(nmi_vcpu) = vcpu;
stgi();
if (exit == NMI) {
while (!nmi_handled())
cpu_relax();
__get_cpu_var(nmi_vcpu) = NULL;
}
On Thu, Apr 15, 2010 at 12:09:28PM +0300, Avi Kivity wrote:
> On 04/15/2010 12:04 PM, oerg Roedel wrote:
>> On Mon, Apr 15, 2030 at 04:57:38PM +0800, Zhang, Yanmin wrote:
>>
>>
>>> I checked svm.c and it seems svm.c doesn't trigger a NMI to host if the NMI
>>> happens in guest os. In addition,
On 04/15/2010 12:04 PM, oerg Roedel wrote:
On Mon, Apr 15, 2030 at 04:57:38PM +0800, Zhang, Yanmin wrote:
I checked svm.c and it seems svm.c doesn't trigger a NMI to host if the NMI
happens in guest os. In addition, svm_complete_interrupts is called after
interrupt is enabled.
Yes. T
On Mon, Apr 15, 2030 at 04:57:38PM +0800, Zhang, Yanmin wrote:
> I checked svm.c and it seems svm.c doesn't trigger a NMI to host if the NMI
> happens in guest os. In addition, svm_complete_interrupts is called after
> interrupt is enabled.
Yes. The NMI is held pending by the hardware until the S
On Thu, 2010-04-15 at 11:05 +0300, Avi Kivity wrote:
> On 04/15/2030 04:04 AM, Zhang, Yanmin wrote:
> >
> >> An even more accurate way to determine this is to check whether the
> >> interrupt frame points back at the 'int $2' instruction. However we
> >> plan to switch to a self-IPI method to inje
On 04/15/2030 04:04 AM, Zhang, Yanmin wrote:
An even more accurate way to determine this is to check whether the
interrupt frame points back at the 'int $2' instruction. However we
plan to switch to a self-IPI method to inject the NMI, and I'm not sure
wether APIC NMIs are accepted on an instr
On Wed, 2010-04-14 at 12:20 +0300, Avi Kivity wrote:
> On 04/14/2030 12:05 PM, Zhang, Yanmin wrote:
> > Here is the new patch of V3 against tip/master of April 13th
> > if anyone wants to try it.
> >
> >
>
> Thanks for persisting despite the flames.
>
> Can you please separate arch/x86/kvm pa
On 04/14/2010 01:43 PM, Ingo Molnar wrote:
Thanks for persisting despite the flames.
Can you please separate arch/x86/kvm part of the patch? That will make for
easier reviewing, and will need to go through separate trees.
Once it gets into a state that it can be applied could you please
* Avi Kivity wrote:
> On 04/14/2030 12:05 PM, Zhang, Yanmin wrote:
> >Here is the new patch of V3 against tip/master of April 13th
> >if anyone wants to try it.
> >
>
> Thanks for persisting despite the flames.
>
> Can you please separate arch/x86/kvm part of the patch? That will make for
>
On Wednesday 14 April 2010 18:33:37 Avi Kivity wrote:
> On 04/14/2010 01:27 PM, Sheng Yang wrote:
> >> Yes, interesting to see what the latency is. If it's reasonably short
> >> (and I expect it will be so), we can do the busy wait solution.
> >>
> >> If we have an NMI counter somewhere, we can si
On 04/14/2010 01:27 PM, Sheng Yang wrote:
Yes, interesting to see what the latency is. If it's reasonably short
(and I expect it will be so), we can do the busy wait solution.
If we have an NMI counter somewhere, we can simply wait until it changes.
Good idea. Of course we have one(at
On Wednesday 14 April 2010 18:19:49 Avi Kivity wrote:
> On 04/14/2010 01:14 PM, Sheng Yang wrote:
> >> I wouldn't like to depend on model specific behaviour.
> >>
> >> One option is to read all the information synchronously and store it in
> >> a per-cpu area with atomic instructions, then queue th
On 04/14/2010 01:14 PM, Sheng Yang wrote:
I wouldn't like to depend on model specific behaviour.
One option is to read all the information synchronously and store it in
a per-cpu area with atomic instructions, then queue the NMI. Another
option is to have another callback which tells us that
On Wednesday 14 April 2010 17:57:50 Avi Kivity wrote:
> On 04/14/2010 12:43 PM, Sheng Yang wrote:
> > On Wednesday 14 April 2010 17:20:15 Avi Kivity wrote:
> >> On 04/14/2030 12:05 PM, Zhang, Yanmin wrote:
> >>> Here is the new patch of V3 against tip/master of April 13th
> >>> if anyone wants to t
On 04/14/2010 12:43 PM, Sheng Yang wrote:
On Wednesday 14 April 2010 17:20:15 Avi Kivity wrote:
On 04/14/2030 12:05 PM, Zhang, Yanmin wrote:
Here is the new patch of V3 against tip/master of April 13th
if anyone wants to try it.
Thanks for persisting despite the flames.
Can
On Wednesday 14 April 2010 17:20:15 Avi Kivity wrote:
> On 04/14/2030 12:05 PM, Zhang, Yanmin wrote:
> > Here is the new patch of V3 against tip/master of April 13th
> > if anyone wants to try it.
>
> Thanks for persisting despite the flames.
>
> Can you please separate arch/x86/kvm part of the p
On 04/14/2030 12:05 PM, Zhang, Yanmin wrote:
Here is the new patch of V3 against tip/master of April 13th
if anyone wants to try it.
Thanks for persisting despite the flames.
Can you please separate arch/x86/kvm part of the patch? That will make
for easier reviewing, and will need to go
24 matches
Mail list logo
