On 27.03.2012 13:43, Vadim Rozenfeld wrote:
On Tuesday, March 27, 2012 12:49:58 PM Peter Lieven wrote:
On 27.03.2012 12:40, Vadim Rozenfeld wrote:
On Tuesday, March 27, 2012 11:26:29 AM Peter Lieven wrote:
On 27.03.2012 11:23, Vadim Rozenfeld wrote:
On Tuesday, March 27, 2012 10:56:05 AM Gleb Natapov wrote:
On Mon, Mar 26, 2012 at 10:11:43PM +0200, Vadim Rozenfeld wrote:
On Monday, March 26, 2012 08:54:50 PM Peter Lieven wrote:
On 26.03.2012 20:36, Vadim Rozenfeld wrote:
On Monday, March 26, 2012 07:52:49 PM Gleb Natapov wrote:
On Mon, Mar 26, 2012 at 07:46:03PM +0200, Vadim Rozenfeld wrote:
On Monday, March 26, 2012 07:00:32 PM Peter Lieven wrote:
On 22.03.2012 10:38, Vadim Rozenfeld wrote:
On Thursday, March 22, 2012 10:52:42 AM Peter Lieven wrote:
On 22.03.2012 09:48, Vadim Rozenfeld wrote:
On Thursday, March 22, 2012 09:53:45 AM Gleb Natapov wrote:
On Wed, Mar 21, 2012 at 06:31:02PM +0100, Peter Lieven wrote:
On 21.03.2012 12:10, David Cure wrote:
hello,
Le Tue, Mar 20, 2012 at 02:38:22PM +0200, Gleb Natapov
ecrivait :
Try to add<feature policy='disable' name='hypervisor'/>
to cpu definition in XML and check command line.
ok I try this but I can't use<cpu model> to map
the
host cpu
(my libvirt is 0.9.8) so I use :
<cpu match='exact'>
<model>Opteron_G3</model>
<feature policy='disable' name='hypervisor'/>
</cpu>
(the physical server use Opteron CPU).
The log is here :
http://www.roullier.net/Report/report-3.2-vhost-net-1vcpu-
cp u.tx t.gz
And now with only 1 vcpu, the response time is 8.5s,
great
improvment. We keep this configuration for production : we
check the response time when some other users are
connected.
please keep in mind, that setting -hypervisor, disabling
hpet and only one vcpu
makes windows use tsc as clocksource. you have to make
sure, that your vm is not switching between physical
sockets on your system and that you have constant_tsc
feature to have a stable tsc between the cores in the same
socket. its also likely that the vm will crash when live
migrated.
All true. I asked to try -hypervisor only to verify where we
loose performance. Since you get good result with it
frequent access to PM timer is probably the reason. I do
not recommend using -hypervisor for production!
@gleb: do you know whats the state of in-kernel hyper-v
timers?
Vadim is working on it. I'll let him answer.
It would be nice to have synthetic timers supported. But, at
the moment, I'm only researching this feature.
So it will take months at least?
I would say weeks.
Is there a way, we could contribute and help you with this?
Hi Peter,
You are welcome to add an appropriate handler.
I think Vadim refers to this HV MSR
http://msdn.microsoft.com/en-us/library/windows/hardware/ff542633%
28 v=vs .85 %29.aspx
This one is pretty simple to support. Please see attachments for
more details. I was thinking about synthetic timers
http://msdn.microsoft.com/en-
us/library/windows/hardware/ff542758(v=vs.85).aspx
is this what microsoft qpc uses as clocksource in hyper-v?
Yes, it should be enough for Win7 / W2K8R2.
To clarify the thing that microsoft qpc uses is what is implemented by
the patch Vadim attached to his previous email. But I believe that
additional qemu patch is needed for Windows to actually use it.
You are right.
bits 1 and 9 must be set to on in leaf 0x40000003 and HPET
should be completely removed from ACPI.
could you advise how to do this and/or make a patch?
Gleb mentioned that it properly handled in upstream,
otherwise just comment the entire HPET section in
acpi-dsdt.dsl file.
i have upstream bios installed. so -no-hpet should disable hpet completely.
can you give a hint, what
"bits 1 and 9 must be set to on in leaf 0x40000003" means?
I mean the following code:
+ if (hyperv_ref_counter_enabled()) {
+ c->eax |= HV_X64_MSR_TIME_REF_COUNT_AVAILABLE;
+ c->eax |= 0x200;
+ }
Please see attached file for more information.
the stuff you send yesterday is for qemu, right? would
it be possible to use it in qemu-kvm also?
Yes, but don't forget about kvm patch as well.
ok, i will try my best. would you consider your patch a quick hack
or do you think it would be worth to be uploaded to the upstream
repository?
It was just a brief attempt from my side, mostly inspirited by our with Gleb
conversation, to see what it worth to turn this option on.
It is not fully tested. It will crash Win8 (as well as the rest of the
currently introduced hyper-v features).
i can confirm that windows 8 installer does not start and resets the
vm continously. it tries to access hv msr 0x40000021
http://msdn.microsoft.com/en-us/library/windows/hardware/ff542648%28v=vs.85%29.aspx
it is possible to tell the guest that the host is not iTSC (how they
call it) capable. i will try to hack
a patch for this.
peter
I wouldn't commit this code without comprehensive testing.
Vadim.
peter
peter
--
Gleb.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
