Re: [Xen-devel] [PATCH] xen: fix initialization of wallclock time for PVHVM on migration

["Egger, Christoph" <chegger@xxxxxxxxx>]

On 11.06.13 16:04, Jan Beulich wrote:
>>>> On 11.06.13 at 15:59, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
>> On Tue, 2013-06-11 at 13:12 +0100, Jan Beulich wrote:
>>>>>> On 11.06.13 at 14:01, George Dunlap <george.dunlap@xxxxxxxxxxxxx> wrote:
>>>> On 06/11/2013 12:59 PM, Jan Beulich wrote:
>>>>>>>> On 11.06.13 at 12:46, Roger Pau Monne <roger.pau@xxxxxxxxxx> wrote:
>>>>>> The initial values of the wallclock time in the shared info page are
>>>>>> set for PVHVM guests when the hypercall page is initialized, since the
>>>>>> hypercall page is not reinitialized on resume, the hypervisor
>>>>>> wallclock time is not properly set on resume.
>>>>>>
>>>>>> Fix it by forcing an update of the wallclock values when the shared
>>>>>> info page is mapped.
>>>>>
>>>>> NACK - this is a guest side bug. After migration, a guest _has_ to
>>>>> re-init the hypercall page, as it may have got migrated between
>>>>> a VMX and an SVM machine, and the hypercall instructions are
>>>>> different between them.
>>>>
>>>> Does migrating from VMX to SVM actually work?
>>>
>>> If you sufficiently feature-restrict both hosts, it should work. At
>>> least it was made work years ago iirc (see the sysenter/syscall
>>> emulation code in the x86 emulator - the only case where this
>>> may be needed is when doing cross vendor migration).
>>
>> Doesn't the presence of that emulation contradict the requirement to
>> reinit the hypercall page?
> 
> Definitely not - the emulation deals with system call instructions,
> while the hypercall page holds hypercall instructions (which have
> no emulation anywhere iirc).

Back at that time, yes migration from VMX to SVM and vice versa gotta
work. However, there are always things to consider:

1) Hypervisor side: When the guest OS uses MSRs that do not exist
on the destination machine must be emulated.
2) feature-set: Make sure both OS and application do not use
instructions (i.e. 3DNow, AVX, etc.) that isn't available on
destination side. You can archieve that by either setting cpuid
properly or emulate the missing instructions in the hypervisor.
The latter one will decrease performance.

>> My recollection is that although it could be made to work the
>> performance would suffer horribly precisely due to this emulation.
> 
> Performance isn't going to be good, sure. It's more for some kind
> of emergency I think. Wasn't it Christoph Egger who implemented
> this? Maybe he recalls more details than I do...

sysenter/syscall emulation comes into play with 32bit applications
in a 64bit guest OS. Yes, performance decreases but how much impact
this actually has on the end-user side depends on
a) the syscall itself (i.e. glibc caches the getpid syscall so the
performance penality shouldn't even be measureable while other syscalls
like read/write may suffer)
b) how often the syscall is actually in use

Christoph


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel