On 2/1/19 8:49 AM, Andrew Cooper wrote:
> c/s 9338a37d "x86/svm: implement debug events" added support for introspecting
> ICEBP debug exceptions, but didn't account for the fact that
> svm_get_insn_len() (previously __get_instruction_length) can fail and may
> already raise #GP for the guest.
>
>>> On 04.02.19 at 20:44, wrote:
> On 04/02/2019 09:16, Jan Beulich wrote:
> On 01.02.19 at 18:09, wrote:
>>> A subsequent #DB getting raised causes #GP to turn into #DF.
>> The table on the #DF page clearly says
>> otherwise, at least according to my reading.
>
> Hmm - so it does. Looks
>>> On 04.02.19 at 20:44, wrote:
> On 04/02/2019 09:16, Jan Beulich wrote:
> On 01.02.19 at 18:09, wrote:
>>> On 01/02/2019 16:55, Jan Beulich wrote:
>>> On 01.02.19 at 17:25, wrote:
> If it were just getting insn_len incorrectly as 0, then the guest would
> livelock as we
On 04/02/2019 09:16, Jan Beulich wrote:
On 01.02.19 at 18:09, wrote:
>> On 01/02/2019 16:55, Jan Beulich wrote:
>> On 01.02.19 at 17:25, wrote:
If it were just getting insn_len incorrectly as 0, then the guest would
livelock as we wouldn't inject the #DB with trap semantics it
>>> On 01.02.19 at 18:09, wrote:
> On 01/02/2019 16:55, Jan Beulich wrote:
> On 01.02.19 at 17:25, wrote:
>>> If it were just getting insn_len incorrectly as 0, then the guest would
>>> livelock as we wouldn't inject the #DB with trap semantics it requires,
>> I'm confused again: Why trap
On 01/02/2019 16:55, Jan Beulich wrote:
On 01.02.19 at 17:25, wrote:
>> On 01/02/2019 15:58, Jan Beulich wrote:
>> On 01.02.19 at 15:49, wrote:
c/s 9338a37d "x86/svm: implement debug events" added support for
introspecting
ICEBP debug exceptions, but didn't account for
>>> On 01.02.19 at 17:25, wrote:
> On 01/02/2019 15:58, Jan Beulich wrote:
> On 01.02.19 at 15:49, wrote:
>>> c/s 9338a37d "x86/svm: implement debug events" added support for
>>> introspecting
>>> ICEBP debug exceptions, but didn't account for the fact that
>>> svm_get_insn_len()
On 01/02/2019 15:58, Jan Beulich wrote:
On 01.02.19 at 15:49, wrote:
>> c/s 9338a37d "x86/svm: implement debug events" added support for
>> introspecting
>> ICEBP debug exceptions, but didn't account for the fact that
>> svm_get_insn_len() (previously __get_instruction_length) can fail and
>>> On 01.02.19 at 15:49, wrote:
> c/s 9338a37d "x86/svm: implement debug events" added support for introspecting
> ICEBP debug exceptions, but didn't account for the fact that
> svm_get_insn_len() (previously __get_instruction_length) can fail and may
> already raise #GP for the guest.
>
> If
On Fri, Feb 1, 2019 at 7:49 AM Andrew Cooper wrote:
>
> c/s 9338a37d "x86/svm: implement debug events" added support for introspecting
> ICEBP debug exceptions, but didn't account for the fact that
> svm_get_insn_len() (previously __get_instruction_length) can fail and may
> already raise #GP for
On 2/1/19 4:49 PM, Andrew Cooper wrote:
c/s 9338a37d "x86/svm: implement debug events" added support for introspecting
ICEBP debug exceptions, but didn't account for the fact that
svm_get_insn_len() (previously __get_instruction_length) can fail and may
already raise #GP for the guest.
If
On 01/02/2019 15:49, Andrew Cooper wrote:
> c/s 9338a37d "x86/svm: implement debug events" added support for introspecting
> ICEBP debug exceptions, but didn't account for the fact that
> svm_get_insn_len() (previously __get_instruction_length) can fail and may
> already raise #GP for the guest.
>
On 01/02/2019 14:52, Tamas K Lengyel wrote:
> On Fri, Feb 1, 2019 at 7:49 AM Andrew Cooper
> wrote:
>> c/s 9338a37d "x86/svm: implement debug events" added support for
>> introspecting
>> ICEBP debug exceptions, but didn't account for the fact that
>> svm_get_insn_len() (previously
13 matches
Mail list logo
