On Fri, 18 Apr 2008 10:25:15 -0500
Anthony Liguori <[EMAIL PROTECTED]> wrote:
> I'd prefer you not do an emulate_instruction loop at all. Just emulate
> one instruction on vmentry failure and let VT tell you what instructions
> you need to emulate.
>
> It's only four instructions so I don't th
Anthony Liguori wrote:
>
> I'd prefer you not do an emulate_instruction loop at all. Just
> emulate one instruction on vmentry failure and let VT tell you what
> instructions you need to emulate.
>
> It's only four instructions so I don't think the performance is going
> to matter. Take a look
Guillaume Thouvenin wrote:
> On Fri, 18 Apr 2008 08:23:07 -0500
> Anthony Liguori <[EMAIL PROTECTED]> wrote:
>
>
>
>> This doesn't seem right. You should have been able to break out of the
>> emulator long before encountering an out instruction. The next
>> instruction you encounter should
On Fri, 18 Apr 2008 08:23:07 -0500
Anthony Liguori <[EMAIL PROTECTED]> wrote:
> This doesn't seem right. You should have been able to break out of the
> emulator long before encountering an out instruction. The next
> instruction you encounter should be a mov instruction. Are you sure
> yo
Guillaume Thouvenin wrote:
> On Tue, 15 Apr 2008 16:06:43 +0300
> Avi Kivity <[EMAIL PROTECTED]> wrote:
>
>
>>> ...
>>> handle_vmentry_failure: invalid guest state
>>> handle_vmentry_failure: start emulation
>>> handle_vmentry_failure: emulation failed
>>>
>>>
>> What instruction faile
On Fri, 18 Apr 2008 14:18:16 +0200
Guillaume Thouvenin <[EMAIL PROTECTED]> wrote:
> I added the code do dump the instruction and it seems that it's the
> emulation of 0xe6 (== out imm8, al) that failed. I made modifications
> to emulate it (see below) and now I have another problem in kvm
> usersp
On Tue, 15 Apr 2008 16:06:43 +0300
Avi Kivity <[EMAIL PROTECTED]> wrote:
> > ...
> > handle_vmentry_failure: invalid guest state
> > handle_vmentry_failure: start emulation
> > handle_vmentry_failure: emulation failed
> >
>
> What instruction failed, exactly?
>
I added the code do dump the i
Guillaume Thouvenin wrote:
> On Mon, 07 Apr 2008 11:05:06 -0500
> Anthony Liguori <[EMAIL PROTECTED]> wrote:
>
>
>> Perhaps a viable way to fix this upstream would be to catch the vmentry
>> failure, look to see if SS.CPL != CS.CPL, and if so, invoke
>> x86_emulate() in a loop until SS.CPL ==
On Mon, 07 Apr 2008 11:05:06 -0500
Anthony Liguori <[EMAIL PROTECTED]> wrote:
> Perhaps a viable way to fix this upstream would be to catch the vmentry
> failure, look to see if SS.CPL != CS.CPL, and if so, invoke
> x86_emulate() in a loop until SS.CPL == CS.CPL.
>
> There are very few instruct
Guillaume Thouvenin wrote:
>>>
>>>
>> x86 emulate is missing support for jmp far which is used to switch into
>> protected mode. It just needs to be added.
>>
>
> Ok I see. I understand now why you said in a previous email that KVM
> needs to have a proper load_seg() function like
On Tue, 08 Apr 2008 07:14:13 -0500
Anthony Liguori <[EMAIL PROTECTED]> wrote:
> Guillaume Thouvenin wrote:
> > On Mon, 07 Apr 2008 11:05:06 -0500
> > Anthony Liguori <[EMAIL PROTECTED]> wrote:
> >
> >
> >> Perhaps a viable way to fix this upstream would be to catch the vmentry
> >> failure, lo
Guillaume Thouvenin wrote:
> On Mon, 07 Apr 2008 11:05:06 -0500
> Anthony Liguori <[EMAIL PROTECTED]> wrote:
>
>
>> Perhaps a viable way to fix this upstream would be to catch the vmentry
>> failure, look to see if SS.CPL != CS.CPL, and if so, invoke
>> x86_emulate() in a loop until SS.CPL ==
On Mon, 07 Apr 2008 11:05:06 -0500
Anthony Liguori <[EMAIL PROTECTED]> wrote:
> Perhaps a viable way to fix this upstream would be to catch the vmentry
> failure, look to see if SS.CPL != CS.CPL, and if so, invoke
> x86_emulate() in a loop until SS.CPL == CS.CPL.
I tried this solution some time
Anthony Liguori wrote:
> Yes, but it won't compile as KVM does not have a proper load_seg()
> function like the Xen's x86_emulate.
Izik added something for task switching (see load_segment_descriptor).
--
Any sufficiently difficult bug is indistinguishable from a feature.
Alexander Graf wrote:
>
> On Apr 7, 2008, at 6:51 PM, Anthony Liguori wrote:
>
>> Alexander Graf wrote:
>>>
>>> On Apr 7, 2008, at 6:05 PM, Anthony Liguori wrote:
>>>
Alexander Graf wrote:
> Hi,
>
> this is an improved version of the patch I sent several weeks ago to
> this lis
On Apr 7, 2008, at 6:51 PM, Anthony Liguori wrote:
> Alexander Graf wrote:
>>
>> On Apr 7, 2008, at 6:05 PM, Anthony Liguori wrote:
>>
>>> Alexander Graf wrote:
Hi,
this is an improved version of the patch I sent several weeks ago
to
this list. Functionally nothing chan
Alexander Graf wrote:
On Apr 7, 2008, at 6:05 PM, Anthony Liguori wrote:
Alexander Graf wrote:
Hi,
this is an improved version of the patch I sent several weeks ago to
this list. Functionally nothing changed; it still hacks into gfxboot
and
patches it to work on Intel CPUs on the fly. The
On Apr 7, 2008, at 6:05 PM, Anthony Liguori wrote:
> Alexander Graf wrote:
>> Hi,
>>
>> this is an improved version of the patch I sent several weeks ago to
>> this list. Functionally nothing changed; it still hacks into
>> gfxboot and
>> patches it to work on Intel CPUs on the fly. The big dif
Alexander Graf wrote:
> Hi,
>
> this is an improved version of the patch I sent several weeks ago to
> this list. Functionally nothing changed; it still hacks into gfxboot and
> patches it to work on Intel CPUs on the fly. The big difference is that
> this version is cleaned up and should work with
Hi,
this is an improved version of the patch I sent several weeks ago to
this list. Functionally nothing changed; it still hacks into gfxboot and
patches it to work on Intel CPUs on the fly. The big difference is that
this version is cleaned up and should work with every future CPU available.
Ple
20 matches
Mail list logo
