On 23/06/2020 12:25, Paolo Bonzini wrote:
> On 23/06/20 11:34, Liran Alon wrote:
>> Having said that, I believe the compatibility risk here is very small
>> and therefore because QEMU 5.0 was
>> released for a very short time-span before these patches were merged,
>> I'm not sure it's really prefer
On 23/06/20 11:34, Liran Alon wrote:
> Having said that, I believe the compatibility risk here is very small
> and therefore because QEMU 5.0 was
> released for a very short time-span before these patches were merged,
> I'm not sure it's really preferable
> to move these flags to hw_compat_5_0[]. B
On 23/06/2020 11:46, Laurent Vivier wrote:
On 11/06/2020 21:43, Paolo Bonzini wrote:
From: Liran Alon
vmport_ioport_read() returns the value that should propagate to vCPU EAX
register when guest reads VMPort IOPort (i.e. By x86 IN instruction).
However, because vmport_ioport_read() calls cp
On 11/06/2020 21:43, Paolo Bonzini wrote:
> From: Liran Alon
>
> vmport_ioport_read() returns the value that should propagate to vCPU EAX
> register when guest reads VMPort IOPort (i.e. By x86 IN instruction).
>
> However, because vmport_ioport_read() calls cpu_synchronize_state(), the
> returne
From: Liran Alon
vmport_ioport_read() returns the value that should propagate to vCPU EAX
register when guest reads VMPort IOPort (i.e. By x86 IN instruction).
However, because vmport_ioport_read() calls cpu_synchronize_state(), the
returned value gets overridden by the value in QEMU vCPU EAX re
