On 08/20/2014 07:03 AM, Hulin, Patrick - 0559 - MITLL wrote:
> Can you guys explain why calling tlb_fill is necessary on the page boundary
> case?
So that you trap on an unaligned store where the second page is unmapped.
That's what we get "for free" with running to store loop backward.
r~
On Aug 19, 2014, at 2:16 AM, Paolo Bonzini wrote:
> Il 18/08/2014 22:50, Hulin, Patrick - 0559 - MITLL ha scritto:
Correct. Doesn¹t work. Haven¹t fully diagnosed why, but it doesn¹t seem
to ever hit the current_tb_modified passage if you invalidate beforehand.
>> Yeah - mem_io_pc doesn¹
Il 18/08/2014 22:50, Hulin, Patrick - 0559 - MITLL ha scritto:
>> >Correct. Doesn¹t work. Haven¹t fully diagnosed why, but it doesn¹t seem
>> >to ever hit the current_tb_modified passage if you invalidate beforehand.
> Yeah - mem_io_pc doesn¹t get updated until we¹re inside io_write, so
> tb_invali
Il 18/08/2014 19:47, Hulin, Patrick - 0559 - MITLL ha scritto:
>> We'll have done the page for the first byte at the top of
>> helper_{le,be}_{ld,st}_name. When we discover it's an unaligned
>> access, we should load and check the pte for the second page. We
>> might have to shuffle those two te
On 8/18/14, 1:47 PM, "Hulin, Patrick - 0559 - MITLL"
wrote:
>On Aug 18, 2014, at 1:37 PM, Richard Henderson wrote:
>
>>On 08/16/2014 10:21 PM, Paolo Bonzini wrote:
>Would it work to just call tb_invalidate_phys_page_range before the
>helper_ret_stb loop?
>>I doubt it.
>
>Correct. Doesn¹
On 8/18/14, 1:47 PM, "Hulin, Patrick - 0559 - MITLL"
wrote:
>On Aug 17, 2014, at 1:21 AM, Paolo Bonzini wrote:
>
>> Il 15/08/2014 23:49, Hulin, Patrick - 0559 - MITLL ha scritto:
> In this case, the write is 8 bytes and unaligned, so it gets split
> into 8 single-byte writes. In stock QE
On Aug 17, 2014, at 1:21 AM, Paolo Bonzini wrote:
> Il 15/08/2014 23:49, Hulin, Patrick - 0559 - MITLL ha scritto:
In this case, the write is 8 bytes and unaligned, so it gets split
into 8 single-byte writes. In stock QEMU, these writes are done in
reverse order (see the loop in so
On Aug 18, 2014, at 1:37 PM, Richard Henderson wrote:
> On 08/16/2014 10:21 PM, Paolo Bonzini wrote:
Would it work to just call tb_invalidate_phys_page_range before the
helper_ret_stb loop?
>
> I doubt it.
Correct. Doesn’t work. Haven’t fully diagnosed why, but it doesn’t seem to eve
On 08/16/2014 10:21 PM, Paolo Bonzini wrote:
>>> Would it work to just call tb_invalidate_phys_page_range before the
>>> helper_ret_stb loop?
I doubt it.
>> Maybe. I think there’s another issue, which is that QEMU’s ending up
>> in the I/O read/write code instead of the normal memory RW. This cou
Il 15/08/2014 23:49, Hulin, Patrick - 0559 - MITLL ha scritto:
>>> In this case, the write is 8 bytes and unaligned, so it gets split
>>> into 8 single-byte writes. In stock QEMU, these writes are done in
>>> reverse order (see the loop in softmmu_template.h, line 402). The
>>> third decryption xor
On Aug 15, 2014, at 4:48 PM, Paolo Bonzini wrote:
> Il 13/08/2014 20:36, Hulin, Patrick - 0559 - MITLL ha scritto:
>> Hi QEMU devs,
>>
>> QEMU 2.10 does not currently run Windows 7 64-bit without KVM. There
>> have been a few threads about this over the past few years (such as
>> https://bugs.la
Il 13/08/2014 20:36, Hulin, Patrick - 0559 - MITLL ha scritto:
> Hi QEMU devs,
>
> QEMU 2.10 does not currently run Windows 7 64-bit without KVM. There
> have been a few threads about this over the past few years (such as
> https://bugs.launchpad.net/qemu/+bug/921208 and
> http://lists.gnu.org/arc
I suppose I should probably add a tl;dr.
I have a diagnosis of the reason Windows 7 64-bit won’t run without KVM, as
well as a hack to fix it, but I’d like input on a real fix.
Details below.
On Aug 13, 2014, at 2:36 PM, Hulin, Patrick - 0559 - MITLL
wrote:
> Hi QEMU devs,
>
> QEMU 2.10 doe
Hi QEMU devs,
QEMU 2.10 does not currently run Windows 7 64-bit without KVM. There have been
a few threads about this over the past few years (such as
https://bugs.launchpad.net/qemu/+bug/921208 and
http://lists.gnu.org/archive/html/qemu-devel/2012-09/msg02603.html), but the
problem was never
14 matches
Mail list logo