On 04/30/15 11:23, Paolo Bonzini wrote:
>
>
> On 30/04/2015 17:15, Don Slutz wrote:
>> That is a possibility. It did not look simple to access CPUX86State
>> where I needed to check HF2_VMPORT_HACK_MASK. Instead of the
>> save/restore I could add it both places.
>
> Why not? This:
>
> @@ -25
On 30/04/2015 17:15, Don Slutz wrote:
>>> This is done by adding a new machine property vmware-port-ring3 that
>>> needs to be enabled to have any effect. It only effects accel=tcg
>>> mode. It is needed if you want to use VMware tools in accel=tcg
>>> mode.
>>
>> How does it work on KVM or Xe
On 30/04/2015 17:15, Don Slutz wrote:
> That is a possibility. It did not look simple to access CPUX86State
> where I needed to check HF2_VMPORT_HACK_MASK. Instead of the
> save/restore I could add it both places.
Why not? This:
@@ -2566,6 +2566,12 @@ static inline void check_io(CPUX86State
On 04/30/15 09:54, Paolo Bonzini wrote:
> On 30/04/2015 15:32, Don Slutz wrote:
>> This is done by adding a new machine property vmware-port-ring3 that
>> needs to be enabled to have any effect. It only effects accel=tcg
>> mode. It is needed if you want to use VMware tools in accel=tcg
>> mode.
On 30/04/2015 15:32, Don Slutz wrote:
> This is done by adding a new machine property vmware-port-ring3 that
> needs to be enabled to have any effect. It only effects accel=tcg
> mode. It is needed if you want to use VMware tools in accel=tcg
> mode.
How does it work on KVM or Xen?
>
> diff
This is done by adding a new machine property vmware-port-ring3 that
needs to be enabled to have any effect. It only effects accel=tcg
mode. It is needed if you want to use VMware tools in accel=tcg
mode.
Signed-off-by: Don Slutz
(cherry picked from commit 6d99c91fc9ae27b476e89a8cc880b4a46e2375
