Re: [Question] Binaries of virtio-gpu-wddm-dod?

[Vadim Rozenfeld]

On Fri, 2021-04-09 at 09:27 -0400, Mike Ladouceur wrote:
> Hi, I'm wondering where I can find binaries of virtio-gpu-wddm-dod to
> test? I tried to build but I guess I'm running too new a version of
> Windows or VS/SDK/WDK? I've seen mention of prewhql ISO's with
> binaries but there's never any links? I understand it's in
> development phase. Thanks!

Hi Mike,

I'm going to update 
https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/
latest  with build 196 soon.

Best,
Vadim.

Re: [Qemu-devel] [PATCH] i386: Fix signedness of hyperv_spinlock_attempts

[Vadim Rozenfeld]

On Tue, 2019-06-18 at 10:35 +, Roman Kagan wrote:
> On Tue, Jun 18, 2019 at 11:24:57AM +1000, Vadim Rozenfeld wrote:
> > On Mon, 2019-06-17 at 14:49 -0300, Eduardo Habkost wrote:
> > > On Mon, Jun 17, 2019 at 05:32:13PM +, Roman Kagan wrote:
> > > > On Mon, Jun 17, 2019 at 11:23:01AM -0300, Eduardo Habkost
> > > > wrote:
> > > > > On Mon, Jun 17, 2019 at 01:48:59PM +, Roman Kagan wrote:
> > > > > > On Sat, Jun 15, 2019 at 05:05:05PM -0300, Eduardo Habkost
> > > > > > wrote:
> > > > > > > The current default value for hv-spinlocks is 0x
> > > > > > > (meaning
> > > > > > > "never retry").  However, the value is stored as a signed
> > > > > > > integer, making the getter of the hv-spinlocks QOM
> > > > > > > property
> > > > > > > return -1 instead of 0x.
> > > > > > > 
> > > > > > > Fix this by changing the type of
> > > > > > > X86CPU::hyperv_spinlock_attempts
> > > > > > > to uint32_t.  This has no visible effect to guest
> > > > > > > operating
> > > > > > > systems, affecting just the behavior of the QOM getter.
> > > > > > > 
> > > > > > > Signed-off-by: Eduardo Habkost 
> > > > > > > ---
> > > > > > >  target/i386/cpu.h | 2 +-
> > > > > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > > 
> > > > > > Reviewed-by: Roman Kagan 
> > > > > > 
> > > > > > That said, it's tempting to just nuke qdev_prop_spinlocks
> > > > > > and
> > > > > > make
> > > > > > hv-spinlocks a regular DEFINE_PROP_UINT32...
> > > > > 
> > > > > Agreed.  The only difference is that we would validate the
> > > > > property at realize time instead of object_property_set().
> > > > 
> > > > Right.  But currently it's validated to be no less than 0xfff
> > > > and
> > > > no
> > > > bigger than 0x.  The latter check would become
> > > > unnecessary,
> > > > and
> > > > I'm unable to find any reason to do the former (neither spec
> > > > references
> > > > nor the log messages of the commits that introduced it).
> > > 
> > > The 0xFFF lower limit was originally introduced by commit
> > > 28f52cc04d34 ("hyper-v: introduce Hyper-V support
> > > infrastructure").
> > > 
> > > Vadim, do you know where the 0xFFF limit comes from?
> > 
> > I simply took this value from Windows Server 2008 R2 that 
> > I used as a reference while working on Hyper-V support for KVM.
> > I also remember some paper (probably published by AMD ???)
> > mentioned
> > that 0x2fff seemed to have the best balance for PLE logic.
> 
> The question is whether the user should be disallowed to set it below
> 0xfff?
> I don't see this mandated by the spec, so I'd rather remove the lower
> limit and convert the property to a regular DEFINE_PROP_UINT32.
> 

Honestly, I don't have any strong opinions on this matter. Having some
lower boundary limit seemed quite logical to me. However, if a user
wants to experiment and see how the smaller number of spinlock acquire
attempts before calling HvNotifyLongSpinWait will affect the overall
system performance, then why not?

Vadim.

> Roman.

Re: [Qemu-devel] [PATCH] i386: Fix signedness of hyperv_spinlock_attempts

[Vadim Rozenfeld]

On Mon, 2019-06-17 at 14:49 -0300, Eduardo Habkost wrote:
> On Mon, Jun 17, 2019 at 05:32:13PM +, Roman Kagan wrote:
> > On Mon, Jun 17, 2019 at 11:23:01AM -0300, Eduardo Habkost wrote:
> > > On Mon, Jun 17, 2019 at 01:48:59PM +, Roman Kagan wrote:
> > > > On Sat, Jun 15, 2019 at 05:05:05PM -0300, Eduardo Habkost
> > > > wrote:
> > > > > The current default value for hv-spinlocks is 0x
> > > > > (meaning
> > > > > "never retry").  However, the value is stored as a signed
> > > > > integer, making the getter of the hv-spinlocks QOM property
> > > > > return -1 instead of 0x.
> > > > > 
> > > > > Fix this by changing the type of
> > > > > X86CPU::hyperv_spinlock_attempts
> > > > > to uint32_t.  This has no visible effect to guest operating
> > > > > systems, affecting just the behavior of the QOM getter.
> > > > > 
> > > > > Signed-off-by: Eduardo Habkost 
> > > > > ---
> > > > >  target/i386/cpu.h | 2 +-
> > > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > > 
> > > > Reviewed-by: Roman Kagan 
> > > > 
> > > > That said, it's tempting to just nuke qdev_prop_spinlocks and
> > > > make
> > > > hv-spinlocks a regular DEFINE_PROP_UINT32...
> > > 
> > > Agreed.  The only difference is that we would validate the
> > > property at realize time instead of object_property_set().
> > 
> > Right.  But currently it's validated to be no less than 0xfff and
> > no
> > bigger than 0x.  The latter check would become unnecessary,
> > and
> > I'm unable to find any reason to do the former (neither spec
> > references
> > nor the log messages of the commits that introduced it).
> 
> The 0xFFF lower limit was originally introduced by commit
> 28f52cc04d34 ("hyper-v: introduce Hyper-V support infrastructure").
> 
> Vadim, do you know where the 0xFFF limit comes from?

I simply took this value from Windows Server 2008 R2 that 
I used as a reference while working on Hyper-V support for KVM.
I also remember some paper (probably published by AMD ???) mentioned
that 0x2fff seemed to have the best balance for PLE logic.


Best,
Vadim.

Re: [Qemu-devel] [PATCH] virtio-pci: Don't force Subsystem Vendor ID = Vendor ID

[Vadim Rozenfeld]

On 03/11/17 19:23, Ladi Prosek wrote:

On Fri, Nov 3, 2017 at 8:20 AM, Gerd Hoffmann  wrote:

Signed-off-by: Ladi Prosek 

I wonder whether it's a problem that legacy devices ignore
the subsystem ID (that's part of spec).

I don't understand this comment. I don't see anything in the spec
related to ignoring the subsystem ID.

Well, the subsystem *device* id is defined to be the virtio device id,
so it is certainly not ignored.  The subsystem *vendor* id is not used
as far I know (or ignored in the sense that it doesn't change driver
behavior), allowing to set that makes sense to me.

Yes, thanks, I'm assuming that Michael meant the subsystem device ID.
The PCI spec seems to be using "subsystem ID" for the name of this
field. I understand that this ID must not change in legacy devices.

Interestingly, Windows appears to allow matching drivers only on the
full subsystem device ID + subsystem vendor ID 32-bit value, not on
only one of the two.

PCI\VEN_v(4)&DEV_d(4)&SUBSYS_s(4)n(4)&REV_r(2)

This might be a potential problem for a legacy driver that wants to
stay vendor-agnostic but I'm pretty sure there would be a reasonable
way of working around it. Actually, the device must use a designated
device ID (like 0x1000) in addition to the subsystem device ID so this
should be a non-issue altogether.


For legacy drivers running on modified qemu it can be a problem.
For new virtio-win build we can keep both compatible (VID/DID) together
with full (VID/DID/SID/SVID) specified in .inf file


Possibly not only for virtio devices, most pci devices have 1af4:1100
as subsystem id, other vendors might want set it too for consistency.

cheers,
   Gerd

Re: [Qemu-devel] [Help] Windows2012 as Guest 64+cores on KVM Halts

[Vadim Rozenfeld]

On 21/02/17 00:18, Gonglei (Arei) wrote:


On 20/02/2017 12:54, Gonglei (Arei) wrote:

On 20/02/2017 10:19, Gonglei (Arei) wrote:

Hi Paolo,



On 16/02/2017 02:31, Gonglei (Arei) wrote:

And the below patch works for me, I can support max 255 vcpus for

WS2012

with hyper-v enlightenments.

diff --git a/target/i386/kvm.c b/target/i386/kvm.c
index 27fd050..efe3cbc 100644
--- a/target/i386/kvm.c
+++ b/target/i386/kvm.c
@@ -772,7 +772,7 @@ int kvm_arch_init_vcpu(CPUState *cs)

  c = &cpuid_data.entries[cpuid_i++];
  c->function = HYPERV_CPUID_IMPLEMENT_LIMITS;
-c->eax = 0x40;
+c->eax = -1;
  c->ebx = 0x40;

  kvm_base = KVM_CPUID_SIGNATURE_NEXT;

This needs to depend on the machine type, but apart from that I think

I don't know why. Because the negative effects for this change don't exist
on current QEMU IIUC, and we don't have compatible problems for live

migration.

CPUID should never change with the same machine type and command line.


OK, then how do we add compat code for the CPUID change? It's not a visible

property.

You can add a new property, something like hv-cpuid-limits-eax.


Sounds good. Let me try.  :)

Thanks,
-Gonglei

Hi Gonglei,
Any update on this issue?

We've found that SVVP on WS2016  is passing successfully with the above 
change

and more than 64 vCPUs defined.

Vadim.

Re: [Qemu-devel] [Help] Windows2012 as Guest 64+cores on KVM Halts

[Vadim Rozenfeld]

On Thu, 2017-02-16 at 01:31 +, Gonglei (Arei) wrote:
> Hi,
> 
> > 
> > 
> > On Sat, 2017-02-11 at 10:39 -0500, Paolo Bonzini wrote:
> > > 
> > > > 
> > > > 
> > > > 
> > > > > 
> > > > > 
> > > > > On 10/02/2017 10:31, Gonglei (Arei) wrote:
> > > > > > 
> > > > > > 
> > > > > > But We tested the same cases on Xen platform and VMware,
> > > > > > and
> > > > > > the guest booted successfully.
> > > > > 
> > > > > Were these two also tested with enlightenments enabled?  TCG
> > > > > surely isn't.
> > > > 
> > > > About TCG, I just remove ' accel=kvm,' and 'hy_releaxed' from
> > > > the
> > > > below QEMU
> > > > Command line, I thought the hyper-V enabled then. Sorry about
> > > > that.
> > > > 
> > > > But for Xen, we set 'viridian=1' which be thought the Hyper-V
> > > > is
> > > > enabled.
> > > > 
> > > > For VMWare we also enabled the Hyper-V enlightenments.
> > If I'm not mistaken, even Hyper-V server doesn't allow specify more
> > than 64 vCPUs for Generation 1 VMs.
> 
> Normally yes, but I found the explanation from Microsoft document
> about it:
> 
> Maximum Supported Virtual Processors
> 
> On Windows operating systems versions through Windows Server 2008
> R2, 
> reporting the HV#1 hypervisor interface limits the Windows virtual
> machine 
> to a maximum of 64 VPs, regardless of what is reported via
> CPUID.4005.EAX.
> Starting with Windows Server 2012 and Windows 8, if
> CPUID.4005.EAX 
> contains a value of -1, Windows assumes that the hypervisor imposes
> no specific
> limit to the number of VPs. In this case, Windows Server 2012 guest
> VMs may
> use more than 64 VPs, up to the maximum supported number of
> processors 
> applicable to the specific Windows version being used.
> 
> Link: https://docs.microsoft.com/en-us/virtualization/hyper-v-on-wind
> ows/reference/tlfs
> 
> "Requirements for Implementing the Microsoft Hypervisor Interface"
> 
> And the below patch works for me, I can support max 255 vcpus for
> WS2012
> with hyper-v enlightenments.
> 
> diff --git a/target/i386/kvm.c b/target/i386/kvm.c
> index 27fd050..efe3cbc 100644
> --- a/target/i386/kvm.c
> +++ b/target/i386/kvm.c
> @@ -772,7 +772,7 @@ int kvm_arch_init_vcpu(CPUState *cs)
> 
>  c = &cpuid_data.entries[cpuid_i++];
>  c->function = HYPERV_CPUID_IMPLEMENT_LIMITS;
> -c->eax = 0x40;
> +c->eax = -1;
>  c->ebx = 0x40;
> 
>  kvm_base = KVM_CPUID_SIGNATURE_NEXT;
> 

Nice.
I tried the following patch some time ago. Unfortunately it didn't work
for me for some reason:

@@ -772,8 +773,9 @@ int kvm_arch_init_vcpu(CPUState *cs)
 
 c = &cpuid_data.entries[cpuid_i++];
 c->function = HYPERV_CPUID_IMPLEMENT_LIMITS;
-c->eax = 0x40;
-c->ebx = 0x40;
+c->eax = 0x00f0;//0x40;
+c->ebx = 0x0200;//0x40;
+c->ecx = 0x0648;

I used the same numbers as provided by WS2016 for both Gen1 and Gen2
VMs.

> > 
> > > > 
> > In any case, if you are only interested in hv_relaxed, you can drop
> > it
> > off for WS2012 as long as you have cpu hypervisor flag
> > (CPUID.1:ECX [bit 31]=1) turned on.
> > 
> hy_relaxed is just a example of enabling hyperv-v enlightenments.
> 
> Thanks,
> -Gonglei

Re: [Qemu-devel] [Help] Windows2012 as Guest 64+cores on KVM Halts

[Vadim Rozenfeld]

On Sat, 2017-02-11 at 10:39 -0500, Paolo Bonzini wrote:
> > 
> > 
> > > 
> > > On 10/02/2017 10:31, Gonglei (Arei) wrote:
> > > > 
> > > > But We tested the same cases on Xen platform and VMware, and
> > > > the guest booted successfully.
> > > 
> > > Were these two also tested with enlightenments enabled?  TCG
> > > surely isn't.
> > 
> > About TCG, I just remove ' accel=kvm,' and 'hy_releaxed' from the
> > below QEMU
> > Command line, I thought the hyper-V enabled then. Sorry about that.
> > 
> > But for Xen, we set 'viridian=1' which be thought the Hyper-V is
> > enabled.
> > 
> > For VMWare we also enabled the Hyper-V enlightenments.
If I'm not mistaken, even Hyper-V server doesn't allow specify more
than 64 vCPUs for Generation 1 VMs.
In any case, if you are only interested in hv_relaxed, you can drop it
off for WS2012 as long as you have cpu hypervisor flag
(CPUID.1:ECX [bit 31]=1) turned on.

Best regards,
Vadim.
 
> 
> Ok, thanks for the clarifications!
> 
> Paolo

Re: [Qemu-devel] VirtIO windows driver: viostor.sys not post-installable

[Vadim Rozenfeld]

On Mon, 2015-06-01 at 15:10 +0200, Philipp Hahn wrote:
> Hello,
> 
> On 31.05.2015 12:58, Vadim Rozenfeld wrote:
> > On Sun, 2015-05-31 at 11:26 +0300, Yan Vugenfirer wrote:
> >>> On May 29, 2015, at 5:43 PM, Philipp Hahn 
> >>> wrote:
> ...
> >>> we tried to migrate some Windows 2008 and 2012 VMs from Xen to KVM,
> >>> but
> >>> installing the VirtIO viostor.sys driver fails, because the
> >>> signature of
> >>> the driver doesn't seem to match what's stored in the
> >>> corresponding .cat
> >>> file.
> ...
> >> Can you send the error message you are getting from Windows? If
> >> possible attach setupapi.log as well (search your system
> >> for setupapi.*, the location might be different for different OS
> >> versions).
> 
> I attached them to <https://bugzilla.redhat.com/show_bug.cgi?id=1226928>
> 
> > Do you use the same installation media for v2v and a fresh install, or
> > vfd for a fresh install and iso for v2v conversion? 
> 
> If the drivers are installed during the initial setup, both ISO and VFD
> work - after navigating into the right sub directory and enabling "show
> not matching drivers". No BSOD.
> 
> Using the same ISO after doing the install using the emulated IDE, the
> drivers are rejected with:
> 
> > Processing inf :vioscsi.inf
> > Adding the driver package failed : The hash for the file is not present in 
> > the specified catalog file. The file is likely corrupt or the victim of 
> > tampering.
> > 
> > Processing inf :viostor.inf
> > Adding the driver package failed : The hash for the file is not present in 
> > the specified catalog file. The file is likely corrupt or the victim of 
> > tampering.
> 
> 
> >>> Are there some Linux tools to work with the .cat files and
> >>> signatures to make sure they match?
> 
> Answering my own question: .crt files are DER encoded. "dumpasn1" shows
> them to contain PKCS#7 data.
> 
> >> Vadim and I monitor qemu-devel, you can also open bug in
> >> bugzilla.redhat.com for virtio-win component or report an issue
> >> here: https://github.com/YanVugenfirer/kvm-guest-drivers-windows/issues
> 
> I filed <https://bugzilla.redhat.com/show_bug.cgi?id=1226928>. If
> anything is still missing, just ask.
> 

Thanks,
Vadim.

> Thanks for the fast help and for any more help in advance
> Philipp Hahn

Re: [Qemu-devel] VirtIO windows driver: viostor.sys not post-installable

[Vadim Rozenfeld]

On Sun, 2015-05-31 at 11:26 +0300, Yan Vugenfirer wrote:
> Adding Vadim to the thread.
> 
> > On May 29, 2015, at 5:43 PM, Philipp Hahn 
> > wrote:
> > 
> > Hello,
> > 
> > we tried to migrate some Windows 2008 and 2012 VMs from Xen to KVM,
> > but
> > installing the VirtIO viostor.sys driver fails, because the
> > signature of
> > the driver doesn't seem to match what's stored in the
> > corresponding .cat
> > file.
> > 
> > 
> 
> 
> Can you send the error message you are getting from Windows? If
> possible attach setupapi.log as well (search your system
> for setupapi.*, the location might be different for different OS
> versions).
> 
> > On the other hand installing the drivers during a fresh install from
> > the
> > beginning never had any problems.

Do you use the same installation media for v2v and a fresh install, or
vfd for a fresh install and iso for v2v conversion? 

Thanks,
Vadim.

> > 
> > 
> > We use
> > 
> > but also tried "virtio-win-0.1.103.iso" and "virtio-win-0.1-81.iso".
> > 
> > Running the following command on 0.1.104 prints (among others) the
> > following sha1hash:
> > > "C:\Program Files (x86)\Windows Kits\8.1\bin\x86
> > > \signtool.exe" /verify
> > /v /kp E:\NetKVM\2k12\amd64\netkvm.sys
> > ...
> > > Hash of file (sha1): 135E3AA23217610AEE8046F68550B0BA86F4EAE6
> > 
> > > "C:\Program Files (x86)\Windows Kits\8.1\bin\x86
> > > \signtool.exe" /verify
> > /v /kp E:\viostor\2k12\amd64\viostor.sys
> > ...
> > > Hash of file (sha1): EF11F5E539EEE0A9DB6DF3710A0DAA35066C5607
> > 
> > Looking into the corresponding .cat "Security Catalog File"
> > - netkvm.cat contains the above given hash for netkvm.sys,
> > - viostor.cat contains 55FC4DA2EE96ECC3FD4865680436DCDA6B8C6BDD
> > instead!
> > 
> > Running "sha1sum" on Linux print some completely different hashes,
> > so I
> > don't know what the Microsoft tool actually hash:
> > 
> > > #
> > > sha1sum /cdrom/NetKVM/2k12/amd64/netkvm.sys 
> > > /cdrom/viostor/2k12/amd64/viostor.sys 
> > > 1aa91c8e1d7680457d92c1875810a79f68af536d
> > >  /cdrom/NetKVM/2k12/amd64/netkvm.sys
> > > f39bc2b561091addfcac30e370227c91700d2698
> > >  /cdrom/viostor/2k12/amd64/viostor.sys
> > 
> > Is this a known issue?
> > 
> 
> 
> There was some mismatch  reported between Windows and sha1sum on
> Linux.
> 
> > 
> > Are there some (working) alternatives?
> > 
> > Are there some Linux tools to work with the .cat files and
> > signatures to
> > make sure they match?
> > 
> > Is there some better mailing list for VirtIO Windows driver issues?
> > 
> 
> 
> Vadim and I monitor qemu-devel, you can also open bug in
> bugzilla.redhat.com for virtio-win component or report an issue
> here: https://github.com/YanVugenfirer/kvm-guest-drivers-windows/issues
> 
> 
> > 
> > 
> > Some more background for our migration procedure:
> > 
> > - The VM was installed some years are on Xen.
> > - The GPLPV drivers were added afterwards.
> > - For the migration the GPLPV drivers were disabled and then
> > removed.
> > - A 2nd VirtIO hard-disk was added in KVM to trigger Windows to
> > request
> > the virstor driver.
> > 
> > If you need any more data, just ask.
> > 
> > Thanks in advance
> > Philipp Hahn
> > 
> > PS: data was copied by hand from Windows, so it might contains
> > copy-paste-errors.
> > -- 
> > Philipp Hahn
> > Open Source Software Engineer
> > 
> > Univention GmbH
> > be open.
> > Mary-Somerville-Str. 1
> > D-28359 Bremen
> > Tel.: +49 421 22232-0
> > Fax : +49 421 22232-99
> > h...@univention.de
> > 
> > http://www.univention.de/
> > Geschäftsführer: Peter H. Ganten
> > HRB 20755 Amtsgericht Bremen
> > Steuer-Nr.: 71-597-02876
> > 
> 
> 

Re: [Qemu-devel] Windows2012R2 virtio-win drivers and IPv6

[Vadim Rozenfeld]

On Thu, 2015-05-28 at 16:07 +0200, Peter Lieven wrote:
> Hi,
> 
> we observed problems with Windows Update Services and Uploading Files from a 
> Windows System to other systems.
> We tracked this down to IPv6 connections only. IPv4 and IPv6 in Receive 
> direction seems to be not a problem.
> It turned out that setting TCP/UDP Checksum Offloading for IPv6 from "RX/TX 
> enabled" to RX "enabled" in the
> Network Driver settings solved the issue. I remember similar problems existed 
> with Linux some time ago.
> Linux guests on the same host are also not an issue.
> 
> Is this a known issue? I tried latest and stable drivers from the Fedora 
> Website.
> 

Adding Yan.

Best regards,
Vadim.
 
> Thanks,
> Peter
> 

Re: [Qemu-devel] Fwd: [question] About MSI for vioscsi

[Vadim Rozenfeld]

On Thu, 2015-01-08 at 17:27 +0800, Wangting (Kathy) wrote:
> 
> On 2015-1-8 17:01, Vadim Rozenfeld wrote:
> > On Thu, 2015-01-08 at 16:40 +0800, Wangting (Kathy) wrote:
> >> Hi Vadim,
> >>
> >>In order to enable MSI for vioscsi in virtio-win-0.1-74, I try to merge
> >>
> >> the patch about Bug 1077566 into it, but I find that MSI still doesn't 
> >> work,
> >>
> >> because the value of IRQ is not negative in the device manager.
> >>
> >>I try to trace the I/O path with ENABLE_COM_DEBUG, and I find that
> >>
> >> pMsixCapOffset->MessageControl.MSIXEnable is zero when
> >>
> >> StorPortGetBusData returned in VioScsiFindAdapter, so MSI can't be enabled.
> >>
> >>I have tested that MSI is successfully enabled in virtio-win-0.1-81.
> >>
> >> But I still want to find out why the patch is not work in 
> >> virtio-win-0.1-74.
> >>
> >> Is there some important points I missed?
> > 
> > Did you enable MSISupported in inf file?
> > 
> > Cheers,
> > Vadim.
> > 
> Where is the inf file? Do you mean qemupciserial.inf?

vioscsi.inx in the source directory. After stamping,
it will be copied into vioscsi.inf, as part of build
process.


> >>
> >>Thank you very much.
> >>
> >>Best wishes,
> >>
> >>Ting Wang
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> > 
> > 
> > 
> > 
> 
> 

Re: [Qemu-devel] Fwd: [question] About MSI for vioscsi

[Vadim Rozenfeld]

On Thu, 2015-01-08 at 16:40 +0800, Wangting (Kathy) wrote:
> Hi Vadim,
> 
>In order to enable MSI for vioscsi in virtio-win-0.1-74, I try to merge
> 
> the patch about Bug 1077566 into it, but I find that MSI still doesn't work,
> 
> because the value of IRQ is not negative in the device manager.
> 
>I try to trace the I/O path with ENABLE_COM_DEBUG, and I find that
> 
> pMsixCapOffset->MessageControl.MSIXEnable is zero when
> 
> StorPortGetBusData returned in VioScsiFindAdapter, so MSI can't be enabled.
> 
>I have tested that MSI is successfully enabled in virtio-win-0.1-81.
> 
> But I still want to find out why the patch is not work in virtio-win-0.1-74.
> 
> Is there some important points I missed?

Did you enable MSISupported in inf file?

Cheers,
Vadim.

> 
>Thank you very much.
> 
>Best wishes,
> 
>Ting Wang
> 
> 
> 
> 
> 
> 
> 
> 

Re: [Qemu-devel] question about vioscsi queue depth patch

[Vadim Rozenfeld]

On Tue, 2014-12-09 at 16:20 +0800, Wangting (Kathy) wrote:
> Hi Vadim,
> 
> I test the vioscsi 0001-queue-depth254.patch for virtio-win-0.1-74 with 
> minor modifications about
> 
> virtio api, because it have not updated to use the linux api. When a VM with 
> four disks in one controller
> 
> and 4kb 32depth sequential read for each disk at the same time, the tool of 
> iometer which simulates
> 
> the IO model become no response. If fit the patch into virtio-win-0.1-94, it 
> works well.
> 
> Is there some bug with the old virtio api, or is there some reason that 
> the patch can not work normally
> 
> in virtio-win-0.1-74?
There were a lot of bug-fixes / changes introduced since build 74
(November 2013). Some of them did affect SRB completion and queue depth
logic.
So do you see any performance improvement after applying the patch?

Cheers,
Vadim.

> 
> 
> 
> Best wishes,
> 
> Ting Wang
> 
> 

Re: [Qemu-devel] MSI interrupt support with vioscsi.c miniport driver

[Vadim Rozenfeld]

On Thu, 2014-10-30 at 18:28 +0800, Wangting (Kathy) wrote:
> 
> On 2014-10-30 16:48, Vadim Rozenfeld wrote:
> > On Thu, 2014-10-30 at 14:54 +0800, Wangting (Kathy) wrote:
> >>> On Tue, 2014-02-18 at 13:11 -0800, Nicholas A. Bellinger wrote:
> >>>> On Tue, 2014-02-18 at 13:00 -0800, Nicholas A. Bellinger wrote:
> >>>>> On Mon, 2014-02-10 at 11:05 -0800, Nicholas A. Bellinger wrote:
> >>>>>
> >>>>> 
> >>>>>
> >>>>>>>>> Hi Yan,
> >>>>>>>>>
> >>>>>>>>> So recently I've been doing some KVM guest performance comparisons
> >>>>>>>>> between the scsi-mq prototype using virtio-scsi + vhost-scsi, and
> >>>>>>>>> Windows Server 2012 with vioscsi.sys (virtio-win-0.1-74.iso) +
> >>>>>>>>> vhost-scsi using PCIe flash backend devices.
> >>>>>>>>>
> >>>>>>>>> I've noticed that small block random performance for the MSFT guest 
> >>>>>>>>> is
> >>>>>>>>> at around ~80K IOPs with multiple vioscsi LUNs + adapters, which 
> >>>>>>>>> ends up
> >>>>>>>>> being well below what the Linux guest with scsi-mq + virtio-scsi is
> >>>>>>>>> capable of (~500K).
> >>>>>>>>>
> >>>>>>>>> After searching through the various vioscsi registry settings, it
> >>>>>>>>> appears that MSIEnabled is being explicitly disabled (0x), 
> >>>>>>>>> that
> >>>>>>>>> is different from what vioscsi.inx is currently defining:
> >>>>>>>>>
> >>>>>>>>> [pnpsafe_pci_addreg_msix]
> >>>>>>>>> HKR, "Interrupt Management",, 0x0010
> >>>>>>>>> HKR, "Interrupt Management\MessageSignaledInterruptProperties",, 
> >>>>>>>>> 0x0010
> >>>>>>>>> HKR, "Interrupt Management\MessageSignaledInterruptProperties", 
> >>>>>>>>> MSISupported, 0x00010001, 0
> >>>>>>>>> HKR, "Interrupt Management\MessageSignaledInterruptProperties", 
> >>>>>>>>> MessageNumberLimit, 0x00010001, 4
> >>>>>>>>>
> >>>>>>>>> Looking deeper at vioscsi.c code, I've noticed that MSI_SUPPORTED=0 
> >>>>>>>>> is
> >>>>>>>>> explicitly disabled at build time in SOURCES + vioscsi.vcxproj, as 
> >>>>>>>>> well
> >>>>>>>>> as VioScsiFindAdapter() code always ends setting msix_enabled = 
> >>>>>>>>> FALSE
> >>>>>>>>> here, regardless of MSI_SUPPORTED:
> >>>>>>>>>
> >>>>>>>>>  
> >>>>>>>>> https://github.com/YanVugenfirer/kvm-guest-drivers-windows/blob/master/vioscsi/vioscsi.c#L340
> >>>>>>>>>
> >>>>>>>>> Also looking at virtio_stor.c for the raw block driver, 
> >>>>>>>>> MSI_SUPPORTED=1
> >>>>>>>>> appears to be the default setting for the driver included in the 
> >>>>>>>>> offical
> >>>>>>>>> virtio-win iso builds, right..?
> >>>>>>>>>
> >>>>>>>>> Sooo, I'd like to try enabling MSI_SUPPORTED=1 in a test vioscsi.sys
> >>>>>>>>> build of my own, but before going down the WDK development rabbit 
> >>>>>>>>> whole,
> >>>>>>>>> I'd like to better understand why you've explicitly disabled this 
> >>>>>>>>> logic
> >>>>>>>>> within vioscsi.c code to start..?
> >>>>>>>>>
> >>>>>>>>> Is there anything that needs to be addressed / carried over from
> >>>>>>>>> virtio_stor.c in order to get MSI_SUPPORTED=1 to work with vioscsi.c
> >>>>>>>>> miniport code..?
> >>>>>>>
> >>>>>>> Hi Nicholas,
> >>>>>>>
> >>>>>>> I wa

Re: [Qemu-devel] MSI interrupt support with vioscsi.c miniport driver

[Vadim Rozenfeld]

On Thu, 2014-10-30 at 14:54 +0800, Wangting (Kathy) wrote:
> > On Tue, 2014-02-18 at 13:11 -0800, Nicholas A. Bellinger wrote:
> >> On Tue, 2014-02-18 at 13:00 -0800, Nicholas A. Bellinger wrote:
> >> > On Mon, 2014-02-10 at 11:05 -0800, Nicholas A. Bellinger wrote:
> >> > 
> >> > 
> >> > 
> >> > > > > > Hi Yan,
> >> > > > > > 
> >> > > > > > So recently I've been doing some KVM guest performance 
> >> > > > > > comparisons
> >> > > > > > between the scsi-mq prototype using virtio-scsi + vhost-scsi, and
> >> > > > > > Windows Server 2012 with vioscsi.sys (virtio-win-0.1-74.iso) +
> >> > > > > > vhost-scsi using PCIe flash backend devices.
> >> > > > > > 
> >> > > > > > I've noticed that small block random performance for the MSFT 
> >> > > > > > guest 
> >> > > > > > is
> >> > > > > > at around ~80K IOPs with multiple vioscsi LUNs + adapters, which 
> >> > > > > > ends up
> >> > > > > > being well below what the Linux guest with scsi-mq + virtio-scsi 
> >> > > > > > is
> >> > > > > > capable of (~500K).
> >> > > > > > 
> >> > > > > > After searching through the various vioscsi registry settings, it
> >> > > > > > appears that MSIEnabled is being explicitly disabled 
> >> > > > > > (0x), 
> >> > > > > > that
> >> > > > > > is different from what vioscsi.inx is currently defining:
> >> > > > > > 
> >> > > > > > [pnpsafe_pci_addreg_msix]
> >> > > > > > HKR, "Interrupt Management",, 0x0010
> >> > > > > > HKR, "Interrupt Management\MessageSignaledInterruptProperties",, 
> >> > > > > > 0x0010
> >> > > > > > HKR, "Interrupt Management\MessageSignaledInterruptProperties", 
> >> > > > > > MSISupported, 0x00010001, 0
> >> > > > > > HKR, "Interrupt Management\MessageSignaledInterruptProperties", 
> >> > > > > > MessageNumberLimit, 0x00010001, 4
> >> > > > > > 
> >> > > > > > Looking deeper at vioscsi.c code, I've noticed that 
> >> > > > > > MSI_SUPPORTED=0 
> >> > > > > > is
> >> > > > > > explicitly disabled at build time in SOURCES + vioscsi.vcxproj, 
> >> > > > > > as 
> >> > > > > > well
> >> > > > > > as VioScsiFindAdapter() code always ends setting msix_enabled = 
> >> > > > > > FALSE
> >> > > > > > here, regardless of MSI_SUPPORTED:
> >> > > > > > 
> >> > > > > >  
> >> > > > > > https://github.com/YanVugenfirer/kvm-guest-drivers-windows/blob/master/vioscsi/vioscsi.c#L340
> >> > > > > > 
> >> > > > > > Also looking at virtio_stor.c for the raw block driver, 
> >> > > > > > MSI_SUPPORTED=1
> >> > > > > > appears to be the default setting for the driver included in the 
> >> > > > > > offical
> >> > > > > > virtio-win iso builds, right..?
> >> > > > > > 
> >> > > > > > Sooo, I'd like to try enabling MSI_SUPPORTED=1 in a test 
> >> > > > > > vioscsi.sys
> >> > > > > > build of my own, but before going down the WDK development 
> >> > > > > > rabbit 
> >> > > > > > whole,
> >> > > > > > I'd like to better understand why you've explicitly disabled 
> >> > > > > > this 
> >> > > > > > logic
> >> > > > > > within vioscsi.c code to start..?
> >> > > > > > 
> >> > > > > > Is there anything that needs to be addressed / carried over from
> >> > > > > > virtio_stor.c in order to get MSI_SUPPORTED=1 to work with 
> >> > > > > > vioscsi.c
> >> > > > > > miniport code..?
> >> > > > 
> >> > > > Hi Nicholas,
> >> > > > 
> >> > > > I was thinking about enabling MSI in RHEL 6.6 (build 74) but for some
> >> > > > reasons decided to keep it disabled until adding mq support.
> >> > > > 
> >> > > > 
> >> > > > You definitely should be able to turn on MSI_SUPPORTED, rebuild the
> >> > > > driver, and switch MSISupported to 1 to make vioscsi driver working 
> >> > > > in
> >> > > > MSI mode.
> >> > > >
> >> > > 
> >> > > Thanks for the quick response.  We'll give MSI_SUPPORTED=1 a shot over
> >> > > the next days with a test build on Server 2012 / Server 2008 R2 and see
> >> > > how things go..
> >> > > 
> >> > 
> >> > Just a quick update on progress.
> >> > 
> >> > I've been able to successfully build + load a unsigned vioscsi.sys
> >> > driver on Server 2012 with WDK 8.0.
> >> > 
> >> > Running with MSI_SUPPORTED=1 against vhost-scsi results in a significant
> >> > performance and efficiency gain, on the order of 100K to 225K IOPs for
> >> > 4K block random I/O workload, depending on read/write mix.
> >> > 
> >> 
> >> One other performance related question..
> >> 
> >> In vioscsi.c:VioScsiFindAdapter() code, the default setting for
> >> adaptExt->queue_depth ends up getting set to 32 (pageNum / 4) when
> >> indirect mode is enabled in the following bits:
> >> 
> >> if(adaptExt->indirect) {
> >> adaptExt->queue_depth = max(2, (pageNum / 4));
> >> } else {
> >> adaptExt->queue_depth = pageNum / 
> >> ConfigInfo->NumberOfPhysicalBreaks 
> >> - 1;
> >> }
> >> 
> >> Looking at viostor/virtio_stor.c:VirtIoFindAdapter() code, the default
> >> setting for ->queue_depth appears to be 128 (pageNum):
> >> 
> >> #if (INDIRECT_SUPPORTED)
> >> if(!adaptExt->dump_mode) {
> >> adaptExt->i

Re: [Qemu-devel] [questions] about KVM asaMicrosoft-compatiblehypervisor

[Vadim Rozenfeld]

On Mon, 2014-08-04 at 14:29 +0800, Zhang Haoyu wrote:
> >Hi Zhang,
> >
> >No I haven't seen such problem
> >Which kernel version are you running?
> Host kernel: RHEL7-RC1(linux-3.10.0).
> 
> >Does it include the latest lazy eli changes?
> >
> lazy eli or lazy eoi?
EOI
> How to confirm whether lazy eli has been included?
> 
not in linux-3.10.0
> >Btw, hv_spinlocks=0xfff is a pretty huge value.
> >
> which value do you advise to use?
MS seems to be using 0x as a default.
best regards,
Vadim.
> 
> Thanks,
> Zhang Haoyu
> >Best regards,
> >Vadim.
> 
> 

Re: [Qemu-devel] [questions] about KVM as aMicrosoft-compatiblehypervisor

[Vadim Rozenfeld]

Hi Zhang,

No I haven't seen such problem
Which kernel version are you running?
Does it include the latest lazy eli changes?

Btw, hv_spinlocks=0xfff is a pretty huge value.

Best regards,
Vadim.



- Original Message -
From: "Zhang Haoyu" 
To: "Vadim Rozenfeld" 
Cc: "Jidong Xiao" , "qemu-devel" 
, "kvm" 
Sent: Monday, August 4, 2014 12:17:41 PM
Subject: Re: Re: [Qemu-devel] [questions] about KVM as 
aMicrosoft-compatiblehypervisor

Hi, Vadim

I start a vm(windows server 2008 64bit) with below qemu command, get stuck with 
black screen during boot stage, 
no error report by qemu and kvm hypervisor, but if I remove the item 
"hv_vapic", then start and run the VM successfully.

/var/run/qemu-server/5195516385344.pid -daemonize -name win2008_iotest -smp 
sockets=1,cores=1 -cpu core2duo,hv_spinlocks=0xfff,hv_relaxed,hv_vapic 
-nodefaults -vga cirrus -no-hpet -k en-us -boot menu=on,splash-time=8000 -m 
2048 -usb -drive if=none,id=drive-ide0,media=cdrom,aio=native,forecast=disable 
-device ide-cd,bus=ide.0,unit=0,drive=drive-ide0,id=ide0,bootindex=200 -drive 
file=/sf/data/3600605b006c126da1b0cde571ba48d0d_00e0ed2d202e/images/host-00e0ed2d202e/win2008_iotest.vm/vm-disk-1.qcow2,if=none,id=drive-virtio1,cache=writethrough,aio=native,forecast=disable
 -device virtio-blk-pci,drive=drive-virtio1,id=virtio1,bus=pci.0,addr=0xb 
-drive 
file=/sf/data/local/images/host-00e0ed2d202e/win2008_iotest.vm/vm-disk-1.qcow2,if=none,id=drive-virtio2,cache=writethrough,aio=native,forecast=disable
 -device 
virtio-blk-pci,drive=drive-virtio2,id=virtio2,bus=pci.0,addr=0xc,bootindex=101 
-netdev 
type=tap,id=net0,ifname=519551638534400,script=/sf/etc/kvm/vtp-bridge,vhost=on,vhostforc
 e=on -device 
virtio-net-pci,mac=FE:FC:FE:58:E0:81,netdev=net0,bus=pci.0,addr=0x12,id=net0,bootindex=300
 -rtc driftfix=slew,clock=rt,base=localtime -global 
kvm-pit.lost_tick_policy=discard -global PIIX4_PM.disable_s3=1 -global 
PIIX4_PM.disable_s4=1 -post win2008_iotest -enable-kvm -L /boot/pc-bios

Seen similar problem before?
Any ideas?

Thanks,
Zhang Haoyu

>> >> Hi, Vadim
>> >> I read the kvm-2012-forum paper < KVM as a Microsoft-compatible 
>> >> hypervisor>, 
>> >> Any update and other references, please?
>> >> 
>> >> Thanks,
>> >> Zhang Haoyu
>> >> 
>> >> 
>> >
>> >Unfortunately, not too much.
>> >From the the most recent, we have lazy eoi implemented by 
>> >MST and reference time counter.
>> >
>> How to get the source of windows pv-eoi?
>I'll be referencing to git://git.kernel.org/pub/scm/virt/kvm/kvm.git
>
>for lazy eoi please take a look at commit:
>b63cf42fd1d8c18fab71222321aaf356f63089c9
>
>> And what is "reference time counter", could you provide some references or 
>> code, please?
>Take a look at commit:
>e984097b553ed2d6551c805223e4057421370f00
>
>I also suggest reading Hypervisor Functional Specification 3.0a provided
>by Microsoft and available for downloading
>from  http://www.microsoft.com/en-au/download/details.aspx?id=39289
>
>Best regards,
>Vadim.

--
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

Re: [Qemu-devel] [questions] about KVM as a Microsoft-compatiblehypervisor

[Vadim Rozenfeld]

On Mon, 2014-06-30 at 19:45 +0800, Zhang Haoyu wrote:
> >> Hi, Vadim
> >> I read the kvm-2012-forum paper < KVM as a Microsoft-compatible 
> >> hypervisor>, 
> >> Any update and other references, please?
> >> 
> >> Thanks,
> >> Zhang Haoyu
> >> 
> >> 
> >
> >Unfortunately, not too much.
> >From the the most recent, we have lazy eoi implemented by 
> >MST and reference time counter.
> >
> How to get the source of windows pv-eoi?
I'll be referencing to git://git.kernel.org/pub/scm/virt/kvm/kvm.git

for lazy eoi please take a look at commit:
b63cf42fd1d8c18fab71222321aaf356f63089c9

> And what is "reference time counter", could you provide some references or 
> code, please?
Take a look at commit:
e984097b553ed2d6551c805223e4057421370f00

I also suggest reading Hypervisor Functional Specification 3.0a provided
by Microsoft and available for downloading
from  http://www.microsoft.com/en-au/download/details.aspx?id=39289

Best regards,
Vadim.

> 
> Thanks,
> Zhang Haoyu
> 
> >Best regards,
> >Vadim.
> 
> 

Re: [Qemu-devel] [questions] about KVM as a Microsoft-compatible hypervisor

[Vadim Rozenfeld]

On Mon, 2014-06-30 at 06:19 -0400, Jidong Xiao wrote:
> On Mon, Jun 30, 2014 at 6:02 AM, Vadim Rozenfeld  wrote:
> > On Mon, 2014-06-30 at 09:39 +0800, Zhang Haoyu wrote:
> >> Hi, Vadim
> >> I read the kvm-2012-forum paper < KVM as a Microsoft-compatible 
> >> hypervisor>,
> >> Any update and other references, please?
> >>
> >> Thanks,
> >> Zhang Haoyu
> >>
> >>
> >
> > Unfortunately, not too much.
> > From the the most recent, we have lazy eoi implemented by
> > MST and reference time counter.
> >
> > Best regards,
> > Vadim.
> >
> It looks like that Mircosoft has defined a large number of synthetic
> registers in their Hyper-v spec, so ultimately KVM should virtualize
> most of these registers, so as to support the Mircosoft Enlightment,
> right?
> 
> -Jidong

Yes, but you don't have to support all the Hyper-V features at once. 
Hypervisor declares supported feature by specifying appropriate flags
in Feature identification (0x4003) and Implementation
recommendations (0x4004)CPUID leaves.

Best regards,
Vadim.

> --
> 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

Re: [Qemu-devel] [questions] about KVM as a Microsoft-compatible hypervisor

[Vadim Rozenfeld]

On Mon, 2014-06-30 at 09:39 +0800, Zhang Haoyu wrote:
> Hi, Vadim
> I read the kvm-2012-forum paper < KVM as a Microsoft-compatible hypervisor>, 
> Any update and other references, please?
> 
> Thanks,
> Zhang Haoyu
> 
> 

Unfortunately, not too much.
>From the the most recent, we have lazy eoi implemented by 
MST and reference time counter.

Best regards,
Vadim.

Re: [Qemu-devel] MSI interrupt support with vioscsi.c miniport driver

[Vadim Rozenfeld]

On Wed, 2014-02-19 at 15:25 -0800, Nicholas A. Bellinger wrote:
> On Wed, 2014-02-19 at 19:03 +1100, Vadim Rozenfeld wrote:
> > On Tue, 2014-02-18 at 13:00 -0800, Nicholas A. Bellinger wrote:
> > > On Mon, 2014-02-10 at 11:05 -0800, Nicholas A. Bellinger wrote:
> > > 
> > > 
> > > 
> > > > > > > Hi Yan,
> > > > > > > 
> > > > > > > So recently I've been doing some KVM guest performance comparisons
> > > > > > > between the scsi-mq prototype using virtio-scsi + vhost-scsi, and
> > > > > > > Windows Server 2012 with vioscsi.sys (virtio-win-0.1-74.iso) +
> > > > > > > vhost-scsi using PCIe flash backend devices.
> > > > > > > 
> > > > > > > I've noticed that small block random performance for the MSFT 
> > > > > > > guest is
> > > > > > > at around ~80K IOPs with multiple vioscsi LUNs + adapters, which 
> > > > > > > ends up
> > > > > > > being well below what the Linux guest with scsi-mq + virtio-scsi 
> > > > > > > is
> > > > > > > capable of (~500K).
> > > > > > > 
> > > > > > > After searching through the various vioscsi registry settings, it
> > > > > > > appears that MSIEnabled is being explicitly disabled 
> > > > > > > (0x), that
> > > > > > > is different from what vioscsi.inx is currently defining:
> > > > > > > 
> > > > > > > [pnpsafe_pci_addreg_msix]
> > > > > > > HKR, "Interrupt Management",, 0x0010
> > > > > > > HKR, "Interrupt Management\MessageSignaledInterruptProperties",, 
> > > > > > > 0x0010
> > > > > > > HKR, "Interrupt Management\MessageSignaledInterruptProperties", 
> > > > > > > MSISupported, 0x00010001, 0
> > > > > > > HKR, "Interrupt Management\MessageSignaledInterruptProperties", 
> > > > > > > MessageNumberLimit, 0x00010001, 4
> > > > > > > 
> > > > > > > Looking deeper at vioscsi.c code, I've noticed that 
> > > > > > > MSI_SUPPORTED=0 is
> > > > > > > explicitly disabled at build time in SOURCES + vioscsi.vcxproj, 
> > > > > > > as well
> > > > > > > as VioScsiFindAdapter() code always ends setting msix_enabled = 
> > > > > > > FALSE
> > > > > > > here, regardless of MSI_SUPPORTED:
> > > > > > > 
> > > > > > >  
> > > > > > > https://github.com/YanVugenfirer/kvm-guest-drivers-windows/blob/master/vioscsi/vioscsi.c#L340
> > > > > > > 
> > > > > > > Also looking at virtio_stor.c for the raw block driver, 
> > > > > > > MSI_SUPPORTED=1
> > > > > > > appears to be the default setting for the driver included in the 
> > > > > > > offical
> > > > > > > virtio-win iso builds, right..?
> > > > > > > 
> > > > > > > Sooo, I'd like to try enabling MSI_SUPPORTED=1 in a test 
> > > > > > > vioscsi.sys
> > > > > > > build of my own, but before going down the WDK development rabbit 
> > > > > > > whole,
> > > > > > > I'd like to better understand why you've explicitly disabled this 
> > > > > > > logic
> > > > > > > within vioscsi.c code to start..?
> > > > > > > 
> > > > > > > Is there anything that needs to be addressed / carried over from
> > > > > > > virtio_stor.c in order to get MSI_SUPPORTED=1 to work with 
> > > > > > > vioscsi.c
> > > > > > > miniport code..?
> > > > > 
> > > > > Hi Nicholas,
> > > > > 
> > > > > I was thinking about enabling MSI in RHEL 6.6 (build 74) but for some
> > > > > reasons decided to keep it disabled until adding mq support.
> > > > > 
> > > > > 
> > > > > You definitely should be able to turn on MSI_SUPPORTED, rebuild the
> > > > > driver, and switch MSISupported to 1 to make vioscsi driver working in
> > > > > MSI mode.
> > > > >
> > > > 
> > > > Thanks for the quick response.  We'll give MSI_SUPPORTED=1 a shot over
> > > > the next days with a test build on Server 2012 / Server 2008 R2 and see
> > > > how things go..
> > > > 
> > > 
> > > Just a quick update on progress.
> > > 
> > > I've been able to successfully build + load a unsigned vioscsi.sys
> > > driver on Server 2012 with WDK 8.0.
> > > 
> > > Running with MSI_SUPPORTED=1 against vhost-scsi results in a significant
> > > performance and efficiency gain, on the order of 100K to 225K IOPs for
> > > 4K block random I/O workload, depending on read/write mix.
> > > 
> > > Below is a simple patch to enable MSI operation by default.  Any chance
> > > to apply this separate from future mq efforts..?
> > 
> > Yes, we differently can enable MSI and rebuild vioscsi.
> > But then we need to re-spin WHQL testing for this particular
> > driver. This process requires a lot of resources, and I doubt that
> > it will be initiated soon, unless we have some significant amount of
> > bug-fixes.
> > 
> 
> Any idea on a rough time frame to expect an official WHQL build with MSI
> enabled..?
In June for sure :)
> Or, would it be possible to generate some -BETA builds that are at least
> signed and don't require extra hoops to jump through for testing..?

It's doable. 
I hope we can make a new build next week.
Best regards,
Vadim.

> 
> Thanks again,
> 
> --nab
> 
> 

Re: [Qemu-devel] MSI interrupt support with vioscsi.c miniport driver

[Vadim Rozenfeld]

On Tue, 2014-02-18 at 13:00 -0800, Nicholas A. Bellinger wrote:
> On Mon, 2014-02-10 at 11:05 -0800, Nicholas A. Bellinger wrote:
> 
> 
> 
> > > > > Hi Yan,
> > > > > 
> > > > > So recently I've been doing some KVM guest performance comparisons
> > > > > between the scsi-mq prototype using virtio-scsi + vhost-scsi, and
> > > > > Windows Server 2012 with vioscsi.sys (virtio-win-0.1-74.iso) +
> > > > > vhost-scsi using PCIe flash backend devices.
> > > > > 
> > > > > I've noticed that small block random performance for the MSFT guest is
> > > > > at around ~80K IOPs with multiple vioscsi LUNs + adapters, which ends 
> > > > > up
> > > > > being well below what the Linux guest with scsi-mq + virtio-scsi is
> > > > > capable of (~500K).
> > > > > 
> > > > > After searching through the various vioscsi registry settings, it
> > > > > appears that MSIEnabled is being explicitly disabled (0x), 
> > > > > that
> > > > > is different from what vioscsi.inx is currently defining:
> > > > > 
> > > > > [pnpsafe_pci_addreg_msix]
> > > > > HKR, "Interrupt Management",, 0x0010
> > > > > HKR, "Interrupt Management\MessageSignaledInterruptProperties",, 
> > > > > 0x0010
> > > > > HKR, "Interrupt Management\MessageSignaledInterruptProperties", 
> > > > > MSISupported, 0x00010001, 0
> > > > > HKR, "Interrupt Management\MessageSignaledInterruptProperties", 
> > > > > MessageNumberLimit, 0x00010001, 4
> > > > > 
> > > > > Looking deeper at vioscsi.c code, I've noticed that MSI_SUPPORTED=0 is
> > > > > explicitly disabled at build time in SOURCES + vioscsi.vcxproj, as 
> > > > > well
> > > > > as VioScsiFindAdapter() code always ends setting msix_enabled = FALSE
> > > > > here, regardless of MSI_SUPPORTED:
> > > > > 
> > > > >  
> > > > > https://github.com/YanVugenfirer/kvm-guest-drivers-windows/blob/master/vioscsi/vioscsi.c#L340
> > > > > 
> > > > > Also looking at virtio_stor.c for the raw block driver, 
> > > > > MSI_SUPPORTED=1
> > > > > appears to be the default setting for the driver included in the 
> > > > > offical
> > > > > virtio-win iso builds, right..?
> > > > > 
> > > > > Sooo, I'd like to try enabling MSI_SUPPORTED=1 in a test vioscsi.sys
> > > > > build of my own, but before going down the WDK development rabbit 
> > > > > whole,
> > > > > I'd like to better understand why you've explicitly disabled this 
> > > > > logic
> > > > > within vioscsi.c code to start..?
> > > > > 
> > > > > Is there anything that needs to be addressed / carried over from
> > > > > virtio_stor.c in order to get MSI_SUPPORTED=1 to work with vioscsi.c
> > > > > miniport code..?
> > > 
> > > Hi Nicholas,
> > > 
> > > I was thinking about enabling MSI in RHEL 6.6 (build 74) but for some
> > > reasons decided to keep it disabled until adding mq support.
> > > 
> > > 
> > > You definitely should be able to turn on MSI_SUPPORTED, rebuild the
> > > driver, and switch MSISupported to 1 to make vioscsi driver working in
> > > MSI mode.
> > >
> > 
> > Thanks for the quick response.  We'll give MSI_SUPPORTED=1 a shot over
> > the next days with a test build on Server 2012 / Server 2008 R2 and see
> > how things go..
> > 
> 
> Just a quick update on progress.
> 
> I've been able to successfully build + load a unsigned vioscsi.sys
> driver on Server 2012 with WDK 8.0.
> 
> Running with MSI_SUPPORTED=1 against vhost-scsi results in a significant
> performance and efficiency gain, on the order of 100K to 225K IOPs for
> 4K block random I/O workload, depending on read/write mix.
> 
> Below is a simple patch to enable MSI operation by default.  Any chance
> to apply this separate from future mq efforts..?

Yes, we differently can enable MSI and rebuild vioscsi.
But then we need to re-spin WHQL testing for this particular
driver. This process requires a lot of resources, and I doubt that
it will be initiated soon, unless we have some significant amount of
bug-fixes.

Best regards,
Vadim. 

> 
> Thanks,
> 
> --nab
> 
> From 89adb6d5800386d44b36737d1587e0ffc09c4902 Mon Sep 17 00:00:00 2001
> From: Nicholas Bellinger 
> Date: Fri, 14 Feb 2014 10:26:04 -0800
> Subject: [PATCH] vioscsi: Set MSI_SUPPORTED=1 by default
> 
> Signed-off-by: Nicholas Bellinger 
> ---
>  vioscsi/SOURCES | 2 +-
>  vioscsi/vioscsi.c   | 2 --
>  vioscsi/vioscsi.inx | 2 +-
>  vioscsi/vioscsi.vcxproj | 6 +++---
>  4 files changed, 5 insertions(+), 7 deletions(-)
> 
> diff --git a/vioscsi/SOURCES b/vioscsi/SOURCES
> index f2083de..f631bd2 100644
> --- a/vioscsi/SOURCES
> +++ b/vioscsi/SOURCES
> @@ -6,7 +6,7 @@ C_DEFINES = -D_MINORVERSION_=$(_BUILD_MINOR_VERSION_) 
> $(C_DEFINES)
>  C_DEFINES = -D_NT_TARGET_MAJ=$(_NT_TARGET_MAJ) $(C_DEFINES)
>  C_DEFINES = -D_NT_TARGET_MIN=$(_RHEL_RELEASE_VERSION_) $(C_DEFINES)
>  
> -C_DEFINES = -DMSI_SUPPORTED=0 $(C_DEFINES)
> +C_DEFINES = -DMSI_SUPPORTED=1 $(C_DEFINES)
>  C_DEFINES = -DINDIRECT_SUPPORTED=1 $(C_DEFINES)
>  TARGETLIBS=$(SDK_LIB_PATH)\storport.lib ..\VirtIO\$(O)\virtiolib.lib
>  
> diff --git a/viosc

Re: [Qemu-devel] MSI interrupt support with vioscsi.c miniport driver

[Vadim Rozenfeld]

On Tue, 2014-02-18 at 13:11 -0800, Nicholas A. Bellinger wrote:
> On Tue, 2014-02-18 at 13:00 -0800, Nicholas A. Bellinger wrote:
> > On Mon, 2014-02-10 at 11:05 -0800, Nicholas A. Bellinger wrote:
> > 
> > 
> > 
> > > > > > Hi Yan,
> > > > > > 
> > > > > > So recently I've been doing some KVM guest performance comparisons
> > > > > > between the scsi-mq prototype using virtio-scsi + vhost-scsi, and
> > > > > > Windows Server 2012 with vioscsi.sys (virtio-win-0.1-74.iso) +
> > > > > > vhost-scsi using PCIe flash backend devices.
> > > > > > 
> > > > > > I've noticed that small block random performance for the MSFT guest 
> > > > > > is
> > > > > > at around ~80K IOPs with multiple vioscsi LUNs + adapters, which 
> > > > > > ends up
> > > > > > being well below what the Linux guest with scsi-mq + virtio-scsi is
> > > > > > capable of (~500K).
> > > > > > 
> > > > > > After searching through the various vioscsi registry settings, it
> > > > > > appears that MSIEnabled is being explicitly disabled (0x), 
> > > > > > that
> > > > > > is different from what vioscsi.inx is currently defining:
> > > > > > 
> > > > > > [pnpsafe_pci_addreg_msix]
> > > > > > HKR, "Interrupt Management",, 0x0010
> > > > > > HKR, "Interrupt Management\MessageSignaledInterruptProperties",, 
> > > > > > 0x0010
> > > > > > HKR, "Interrupt Management\MessageSignaledInterruptProperties", 
> > > > > > MSISupported, 0x00010001, 0
> > > > > > HKR, "Interrupt Management\MessageSignaledInterruptProperties", 
> > > > > > MessageNumberLimit, 0x00010001, 4
> > > > > > 
> > > > > > Looking deeper at vioscsi.c code, I've noticed that MSI_SUPPORTED=0 
> > > > > > is
> > > > > > explicitly disabled at build time in SOURCES + vioscsi.vcxproj, as 
> > > > > > well
> > > > > > as VioScsiFindAdapter() code always ends setting msix_enabled = 
> > > > > > FALSE
> > > > > > here, regardless of MSI_SUPPORTED:
> > > > > > 
> > > > > >  
> > > > > > https://github.com/YanVugenfirer/kvm-guest-drivers-windows/blob/master/vioscsi/vioscsi.c#L340
> > > > > > 
> > > > > > Also looking at virtio_stor.c for the raw block driver, 
> > > > > > MSI_SUPPORTED=1
> > > > > > appears to be the default setting for the driver included in the 
> > > > > > offical
> > > > > > virtio-win iso builds, right..?
> > > > > > 
> > > > > > Sooo, I'd like to try enabling MSI_SUPPORTED=1 in a test vioscsi.sys
> > > > > > build of my own, but before going down the WDK development rabbit 
> > > > > > whole,
> > > > > > I'd like to better understand why you've explicitly disabled this 
> > > > > > logic
> > > > > > within vioscsi.c code to start..?
> > > > > > 
> > > > > > Is there anything that needs to be addressed / carried over from
> > > > > > virtio_stor.c in order to get MSI_SUPPORTED=1 to work with vioscsi.c
> > > > > > miniport code..?
> > > > 
> > > > Hi Nicholas,
> > > > 
> > > > I was thinking about enabling MSI in RHEL 6.6 (build 74) but for some
> > > > reasons decided to keep it disabled until adding mq support.
> > > > 
> > > > 
> > > > You definitely should be able to turn on MSI_SUPPORTED, rebuild the
> > > > driver, and switch MSISupported to 1 to make vioscsi driver working in
> > > > MSI mode.
> > > >
> > > 
> > > Thanks for the quick response.  We'll give MSI_SUPPORTED=1 a shot over
> > > the next days with a test build on Server 2012 / Server 2008 R2 and see
> > > how things go..
> > > 
> > 
> > Just a quick update on progress.
> > 
> > I've been able to successfully build + load a unsigned vioscsi.sys
> > driver on Server 2012 with WDK 8.0.
> > 
> > Running with MSI_SUPPORTED=1 against vhost-scsi results in a significant
> > performance and efficiency gain, on the order of 100K to 225K IOPs for
> > 4K block random I/O workload, depending on read/write mix.
> > 
> 
> One other performance related question..
> 
> In vioscsi.c:VioScsiFindAdapter() code, the default setting for
> adaptExt->queue_depth ends up getting set to 32 (pageNum / 4) when
> indirect mode is enabled in the following bits:
> 
> if(adaptExt->indirect) {
> adaptExt->queue_depth = max(2, (pageNum / 4));
> } else {
> adaptExt->queue_depth = pageNum / ConfigInfo->NumberOfPhysicalBreaks 
> - 1;
> }
> 
> Looking at viostor/virtio_stor.c:VirtIoFindAdapter() code, the default
> setting for ->queue_depth appears to be 128 (pageNum):
> 
> #if (INDIRECT_SUPPORTED)
> if(!adaptExt->dump_mode) {
> adaptExt->indirect = CHECKBIT(adaptExt->features, 
> VIRTIO_RING_F_INDIRECT_DESC);
> }
> if(adaptExt->indirect) {
> adaptExt->queue_depth = pageNum;
> }
> #else
> adaptExt->indirect = 0;
> #endif
> 
> Is there a reason for the lower queue_depth for vioscsi vs. viostor..?

It's a horrible work around for the following bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1013443

I'm going to remove it as soon as found better solution for it.

Best regards,
Vadim.


> 
> How about using min(adaptExt->scsi_config.cmd_per_lun, pageNum) instead..?
>

Re: [Qemu-devel] MSI interrupt support with vioscsi.c miniport driver

[Vadim Rozenfeld]

On Sun, 2014-02-09 at 11:24 +0200, Yan Vugenfirer wrote:
> Hi Nicholas,
> 
> Adding Vadim Rozenfeld who wrote the virtio-scsi driver.
> 
> Best regards,
> Yan.
> 
> On Feb 7, 2014, at 10:14 PM, Nicholas A. Bellinger  
> wrote:
> 
> > Hi Yan,
> > 
> > So recently I've been doing some KVM guest performance comparisons
> > between the scsi-mq prototype using virtio-scsi + vhost-scsi, and
> > Windows Server 2012 with vioscsi.sys (virtio-win-0.1-74.iso) +
> > vhost-scsi using PCIe flash backend devices.
> > 
> > I've noticed that small block random performance for the MSFT guest is
> > at around ~80K IOPs with multiple vioscsi LUNs + adapters, which ends up
> > being well below what the Linux guest with scsi-mq + virtio-scsi is
> > capable of (~500K).
> > 
> > After searching through the various vioscsi registry settings, it
> > appears that MSIEnabled is being explicitly disabled (0x), that
> > is different from what vioscsi.inx is currently defining:
> > 
> > [pnpsafe_pci_addreg_msix]
> > HKR, "Interrupt Management",, 0x0010
> > HKR, "Interrupt Management\MessageSignaledInterruptProperties",, 0x0010
> > HKR, "Interrupt Management\MessageSignaledInterruptProperties", 
> > MSISupported, 0x00010001, 0
> > HKR, "Interrupt Management\MessageSignaledInterruptProperties", 
> > MessageNumberLimit, 0x00010001, 4
> > 
> > Looking deeper at vioscsi.c code, I've noticed that MSI_SUPPORTED=0 is
> > explicitly disabled at build time in SOURCES + vioscsi.vcxproj, as well
> > as VioScsiFindAdapter() code always ends setting msix_enabled = FALSE
> > here, regardless of MSI_SUPPORTED:
> > 
> >  
> > https://github.com/YanVugenfirer/kvm-guest-drivers-windows/blob/master/vioscsi/vioscsi.c#L340
> > 
> > Also looking at virtio_stor.c for the raw block driver, MSI_SUPPORTED=1
> > appears to be the default setting for the driver included in the offical
> > virtio-win iso builds, right..?
> > 
> > Sooo, I'd like to try enabling MSI_SUPPORTED=1 in a test vioscsi.sys
> > build of my own, but before going down the WDK development rabbit whole,
> > I'd like to better understand why you've explicitly disabled this logic
> > within vioscsi.c code to start..?
> > 
> > Is there anything that needs to be addressed / carried over from
> > virtio_stor.c in order to get MSI_SUPPORTED=1 to work with vioscsi.c
> > miniport code..?

Hi Nicholas,

I was thinking about enabling MSI in RHEL 6.6 (build 74) but for some
reasons decided to keep it disabled until adding mq support.


You definitely should be able to turn on MSI_SUPPORTED, rebuild the
driver, and switch MSISupported to 1 to make vioscsi driver working in
MSI mode.
   
Cheers,
Vadim.

> > 
> > TIA!
> > 
> > --nab
> > 
> > 
> 

[Qemu-devel] [PATCH v2 6/7] make hyperv vapic assist page migratable

[Vadim Rozenfeld]

Signed-off-by: Vadim Rozenfeld 
---
 target-i386/cpu.h |  1 +
 target-i386/kvm.c | 16 +---
 target-i386/machine.c | 22 ++
 3 files changed, 36 insertions(+), 3 deletions(-)

diff --git a/target-i386/cpu.h b/target-i386/cpu.h
index 3bfaf87..d75a793 100644
--- a/target-i386/cpu.h
+++ b/target-i386/cpu.h
@@ -848,6 +848,7 @@ typedef struct CPUX86State {
 uint64_t msr_gp_evtsel[MAX_GP_COUNTERS];
 uint64_t msr_hv_hypercall;
 uint64_t msr_hv_guest_os_id;
+uint64_t msr_hv_vapic;
 
 /* exception/interrupt handling */
 int error_code;
diff --git a/target-i386/kvm.c b/target-i386/kvm.c
index 48a747e..6563dcb 100644
--- a/target-i386/kvm.c
+++ b/target-i386/kvm.c
@@ -72,6 +72,7 @@ static bool has_msr_misc_enable;
 static bool has_msr_kvm_steal_time;
 static int lm_capable_kernel;
 static bool has_msr_hv_hypercall;
+static bool has_msr_hv_vapic;
 
 static bool has_msr_architectural_pmu;
 static uint32_t num_architectural_pmu_counters;
@@ -490,6 +491,7 @@ int kvm_arch_init_vcpu(CPUState *cs)
 if (cpu->hyperv_vapic) {
 c->eax |= HV_X64_MSR_HYPERCALL_AVAILABLE;
 c->eax |= HV_X64_MSR_APIC_ACCESS_AVAILABLE;
+has_msr_hv_vapic = true;
 }
 
 c = &cpuid_data.entries[cpuid_i++];
@@ -497,7 +499,7 @@ int kvm_arch_init_vcpu(CPUState *cs)
 if (cpu->hyperv_relaxed_timing) {
 c->eax |= HV_X64_RELAXED_TIMING_RECOMMENDED;
 }
-if (cpu->hyperv_vapic) {
+if (has_msr_hv_vapic) {
 c->eax |= HV_X64_APIC_ACCESS_RECOMMENDED;
 }
 c->ebx = cpu->hyperv_spinlock_attempts;
@@ -1185,8 +1187,9 @@ static int kvm_put_msrs(X86CPU *cpu, int level)
 kvm_msr_entry_set(&msrs[n++], HV_X64_MSR_HYPERCALL,
   env->msr_hv_hypercall);
 }
-if (cpu->hyperv_vapic) {
-kvm_msr_entry_set(&msrs[n++], HV_X64_MSR_APIC_ASSIST_PAGE, 0);
+if (has_msr_hv_vapic) {
+kvm_msr_entry_set(&msrs[n++], HV_X64_MSR_APIC_ASSIST_PAGE,
+  env->msr_hv_vapic);
 }
 if (has_msr_feature_control) {
 kvm_msr_entry_set(&msrs[n++], MSR_IA32_FEATURE_CONTROL,
@@ -1470,6 +1473,10 @@ static int kvm_get_msrs(X86CPU *cpu)
 msrs[n++].index = HV_X64_MSR_HYPERCALL;
 msrs[n++].index = HV_X64_MSR_GUEST_OS_ID;
 }
+if (has_msr_hv_vapic) {
+msrs[n++].index = HV_X64_MSR_APIC_ASSIST_PAGE;
+}
+
 msr_data.info.nmsrs = n;
 ret = kvm_vcpu_ioctl(CPU(cpu), KVM_GET_MSRS, &msr_data);
 if (ret < 0) {
@@ -1580,6 +1587,9 @@ static int kvm_get_msrs(X86CPU *cpu)
 case HV_X64_MSR_GUEST_OS_ID:
 env->msr_hv_guest_os_id = msrs[i].data;
 break;
+case HV_X64_MSR_APIC_ASSIST_PAGE:
+env->msr_hv_vapic = msrs[i].data;
+break;
 }
 }
 
diff --git a/target-i386/machine.c b/target-i386/machine.c
index 3809d06..8fc81bc 100644
--- a/target-i386/machine.c
+++ b/target-i386/machine.c
@@ -526,6 +526,25 @@ static const VMStateDescription 
vmstate_msr_hypercall_hypercall = {
 }
 };
 
+static bool hyperv_vapic_enable_needed(void *opaque)
+{
+X86CPU *cpu = opaque;
+CPUX86State *env = &cpu->env;
+
+return env->msr_hv_vapic != 0;
+}
+
+static const VMStateDescription vmstate_msr_hyperv_vapic = {
+.name = "cpu/msr_hyperv_vapic",
+.version_id = 1,
+.minimum_version_id = 1,
+.minimum_version_id_old = 1,
+.fields  = (VMStateField []) {
+VMSTATE_UINT64(env.msr_hv_vapic, X86CPU),
+VMSTATE_END_OF_LIST()
+}
+};
+
 const VMStateDescription vmstate_x86_cpu = {
 .name = "cpu",
 .version_id = 12,
@@ -660,6 +679,9 @@ const VMStateDescription vmstate_x86_cpu = {
 }, {
 .vmsd = &vmstate_msr_hypercall_hypercall,
 .needed = hyperv_hypercall_enable_needed,
+}, {
+.vmsd = &vmstate_msr_hyperv_vapic,
+.needed = hyperv_vapic_enable_needed,
 } , {
 /* empty */
 }
-- 
1.8.1.4

[Qemu-devel] [PATCH v2 7/7] add support for hyper-v timers http://msdn.microsoft.com/en-us/library/windows/hardware/ff541625%28v=vs.85%29.aspx This code is generic for activating reference time counte

[Vadim Rozenfeld]

Signed-off-by: Vadim Rozenfeld 
---
 linux-headers/asm-x86/hyperv.h |  3 +++
 linux-headers/linux/kvm.h  |  1 +
 target-i386/cpu-qom.h  |  1 +
 target-i386/cpu.c  |  1 +
 target-i386/cpu.h  |  1 +
 target-i386/kvm.c  | 21 -
 target-i386/machine.c  | 21 +
 7 files changed, 48 insertions(+), 1 deletion(-)

diff --git a/linux-headers/asm-x86/hyperv.h b/linux-headers/asm-x86/hyperv.h
index b8f1c01..3b400ee 100644
--- a/linux-headers/asm-x86/hyperv.h
+++ b/linux-headers/asm-x86/hyperv.h
@@ -149,6 +149,9 @@
 /* MSR used to read the per-partition time reference counter */
 #define HV_X64_MSR_TIME_REF_COUNT  0x4020
 
+/* A partition's reference time stamp counter (TSC) page */
+#define HV_X64_MSR_REFERENCE_TSC   0x4021
+
 /* MSR used to retrieve the TSC frequency */
 #define HV_X64_MSR_TSC_FREQUENCY   0x4022
 
diff --git a/linux-headers/linux/kvm.h b/linux-headers/linux/kvm.h
index 5a49671..999fb13 100644
--- a/linux-headers/linux/kvm.h
+++ b/linux-headers/linux/kvm.h
@@ -674,6 +674,7 @@ struct kvm_ppc_smmu_info {
 #define KVM_CAP_ARM_EL1_32BIT 93
 #define KVM_CAP_SPAPR_MULTITCE 94
 #define KVM_CAP_EXT_EMUL_CPUID 95
+#define KVM_CAP_HYPERV_TIME 96
 
 #ifdef KVM_CAP_IRQ_ROUTING
 
diff --git a/target-i386/cpu-qom.h b/target-i386/cpu-qom.h
index d1751a4..722f11a 100644
--- a/target-i386/cpu-qom.h
+++ b/target-i386/cpu-qom.h
@@ -69,6 +69,7 @@ typedef struct X86CPU {
 bool hyperv_vapic;
 bool hyperv_relaxed_timing;
 int hyperv_spinlock_attempts;
+bool hyperv_time;
 bool check_cpuid;
 bool enforce_cpuid;
 
diff --git a/target-i386/cpu.c b/target-i386/cpu.c
index 0eea8c7..ff3290c 100644
--- a/target-i386/cpu.c
+++ b/target-i386/cpu.c
@@ -2744,6 +2744,7 @@ static Property x86_cpu_properties[] = {
 { .name  = "hv-spinlocks", .info  = &qdev_prop_spinlocks },
 DEFINE_PROP_BOOL("hv-relaxed", X86CPU, hyperv_relaxed_timing, false),
 DEFINE_PROP_BOOL("hv-vapic", X86CPU, hyperv_vapic, false),
+DEFINE_PROP_BOOL("hv-time", X86CPU, hyperv_time, false),
 DEFINE_PROP_BOOL("check", X86CPU, check_cpuid, false),
 DEFINE_PROP_BOOL("enforce", X86CPU, enforce_cpuid, false),
 DEFINE_PROP_END_OF_LIST()
diff --git a/target-i386/cpu.h b/target-i386/cpu.h
index d75a793..73174a3 100644
--- a/target-i386/cpu.h
+++ b/target-i386/cpu.h
@@ -849,6 +849,7 @@ typedef struct CPUX86State {
 uint64_t msr_hv_hypercall;
 uint64_t msr_hv_guest_os_id;
 uint64_t msr_hv_vapic;
+uint64_t msr_hv_tsc;
 
 /* exception/interrupt handling */
 int error_code;
diff --git a/target-i386/kvm.c b/target-i386/kvm.c
index 6563dcb..135d369 100644
--- a/target-i386/kvm.c
+++ b/target-i386/kvm.c
@@ -73,6 +73,7 @@ static bool has_msr_kvm_steal_time;
 static int lm_capable_kernel;
 static bool has_msr_hv_hypercall;
 static bool has_msr_hv_vapic;
+static bool has_msr_hv_tsc;
 
 static bool has_msr_architectural_pmu;
 static uint32_t num_architectural_pmu_counters;
@@ -439,6 +440,7 @@ static bool hyperv_hypercall_available(X86CPU *cpu)
 static bool hyperv_enabled(X86CPU *cpu)
 {
 return hyperv_hypercall_available(cpu) ||
+   cpu->hyperv_time  ||
cpu->hyperv_relaxed_timing;
 }
 
@@ -493,7 +495,13 @@ int kvm_arch_init_vcpu(CPUState *cs)
 c->eax |= HV_X64_MSR_APIC_ACCESS_AVAILABLE;
 has_msr_hv_vapic = true;
 }
-
+if (cpu->hyperv_time &&
+kvm_check_extension(cs->kvm_state, KVM_CAP_HYPERV_TIME) > 0) {
+c->eax |= HV_X64_MSR_HYPERCALL_AVAILABLE;
+c->eax |= HV_X64_MSR_TIME_REF_COUNT_AVAILABLE;
+c->eax |= 0x200;
+has_msr_hv_tsc = true;
+}
 c = &cpuid_data.entries[cpuid_i++];
 c->function = HYPERV_CPUID_ENLIGHTMENT_INFO;
 if (cpu->hyperv_relaxed_timing) {
@@ -1191,6 +1199,11 @@ static int kvm_put_msrs(X86CPU *cpu, int level)
 kvm_msr_entry_set(&msrs[n++], HV_X64_MSR_APIC_ASSIST_PAGE,
   env->msr_hv_vapic);
 }
+if (has_msr_hv_tsc) {
+kvm_msr_entry_set(&msrs[n++], HV_X64_MSR_REFERENCE_TSC,
+  env->msr_hv_tsc);
+}
+
 if (has_msr_feature_control) {
 kvm_msr_entry_set(&msrs[n++], MSR_IA32_FEATURE_CONTROL,
   env->msr_ia32_feature_control);
@@ -1476,6 +1489,9 @@ static int kvm_get_msrs(X86CPU *cpu)
 if (has_msr_hv_vapic) {
 msrs[n++].index = HV_X64_MSR_APIC_ASSIST_PAGE;
 }
+if (has_msr_hv_tsc) {
+msrs[n++].index = HV_X64_MSR_REFERENCE_TSC;
+}
 
 msr_data.info.nmsrs = n;
 ret = kvm_vcpu_ioctl(CPU(cpu), KVM_GET_MSRS, &msr_data);
@@ -1590,6 +1606,9 @@ static int kvm_get_msrs(X86CPU *cpu)
 

[Qemu-devel] [PATCH v2 5/7] make hyperv hypercall and guest os id MSRs migratable.

[Vadim Rozenfeld]

Signed-off-by: Vadim Rozenfeld 
---
 target-i386/cpu.h |  2 ++
 target-i386/kvm.c | 25 -
 target-i386/machine.c | 23 +++
 3 files changed, 45 insertions(+), 5 deletions(-)

diff --git a/target-i386/cpu.h b/target-i386/cpu.h
index 1d94a9d..3bfaf87 100644
--- a/target-i386/cpu.h
+++ b/target-i386/cpu.h
@@ -846,6 +846,8 @@ typedef struct CPUX86State {
 uint64_t msr_fixed_counters[MAX_FIXED_COUNTERS];
 uint64_t msr_gp_counters[MAX_GP_COUNTERS];
 uint64_t msr_gp_evtsel[MAX_GP_COUNTERS];
+uint64_t msr_hv_hypercall;
+uint64_t msr_hv_guest_os_id;
 
 /* exception/interrupt handling */
 int error_code;
diff --git a/target-i386/kvm.c b/target-i386/kvm.c
index c1bc8c0..48a747e 100644
--- a/target-i386/kvm.c
+++ b/target-i386/kvm.c
@@ -71,6 +71,7 @@ static bool has_msr_pv_eoi_en;
 static bool has_msr_misc_enable;
 static bool has_msr_kvm_steal_time;
 static int lm_capable_kernel;
+static bool has_msr_hv_hypercall;
 
 static bool has_msr_architectural_pmu;
 static uint32_t num_architectural_pmu_counters;
@@ -464,8 +465,10 @@ int kvm_arch_init_vcpu(CPUState *cs)
 c = &cpuid_data.entries[cpuid_i++];
 c->function = KVM_CPUID_SIGNATURE;
 memcpy(signature, "KVMKVMKVM\0\0\0", 12);
-if (hyperv_enabled(cpu)) {
+if (hyperv_enabled(cpu) &&
+kvm_check_extension(cs->kvm_state, KVM_CAP_HYPERV) > 0) {
 c->eax = HYPERV_CPUID_MIN;
+has_msr_hv_hypercall = true;
 }
 c->ebx = signature[0];
 c->ecx = signature[1];
@@ -475,7 +478,7 @@ int kvm_arch_init_vcpu(CPUState *cs)
 c->function = KVM_CPUID_FEATURES;
 c->eax = env->features[FEAT_KVM];
 
-if (hyperv_enabled(cpu)) {
+if (has_msr_hv_hypercall) {
 memcpy(signature, "Hv#1\0\0\0\0\0\0\0\0", 12);
 c->eax = signature[0];
 
@@ -1176,9 +1179,11 @@ static int kvm_put_msrs(X86CPU *cpu, int level)
 kvm_msr_entry_set(&msrs[n++], MSR_CORE_PERF_GLOBAL_CTRL,
   env->msr_global_ctrl);
 }
-if (hyperv_hypercall_available(cpu)) {
-kvm_msr_entry_set(&msrs[n++], HV_X64_MSR_GUEST_OS_ID, 0);
-kvm_msr_entry_set(&msrs[n++], HV_X64_MSR_HYPERCALL, 0);
+if (has_msr_hv_hypercall) {
+kvm_msr_entry_set(&msrs[n++], HV_X64_MSR_GUEST_OS_ID,
+  env->msr_hv_guest_os_id);
+kvm_msr_entry_set(&msrs[n++], HV_X64_MSR_HYPERCALL,
+  env->msr_hv_hypercall);
 }
 if (cpu->hyperv_vapic) {
 kvm_msr_entry_set(&msrs[n++], HV_X64_MSR_APIC_ASSIST_PAGE, 0);
@@ -1461,6 +1466,10 @@ static int kvm_get_msrs(X86CPU *cpu)
 }
 }
 
+if (has_msr_hv_hypercall) {
+msrs[n++].index = HV_X64_MSR_HYPERCALL;
+msrs[n++].index = HV_X64_MSR_GUEST_OS_ID;
+}
 msr_data.info.nmsrs = n;
 ret = kvm_vcpu_ioctl(CPU(cpu), KVM_GET_MSRS, &msr_data);
 if (ret < 0) {
@@ -1565,6 +1574,12 @@ static int kvm_get_msrs(X86CPU *cpu)
 case MSR_P6_EVNTSEL0 ... MSR_P6_EVNTSEL0 + MAX_GP_COUNTERS - 1:
 env->msr_gp_evtsel[index - MSR_P6_EVNTSEL0] = msrs[i].data;
 break;
+case HV_X64_MSR_HYPERCALL:
+env->msr_hv_hypercall = msrs[i].data;
+break;
+case HV_X64_MSR_GUEST_OS_ID:
+env->msr_hv_guest_os_id = msrs[i].data;
+break;
 }
 }
 
diff --git a/target-i386/machine.c b/target-i386/machine.c
index e568da2..3809d06 100644
--- a/target-i386/machine.c
+++ b/target-i386/machine.c
@@ -506,6 +506,26 @@ static const VMStateDescription 
vmstate_msr_architectural_pmu = {
 }
 };
 
+static bool hyperv_hypercall_enable_needed(void *opaque)
+{
+X86CPU *cpu = opaque;
+CPUX86State *env = &cpu->env;
+
+return env->msr_hv_hypercall != 0 || env->msr_hv_guest_os_id != 0;
+}
+
+static const VMStateDescription vmstate_msr_hypercall_hypercall = {
+.name = "cpu/msr_hyperv_hypercall",
+.version_id = 1,
+.minimum_version_id = 1,
+.minimum_version_id_old = 1,
+.fields  = (VMStateField []) {
+VMSTATE_UINT64(env.msr_hv_hypercall, X86CPU),
+VMSTATE_UINT64(env.msr_hv_guest_os_id, X86CPU),
+VMSTATE_END_OF_LIST()
+}
+};
+
 const VMStateDescription vmstate_x86_cpu = {
 .name = "cpu",
 .version_id = 12,
@@ -637,6 +657,9 @@ const VMStateDescription vmstate_x86_cpu = {
 }, {
 .vmsd = &vmstate_msr_architectural_pmu,
 .needed = pmu_enable_needed,
+}, {
+.vmsd = &vmstate_msr_hypercall_hypercall,
+.needed = hyperv_hypercall_enable_needed,
 } , {
 /* empty */
 }
-- 
1.8.1.4

[Qemu-devel] [PATCH v2 3/7] Don't specify implementation limits

[Vadim Rozenfeld]

According to "Requirements for Implementing the Microsoft Hypervisor
Interface" (http://msdn.microsoft.com/library/windows/hardware/hh975392)
page 7, parameters "The maximum number of virtual processors supported"
and "The maximum number of logical processors supported" are not required
and may be set to zero

Signed-off-by: Vadim Rozenfeld 
---
 target-i386/kvm.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/target-i386/kvm.c b/target-i386/kvm.c
index 0aa85a3..8adf27e 100644
--- a/target-i386/kvm.c
+++ b/target-i386/kvm.c
@@ -500,11 +500,6 @@ int kvm_arch_init_vcpu(CPUState *cs)
 c->ebx = cpu->hyperv_spinlock_attempts;
 
 c = &cpuid_data.entries[cpuid_i++];
-c->function = HYPERV_CPUID_IMPLEMENT_LIMITS;
-c->eax = 0x40;
-c->ebx = 0x40;
-
-c = &cpuid_data.entries[cpuid_i++];
 c->function = KVM_CPUID_SIGNATURE_NEXT;
 memcpy(signature, "KVMKVMKVM\0\0\0", 12);
 c->eax = 0;
-- 
1.8.1.4

[Qemu-devel] [PATCH v2 4/7] Don't report the KVM signature twice, since it's already reported in KVM_CPUID_SIGNATURE CPUID leaf.

[Vadim Rozenfeld]

Signed-off-by: Vadim Rozenfeld 
---
 target-i386/kvm.c | 8 
 1 file changed, 8 deletions(-)

diff --git a/target-i386/kvm.c b/target-i386/kvm.c
index 8adf27e..c1bc8c0 100644
--- a/target-i386/kvm.c
+++ b/target-i386/kvm.c
@@ -498,14 +498,6 @@ int kvm_arch_init_vcpu(CPUState *cs)
 c->eax |= HV_X64_APIC_ACCESS_RECOMMENDED;
 }
 c->ebx = cpu->hyperv_spinlock_attempts;
-
-c = &cpuid_data.entries[cpuid_i++];
-c->function = KVM_CPUID_SIGNATURE_NEXT;
-memcpy(signature, "KVMKVMKVM\0\0\0", 12);
-c->eax = 0;
-c->ebx = signature[0];
-c->ecx = signature[1];
-c->edx = signature[2];
 }
 
 has_msr_async_pf_en = c->eax & (1 << KVM_FEATURE_ASYNC_PF);
-- 
1.8.1.4

[Qemu-devel] [PATCH v2 0/7] Hyper-V parameters update

[Vadim Rozenfeld]

This series consists of several clean-ups,
hyper-v MSRs migration fixes, and adding
support for new "hv-time" parameter, which 
designed for activating hyper-v timers feature.  

v2 -> v1
  Split the previous series into small pieces.

Vadim Rozenfeld (7):
  Don't report "Microsoft" as the vendor ID signature.
  Don't specify hypervisor system identity
  Don't specify implementation limits
  Don't report the KVM signature twice, since it's already reported
in KVM_CPUID_SIGNATURE CPUID leaf.
  make hyperv hypercall and guest os id MSRs migratable.
  make hyperv vapic assist page migratable
  add support for hyper-v timers

 linux-headers/asm-x86/hyperv.h |  3 ++
 linux-headers/linux/kvm.h  |  1 +
 target-i386/cpu-qom.h  |  1 +
 target-i386/cpu.c  |  1 +
 target-i386/cpu.h  |  4 ++
 target-i386/kvm.c  | 85 +++---
 target-i386/machine.c  | 66 
 7 files changed, 130 insertions(+), 31 deletions(-)

-- 
1.8.1.4

[Qemu-devel] [PATCH v2 1/7] Don't report "Microsoft" as the vendor ID signature.

[Vadim Rozenfeld]

According to "Requirements for Implementing the Microsoft Hypervisor
Interface" (http://msdn.microsoft.com/library/windows/hardware/hh975392)
page 4, conformant hypervisors are not required to report the vendor id
signature. Guest use this information for reporting and diagnostic
purposes only.

Signed-off-by: Vadim Rozenfeld 
---
 target-i386/kvm.c | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/target-i386/kvm.c b/target-i386/kvm.c
index 7522e98..db1583a 100644
--- a/target-i386/kvm.c
+++ b/target-i386/kvm.c
@@ -463,11 +463,8 @@ int kvm_arch_init_vcpu(CPUState *cs)
 /* Paravirtualization CPUIDs */
 c = &cpuid_data.entries[cpuid_i++];
 c->function = KVM_CPUID_SIGNATURE;
-if (!hyperv_enabled(cpu)) {
-memcpy(signature, "KVMKVMKVM\0\0\0", 12);
-c->eax = 0;
-} else {
-memcpy(signature, "Microsoft Hv", 12);
+memcpy(signature, "KVMKVMKVM\0\0\0", 12);
+if (hyperv_enabled(cpu)) {
 c->eax = HYPERV_CPUID_MIN;
 }
 c->ebx = signature[0];
-- 
1.8.1.4

[Qemu-devel] [PATCH v2 2/7] Don't specify hypervisor system identity

[Vadim Rozenfeld]

According to "Requirements for Implementing the Microsoft Hypervisor
Interface" (http://msdn.microsoft.com/library/windows/hardware/hh975392)
page 5, this leaf is recommended but not required. It may be used for
diagnostic and reporting purposes.

Signed-off-by: Vadim Rozenfeld 
---
 target-i386/kvm.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/target-i386/kvm.c b/target-i386/kvm.c
index db1583a..0aa85a3 100644
--- a/target-i386/kvm.c
+++ b/target-i386/kvm.c
@@ -480,11 +480,6 @@ int kvm_arch_init_vcpu(CPUState *cs)
 c->eax = signature[0];
 
 c = &cpuid_data.entries[cpuid_i++];
-c->function = HYPERV_CPUID_VERSION;
-c->eax = 0x1bbc;
-c->ebx = 0x00060001;
-
-c = &cpuid_data.entries[cpuid_i++];
 c->function = HYPERV_CPUID_FEATURES;
 if (cpu->hyperv_relaxed_timing) {
 c->eax |= HV_X64_MSR_HYPERCALL_AVAILABLE;
-- 
1.8.1.4

Re: [Qemu-devel] [PATCH 3/3] add support for hyperv time parameter

[Vadim Rozenfeld]

On Tue, 2014-01-21 at 11:21 +0100, Paolo Bonzini wrote:
> Il 21/01/2014 09:02, Vadim Rozenfeld ha scritto:
> > From: Vadim Rozenfeld 
> > 
> > Signed-off-by: Vadim Rozenfeld 
> > ---
> >  linux-headers/asm-x86/hyperv.h |  3 +++
> >  linux-headers/linux/kvm.h  |  1 +
> >  target-i386/cpu-qom.h  |  1 +
> >  target-i386/cpu.c  |  1 +
> >  target-i386/cpu.h  |  1 +
> >  target-i386/kvm.c  | 19 +++
> >  target-i386/machine.c  |  1 +
> >  7 files changed, 27 insertions(+)
> > 
> > diff --git a/linux-headers/asm-x86/hyperv.h b/linux-headers/asm-x86/hyperv.h
> > index b8f1c01..3b400ee 100644
> > --- a/linux-headers/asm-x86/hyperv.h
> > +++ b/linux-headers/asm-x86/hyperv.h
> > @@ -149,6 +149,9 @@
> >  /* MSR used to read the per-partition time reference counter */
> >  #define HV_X64_MSR_TIME_REF_COUNT  0x4020
> >  
> > +/* A partition's reference time stamp counter (TSC) page */
> > +#define HV_X64_MSR_REFERENCE_TSC   0x4021
> > +
> >  /* MSR used to retrieve the TSC frequency */
> >  #define HV_X64_MSR_TSC_FREQUENCY   0x4022
> >  
> > diff --git a/linux-headers/linux/kvm.h b/linux-headers/linux/kvm.h
> > index 5a49671..999fb13 100644
> > --- a/linux-headers/linux/kvm.h
> > +++ b/linux-headers/linux/kvm.h
> > @@ -674,6 +674,7 @@ struct kvm_ppc_smmu_info {
> >  #define KVM_CAP_ARM_EL1_32BIT 93
> >  #define KVM_CAP_SPAPR_MULTITCE 94
> >  #define KVM_CAP_EXT_EMUL_CPUID 95
> > +#define KVM_CAP_HYPERV_TIME 96
> >  
> >  #ifdef KVM_CAP_IRQ_ROUTING
> >  
> > diff --git a/target-i386/cpu-qom.h b/target-i386/cpu-qom.h
> > index d1751a4..722f11a 100644
> > --- a/target-i386/cpu-qom.h
> > +++ b/target-i386/cpu-qom.h
> > @@ -69,6 +69,7 @@ typedef struct X86CPU {
> >  bool hyperv_vapic;
> >  bool hyperv_relaxed_timing;
> >  int hyperv_spinlock_attempts;
> > +bool hyperv_time;
> >  bool check_cpuid;
> >  bool enforce_cpuid;
> >  
> > diff --git a/target-i386/cpu.c b/target-i386/cpu.c
> > index 0eea8c7..ff3290c 100644
> > --- a/target-i386/cpu.c
> > +++ b/target-i386/cpu.c
> > @@ -2744,6 +2744,7 @@ static Property x86_cpu_properties[] = {
> >  { .name  = "hv-spinlocks", .info  = &qdev_prop_spinlocks },
> >  DEFINE_PROP_BOOL("hv-relaxed", X86CPU, hyperv_relaxed_timing, false),
> >  DEFINE_PROP_BOOL("hv-vapic", X86CPU, hyperv_vapic, false),
> > +DEFINE_PROP_BOOL("hv-time", X86CPU, hyperv_time, false),
> >  DEFINE_PROP_BOOL("check", X86CPU, check_cpuid, false),
> >  DEFINE_PROP_BOOL("enforce", X86CPU, enforce_cpuid, false),
> >  DEFINE_PROP_END_OF_LIST()
> > diff --git a/target-i386/cpu.h b/target-i386/cpu.h
> > index 6eeafdc..f7d7689 100644
> > --- a/target-i386/cpu.h
> > +++ b/target-i386/cpu.h
> > @@ -850,6 +850,7 @@ typedef struct CPUX86State {
> >  uint64_t msr_hv_hypercall;
> >  uint64_t msr_hv_guest_os_id;
> >  uint64_t msr_hv_vapic;
> > +uint64_t msr_hv_tsc;
> >  
> >  /* exception/interrupt handling */
> >  int error_code;
> > diff --git a/target-i386/kvm.c b/target-i386/kvm.c
> > index 5152e64..75ebc5d 100644
> > --- a/target-i386/kvm.c
> > +++ b/target-i386/kvm.c
> > @@ -73,6 +73,7 @@ static bool has_msr_kvm_steal_time;
> >  static int lm_capable_kernel;
> >  static bool has_msr_hv_hypercall;
> >  static bool has_msr_hv_vapic;
> > +static bool has_msr_hv_tsc;
> >  
> >  static bool has_msr_architectural_pmu;
> >  static uint32_t num_architectural_pmu_counters;
> > @@ -433,6 +434,7 @@ unsigned long kvm_arch_vcpu_id(CPUState *cs)
> >  static bool hyperv_hypercall_available(X86CPU *cpu)
> >  {
> >  return cpu->hyperv_vapic ||
> > +   cpu->hyperv_time  ||
> > (cpu->hyperv_spinlock_attempts != HYPERV_SPINLOCK_NEVER_RETRY);
> >  }
> >  
> > @@ -492,6 +494,13 @@ int kvm_arch_init_vcpu(CPUState *cs)
> >  c->eax |= HV_X64_MSR_APIC_ACCESS_AVAILABLE;
> >  has_msr_hv_vapic = true;
> >  }
> > +if (cpu->hyperv_time &&
> > +kvm_check_extension(cs->kvm_state, KVM_CAP_HYPERV_TIME) > 0) {
> > +c->eax |= HV_X64_MSR_HYPERCALL_AVAILABLE;
> > +c->eax |= HV_X64_MSR_TIME_REF_COUNT_AVAILABLE;
> > +c->eax |= 0x200;
> > + 

[Qemu-devel] [PATCH 0/3] Hyper-V parameters

[Vadim Rozenfeld]

From: Vadim Rozenfeld 

This series conists of three patches and addresses
the following issues:
 - adjusting hyperv parameters according to MS requirements
   http://msdn.microsoft.com/library/windows/hardware/hh975392
 - make hyperv hypercall and vapic pages migratable
 - add support for enabling hyperv reference counters

Vadim Rozenfeld (3):
  cleanup hyper-v interface initialization
  make hyperv hypercall, vapic, and os id MSRs migratable
  add support for hyperv time parameter

 linux-headers/asm-x86/hyperv.h |  3 ++
 linux-headers/linux/kvm.h  |  1 +
 target-i386/cpu-qom.h  |  1 +
 target-i386/cpu.c  |  1 +
 target-i386/cpu.h  |  5 +++
 target-i386/kvm.c  | 95 +++---
 target-i386/machine.c  | 25 +++
 7 files changed, 97 insertions(+), 34 deletions(-)

-- 
1.8.3.1

[Qemu-devel] [PATCH 2/3] make hyperv hypercall, vapic, and os id MSRs migratable

[Vadim Rozenfeld]

Signed-off-by: Vadim Rozenfeld 
---
 target-i386/cpu.h |  4 
 target-i386/kvm.c | 30 +-
 target-i386/machine.c | 24 
 3 files changed, 53 insertions(+), 5 deletions(-)

diff --git a/target-i386/cpu.h b/target-i386/cpu.h
index 1d94a9d..6eeafdc 100644
--- a/target-i386/cpu.h
+++ b/target-i386/cpu.h
@@ -847,6 +847,10 @@ typedef struct CPUX86State {
 uint64_t msr_gp_counters[MAX_GP_COUNTERS];
 uint64_t msr_gp_evtsel[MAX_GP_COUNTERS];
 
+uint64_t msr_hv_hypercall;
+uint64_t msr_hv_guest_os_id;
+uint64_t msr_hv_vapic;
+
 /* exception/interrupt handling */
 int error_code;
 int exception_is_int;
diff --git a/target-i386/kvm.c b/target-i386/kvm.c
index 768ca1d..5152e64 100644
--- a/target-i386/kvm.c
+++ b/target-i386/kvm.c
@@ -1185,12 +1185,15 @@ static int kvm_put_msrs(X86CPU *cpu, int level)
 kvm_msr_entry_set(&msrs[n++], MSR_CORE_PERF_GLOBAL_CTRL,
   env->msr_global_ctrl);
 }
-if (hyperv_hypercall_available(cpu)) {
-kvm_msr_entry_set(&msrs[n++], HV_X64_MSR_GUEST_OS_ID, 0);
-kvm_msr_entry_set(&msrs[n++], HV_X64_MSR_HYPERCALL, 0);
+if (has_msr_hv_hypercall) {
+kvm_msr_entry_set(&msrs[n++], HV_X64_MSR_GUEST_OS_ID,
+  env->msr_hv_guest_os_id);
+kvm_msr_entry_set(&msrs[n++], HV_X64_MSR_HYPERCALL,
+  env->msr_hv_hypercall);
 }
-if (cpu->hyperv_vapic) {
-kvm_msr_entry_set(&msrs[n++], HV_X64_MSR_APIC_ASSIST_PAGE, 0);
+if (has_msr_hv_vapic) {
+kvm_msr_entry_set(&msrs[n++], HV_X64_MSR_APIC_ASSIST_PAGE,
+  env->msr_hv_vapic);
 }
 if (has_msr_feature_control) {
 kvm_msr_entry_set(&msrs[n++], MSR_IA32_FEATURE_CONTROL,
@@ -1470,6 +1473,14 @@ static int kvm_get_msrs(X86CPU *cpu)
 }
 }
 
+if (has_msr_hv_hypercall) {
+msrs[n++].index = HV_X64_MSR_HYPERCALL;
+msrs[n++].index = HV_X64_MSR_GUEST_OS_ID;
+}
+if (has_msr_hv_vapic) {
+msrs[n++].index = HV_X64_MSR_APIC_ASSIST_PAGE;
+}
+
 msr_data.info.nmsrs = n;
 ret = kvm_vcpu_ioctl(CPU(cpu), KVM_GET_MSRS, &msr_data);
 if (ret < 0) {
@@ -1574,6 +1585,15 @@ static int kvm_get_msrs(X86CPU *cpu)
 case MSR_P6_EVNTSEL0 ... MSR_P6_EVNTSEL0 + MAX_GP_COUNTERS - 1:
 env->msr_gp_evtsel[index - MSR_P6_EVNTSEL0] = msrs[i].data;
 break;
+case HV_X64_MSR_HYPERCALL:
+env->msr_hv_hypercall = msrs[i].data;
+break;
+case HV_X64_MSR_GUEST_OS_ID:
+env->msr_hv_guest_os_id = msrs[i].data;
+break;
+case HV_X64_MSR_APIC_ASSIST_PAGE:
+env->msr_hv_vapic = msrs[i].data;
+break;
 }
 }
 
diff --git a/target-i386/machine.c b/target-i386/machine.c
index e568da2..58c5b45 100644
--- a/target-i386/machine.c
+++ b/target-i386/machine.c
@@ -506,6 +506,27 @@ static const VMStateDescription 
vmstate_msr_architectural_pmu = {
 }
 };
 
+static bool hyperv_enable_needed(void *opaque)
+{
+X86CPU *cpu = opaque;
+CPUX86State *env = &cpu->env;
+
+return env->msr_hv_hypercall != 0;
+}
+
+static const VMStateDescription vmstate_msr_hyperv = {
+.name = "cpu/msr_hyperv",
+.version_id = 1,
+.minimum_version_id = 1,
+.minimum_version_id_old = 1,
+.fields  = (VMStateField []) {
+VMSTATE_UINT64(env.msr_hv_hypercall, X86CPU),
+VMSTATE_UINT64(env.msr_hv_guest_os_id, X86CPU),
+VMSTATE_UINT64(env.msr_hv_vapic, X86CPU),
+VMSTATE_END_OF_LIST()
+}
+};
+
 const VMStateDescription vmstate_x86_cpu = {
 .name = "cpu",
 .version_id = 12,
@@ -637,6 +658,9 @@ const VMStateDescription vmstate_x86_cpu = {
 }, {
 .vmsd = &vmstate_msr_architectural_pmu,
 .needed = pmu_enable_needed,
+}, {
+.vmsd = &vmstate_msr_hyperv,
+.needed = hyperv_enable_needed,
 } , {
 /* empty */
 }
-- 
1.8.3.1

[Qemu-devel] [PATCH 3/3] add support for hyperv time parameter

[Vadim Rozenfeld]

From: Vadim Rozenfeld 

Signed-off-by: Vadim Rozenfeld 
---
 linux-headers/asm-x86/hyperv.h |  3 +++
 linux-headers/linux/kvm.h  |  1 +
 target-i386/cpu-qom.h  |  1 +
 target-i386/cpu.c  |  1 +
 target-i386/cpu.h  |  1 +
 target-i386/kvm.c  | 19 +++
 target-i386/machine.c  |  1 +
 7 files changed, 27 insertions(+)

diff --git a/linux-headers/asm-x86/hyperv.h b/linux-headers/asm-x86/hyperv.h
index b8f1c01..3b400ee 100644
--- a/linux-headers/asm-x86/hyperv.h
+++ b/linux-headers/asm-x86/hyperv.h
@@ -149,6 +149,9 @@
 /* MSR used to read the per-partition time reference counter */
 #define HV_X64_MSR_TIME_REF_COUNT  0x4020
 
+/* A partition's reference time stamp counter (TSC) page */
+#define HV_X64_MSR_REFERENCE_TSC   0x4021
+
 /* MSR used to retrieve the TSC frequency */
 #define HV_X64_MSR_TSC_FREQUENCY   0x4022
 
diff --git a/linux-headers/linux/kvm.h b/linux-headers/linux/kvm.h
index 5a49671..999fb13 100644
--- a/linux-headers/linux/kvm.h
+++ b/linux-headers/linux/kvm.h
@@ -674,6 +674,7 @@ struct kvm_ppc_smmu_info {
 #define KVM_CAP_ARM_EL1_32BIT 93
 #define KVM_CAP_SPAPR_MULTITCE 94
 #define KVM_CAP_EXT_EMUL_CPUID 95
+#define KVM_CAP_HYPERV_TIME 96
 
 #ifdef KVM_CAP_IRQ_ROUTING
 
diff --git a/target-i386/cpu-qom.h b/target-i386/cpu-qom.h
index d1751a4..722f11a 100644
--- a/target-i386/cpu-qom.h
+++ b/target-i386/cpu-qom.h
@@ -69,6 +69,7 @@ typedef struct X86CPU {
 bool hyperv_vapic;
 bool hyperv_relaxed_timing;
 int hyperv_spinlock_attempts;
+bool hyperv_time;
 bool check_cpuid;
 bool enforce_cpuid;
 
diff --git a/target-i386/cpu.c b/target-i386/cpu.c
index 0eea8c7..ff3290c 100644
--- a/target-i386/cpu.c
+++ b/target-i386/cpu.c
@@ -2744,6 +2744,7 @@ static Property x86_cpu_properties[] = {
 { .name  = "hv-spinlocks", .info  = &qdev_prop_spinlocks },
 DEFINE_PROP_BOOL("hv-relaxed", X86CPU, hyperv_relaxed_timing, false),
 DEFINE_PROP_BOOL("hv-vapic", X86CPU, hyperv_vapic, false),
+DEFINE_PROP_BOOL("hv-time", X86CPU, hyperv_time, false),
 DEFINE_PROP_BOOL("check", X86CPU, check_cpuid, false),
 DEFINE_PROP_BOOL("enforce", X86CPU, enforce_cpuid, false),
 DEFINE_PROP_END_OF_LIST()
diff --git a/target-i386/cpu.h b/target-i386/cpu.h
index 6eeafdc..f7d7689 100644
--- a/target-i386/cpu.h
+++ b/target-i386/cpu.h
@@ -850,6 +850,7 @@ typedef struct CPUX86State {
 uint64_t msr_hv_hypercall;
 uint64_t msr_hv_guest_os_id;
 uint64_t msr_hv_vapic;
+uint64_t msr_hv_tsc;
 
 /* exception/interrupt handling */
 int error_code;
diff --git a/target-i386/kvm.c b/target-i386/kvm.c
index 5152e64..75ebc5d 100644
--- a/target-i386/kvm.c
+++ b/target-i386/kvm.c
@@ -73,6 +73,7 @@ static bool has_msr_kvm_steal_time;
 static int lm_capable_kernel;
 static bool has_msr_hv_hypercall;
 static bool has_msr_hv_vapic;
+static bool has_msr_hv_tsc;
 
 static bool has_msr_architectural_pmu;
 static uint32_t num_architectural_pmu_counters;
@@ -433,6 +434,7 @@ unsigned long kvm_arch_vcpu_id(CPUState *cs)
 static bool hyperv_hypercall_available(X86CPU *cpu)
 {
 return cpu->hyperv_vapic ||
+   cpu->hyperv_time  ||
(cpu->hyperv_spinlock_attempts != HYPERV_SPINLOCK_NEVER_RETRY);
 }
 
@@ -492,6 +494,13 @@ int kvm_arch_init_vcpu(CPUState *cs)
 c->eax |= HV_X64_MSR_APIC_ACCESS_AVAILABLE;
 has_msr_hv_vapic = true;
 }
+if (cpu->hyperv_time &&
+kvm_check_extension(cs->kvm_state, KVM_CAP_HYPERV_TIME) > 0) {
+c->eax |= HV_X64_MSR_HYPERCALL_AVAILABLE;
+c->eax |= HV_X64_MSR_TIME_REF_COUNT_AVAILABLE;
+c->eax |= 0x200;
+has_msr_hv_tsc = true;
+}
 
 c = &cpuid_data.entries[cpuid_i++];
 c->function = HYPERV_CPUID_ENLIGHTMENT_INFO;
@@ -1195,6 +1204,10 @@ static int kvm_put_msrs(X86CPU *cpu, int level)
 kvm_msr_entry_set(&msrs[n++], HV_X64_MSR_APIC_ASSIST_PAGE,
   env->msr_hv_vapic);
 }
+if (has_msr_hv_tsc) {
+kvm_msr_entry_set(&msrs[n++], HV_X64_MSR_REFERENCE_TSC,
+  env->msr_hv_tsc);
+}
 if (has_msr_feature_control) {
 kvm_msr_entry_set(&msrs[n++], MSR_IA32_FEATURE_CONTROL,
   env->msr_ia32_feature_control);
@@ -1480,6 +1493,9 @@ static int kvm_get_msrs(X86CPU *cpu)
 if (has_msr_hv_vapic) {
 msrs[n++].index = HV_X64_MSR_APIC_ASSIST_PAGE;
 }
+if (has_msr_hv_tsc) {
+msrs[n++].index = HV_X64_MSR_REFERENCE_TSC;
+}
 
 msr_data.info.nmsrs = n;
 ret = kvm_vcpu_ioctl(CPU(cpu), KVM_GET_MSRS, &msr_data);
@@ -1594,6 +1610,9 @@ static int kvm_get_msrs(X86CPU *cpu)
 case HV_X64_MSR_APIC_ASSIST_PAGE:
 

[Qemu-devel] [PATCH 1/3] cleanup hyper-v interface initialization

[Vadim Rozenfeld]

Signed-off-by: Vadim Rozenfeld 
---
 target-i386/kvm.c | 46 +-
 1 file changed, 17 insertions(+), 29 deletions(-)

diff --git a/target-i386/kvm.c b/target-i386/kvm.c
index 7522e98..768ca1d 100644
--- a/target-i386/kvm.c
+++ b/target-i386/kvm.c
@@ -71,6 +71,8 @@ static bool has_msr_pv_eoi_en;
 static bool has_msr_misc_enable;
 static bool has_msr_kvm_steal_time;
 static int lm_capable_kernel;
+static bool has_msr_hv_hypercall;
+static bool has_msr_hv_vapic;
 
 static bool has_msr_architectural_pmu;
 static uint32_t num_architectural_pmu_counters;
@@ -463,13 +465,7 @@ int kvm_arch_init_vcpu(CPUState *cs)
 /* Paravirtualization CPUIDs */
 c = &cpuid_data.entries[cpuid_i++];
 c->function = KVM_CPUID_SIGNATURE;
-if (!hyperv_enabled(cpu)) {
-memcpy(signature, "KVMKVMKVM\0\0\0", 12);
-c->eax = 0;
-} else {
-memcpy(signature, "Microsoft Hv", 12);
-c->eax = HYPERV_CPUID_MIN;
-}
+memcpy(signature, "KVMKVMKVM\0\0\0", 12);
 c->ebx = signature[0];
 c->ecx = signature[1];
 c->edx = signature[2];
@@ -478,23 +474,23 @@ int kvm_arch_init_vcpu(CPUState *cs)
 c->function = KVM_CPUID_FEATURES;
 c->eax = env->features[FEAT_KVM];
 
-if (hyperv_enabled(cpu)) {
+if (hyperv_enabled(cpu) &&
+kvm_check_extension(cs->kvm_state, KVM_CAP_HYPERV) > 0) {
+has_msr_hv_hypercall = true;
+
 memcpy(signature, "Hv#1\0\0\0\0\0\0\0\0", 12);
 c->eax = signature[0];
 
 c = &cpuid_data.entries[cpuid_i++];
-c->function = HYPERV_CPUID_VERSION;
-c->eax = 0x1bbc;
-c->ebx = 0x00060001;
-
-c = &cpuid_data.entries[cpuid_i++];
 c->function = HYPERV_CPUID_FEATURES;
 if (cpu->hyperv_relaxed_timing) {
 c->eax |= HV_X64_MSR_HYPERCALL_AVAILABLE;
 }
-if (cpu->hyperv_vapic) {
+if (cpu->hyperv_vapic &&
+kvm_check_extension(cs->kvm_state, KVM_CAP_HYPERV_VAPIC) > 0) {
 c->eax |= HV_X64_MSR_HYPERCALL_AVAILABLE;
 c->eax |= HV_X64_MSR_APIC_ACCESS_AVAILABLE;
+has_msr_hv_vapic = true;
 }
 
 c = &cpuid_data.entries[cpuid_i++];
@@ -502,23 +498,15 @@ int kvm_arch_init_vcpu(CPUState *cs)
 if (cpu->hyperv_relaxed_timing) {
 c->eax |= HV_X64_RELAXED_TIMING_RECOMMENDED;
 }
-if (cpu->hyperv_vapic) {
+if (has_msr_hv_vapic) {
 c->eax |= HV_X64_APIC_ACCESS_RECOMMENDED;
 }
-c->ebx = cpu->hyperv_spinlock_attempts;
-
-c = &cpuid_data.entries[cpuid_i++];
-c->function = HYPERV_CPUID_IMPLEMENT_LIMITS;
-c->eax = 0x40;
-c->ebx = 0x40;
-
-c = &cpuid_data.entries[cpuid_i++];
-c->function = KVM_CPUID_SIGNATURE_NEXT;
-memcpy(signature, "KVMKVMKVM\0\0\0", 12);
-c->eax = 0;
-c->ebx = signature[0];
-c->ecx = signature[1];
-c->edx = signature[2];
+if (cpu->hyperv_spinlock_attempts != HYPERV_SPINLOCK_NEVER_RETRY &&
+kvm_check_extension(cs->kvm_state, KVM_CAP_HYPERV_SPIN) > 0) {
+c->ebx = cpu->hyperv_spinlock_attempts;
+} else {
+c->ebx = HYPERV_SPINLOCK_NEVER_RETRY;
+}
 }
 
 has_msr_async_pf_en = c->eax & (1 << KVM_FEATURE_ASYNC_PF);
-- 
1.8.3.1

[Qemu-devel] [PATCH 0/3] Hyper-V parameters

[Vadim Rozenfeld]

From: Vadim Rozenfeld 

This series conists of three patches and addresses
the following issues:
 - adjusting hyperv parameters according to MS requirements
   http://msdn.microsoft.com/library/windows/hardware/hh975392
 - make hyperv hypercall and vapic pages migratable
 - add support for enabling hyperv reference counters

Vadim Rozenfeld (3):
  cleanup hyper-v interface initialization
  make hyperv hypercall, vapic, and os id MSRs migratable
  add support for hyperv time parameter

 linux-headers/asm-x86/hyperv.h |  3 ++
 linux-headers/linux/kvm.h  |  1 +
 target-i386/cpu-qom.h  |  1 +
 target-i386/cpu.c  |  1 +
 target-i386/cpu.h  |  5 +++
 target-i386/kvm.c  | 95 +++---
 target-i386/machine.c  | 25 +++
 7 files changed, 97 insertions(+), 34 deletions(-)

-- 
1.8.3.1

Re: [Qemu-devel] Occasional clockjump in Win2012 after Live Migration

[Vadim Rozenfeld]

On Fri, 2013-12-13 at 12:50 +0100, Peter Lieven wrote:
> Am 13.12.2013 11:10, schrieb Vadim Rozenfeld:
> > On Fri, 2013-12-13 at 09:27 +0100, Peter Lieven wrote:
> >> Am 13.12.2013 05:12, schrieb Vadim Rozenfeld:
> >>> Does your VM belong to domain or workgroup? 
> >> We had 2 vServers where this happened. One was a Domain Controller and the 
> >> second was an independent Workgroup Server.
> >>
> >> Do you have evidence how the DateTime Clock is driven in Windows 2012?
> > Should be CMOS periodic timer.
> you mean the RTC?
Right.
> Ok, so if there is a huge clock jump this one must have got messed up?
It might be. We have seen some similar problem during WHQL testing some
time ago. The problem happened because time on the host was not set
correct. So guest was taking this wrong time on boot and then it was a
big jump after resync with domain controller.

best regards,
Vadim.   
> 
> Peter
> 

Re: [Qemu-devel] Occasional clockjump in Win2012 after Live Migration

[Vadim Rozenfeld]

On Fri, 2013-12-13 at 09:27 +0100, Peter Lieven wrote:
> Am 13.12.2013 05:12, schrieb Vadim Rozenfeld:
> > Does your VM belong to domain or workgroup? 
> 
> We had 2 vServers where this happened. One was a Domain Controller and the 
> second was an independent Workgroup Server.
> 
> Do you have evidence how the DateTime Clock is driven in Windows 2012?

Should be CMOS periodic timer.

> 
> Peter
> 

Re: [Qemu-devel] Occasional clockjump in Win2012 after Live Migration

[Vadim Rozenfeld]

Does your VM belong to domain or workgroup? 
Best regards,
Vadim.

- Original Message -
From: "Peter Lieven" 
To: qemu-devel@nongnu.org, vroze...@redhat.com
Sent: Friday, December 13, 2013 3:03:45 AM
Subject: Occasional clockjump in Win2012 after Live Migration

Hi,

is anyone aware of a problem with a clock jump in Windows (observed in Server 
2012)
where after a successful live migration the clock jumps roughly 2 days into the 
future?

Maybe this is already fixed we observed this with qemu-kvm-1.2.0. I have not 
yet managed
to reproduce this, but it definetly happens.

Where is Windows getting the system clock from? RTC or addtionally internal 
clocksources
like HPET, PM_TIMER etc?

Thanks,
Peter

Re: [Qemu-devel] kvm/hyper-v: obtaining client machine id

[Vadim Rozenfeld]

On Tue, 2013-10-29 at 10:40 +0100, Peter Lieven wrote:
> On 29.10.2013 10:03, Vadim Rozenfeld wrote:
> >
> > - Original Message -
> > From: "Peter Lieven" 
> > To: "Gleb Natapov" , "Vadim Rozenfeld" 
> > , qemu-devel@nongnu.org
> > Sent: Monday, October 28, 2013 6:50:31 PM
> > Subject: [Qemu-devel] kvm/hyper-v: obtaining client machine id
> >
> > Hi,
> >
> > do you know if it is possible to obtain the client machine id of a Windows 
> > vServer via
> > a Hyper-V hypercall? I would need an information to check vServer 
> > activations against
> > our KMS.
> >
> > Hi Peter,
> >
> > WMI SoftwareLicensingService should be able to do it
> > http://msdn.microsoft.com/en-us/library/cc534597%28v=vs.85%29.aspx
> > Vadim.
> Sorry, I don't see how to get this information via a Hyper-V MSR?!
Yes, there is no such MSR. But you probably don't need it in any case.
If you need to collect CMIDs you can access WMI data on remote
computers. Alternatively, you can write a small application to obtain
CMID locally and pass it to host via virtio-serial port.

Vadim.
 
> 
> Peter
> >
> >
> > Thanks,
> > Peter
> >
> 
> 

Re: [Qemu-devel] kvm/hyper-v: obtaining client machine id

[Vadim Rozenfeld]

- Original Message -
From: "Peter Lieven" 
To: "Gleb Natapov" , "Vadim Rozenfeld" , 
qemu-devel@nongnu.org
Sent: Monday, October 28, 2013 6:50:31 PM
Subject: [Qemu-devel] kvm/hyper-v: obtaining client machine id

Hi,

do you know if it is possible to obtain the client machine id of a Windows 
vServer via
a Hyper-V hypercall? I would need an information to check vServer activations 
against
our KMS.

Hi Peter,

WMI SoftwareLicensingService should be able to do it
http://msdn.microsoft.com/en-us/library/cc534597%28v=vs.85%29.aspx
Vadim.


Thanks,
Peter

Re: [Qemu-devel] [PATCH qom-cpu 00/21 v9] target-i386: convert CPU features into properties

[Vadim Rozenfeld]

- Original Message -
From: "Igor Mammedov" 
To: "Igor Mammedov" 
Cc: "Anthony Liguori" , "Eduardo Habkost" 
, qemu-devel@nongnu.org, "Vadim Rozenfeld" 
, "Paolo Bonzini" , "Andreas Färber" 

Sent: Monday, October 14, 2013 3:09:11 PM
Subject: Re: [Qemu-devel] [PATCH qom-cpu 00/21 v9] target-i386: convert CPU 
features into properties

On Tue, 16 Jul 2013 00:25:53 +0200
Igor Mammedov  wrote:

> It's reordered and rebased v8 plus CPUID feature bits conversion to properties
> and cleanups that are removing unused anymore *_feature_name arrays.
> 
> dynamic => static properties conversion is still making sense as cleanup of
> initfn(), consolidating all properties in one place and making uniform
> property setters signatures, so it was kept.
> 
> hyperv and dynamic => static properties conversion are covered by virt-test's
> qemu_cpu test group.
> 
> On top of that, CPUID feature bits conversion and cleanups it's allowed.
> 
> git for testing: https://github.com/imammedo/qemu/tree/x86-cpu-properties.v9
> 
> v8-v9:
> * reorder hyperv/check/force and cpu_x86_parse_featurestr() cleanups to be 
> the first
> * when converting dynamic properties inline custom DEFINE_PROP_FOO directly in
>   cpu_x86_properties property array. (req: afaerber)
> * change "f-" CPUID feature bits prefix to "feat-" (req: afaerber)
> * replace F_* macros with a single X86CPU_FEAT() macro and simplify it setting
> default value to 0, intended for defaults to be set by initfn()
> * kvmclock: fix endless loop on compat kvmclock2 append
> * converted check_features_against_host() and x86_cpu_list() to use
>   static properties definition for feature name lookups, removing along the 
> way
>   unused anymore *_feature_name arrays.
> 
> v7-v8:
> * split out dynamic properties convertion patch into per property patches
>   to simplify review
> * drop feature bits convertion
> 
> v6-v7:
> * convert globals check_cpuid, enforce_cpuid and  hyperv_* to fields of
>   CPUState
> * Make PropertyInfo-s static
> * maintain legacy kvmclock semantic in cpu_x86_parse_featurestr()
> * existing properties code are not moved around, just fixed signatures where
>   it's needed and used visitors.
> 
> v5-v6:
> * when converting feature names to property names, replace '_' with '-'
> * separate patches converting existing dynamic properties into one, were
>   squashed into one [1/9] and change tested with virt-test(next).
> * patches that were touching +-foo features are squashed into one [9/9],
>   to avoid behavior change between them(f-kvmclock property).
> * the rest of conversions were basicaly rebased on top of current qom-cpu-next
>   tree, with small corrections
> 
> Igor Mammedov (20):
>   target-i386: Move hyperv_* static globals to X86CPU
>   target-i386: convert 'hv_spinlocks' to static property
>   target-i386: convert 'hv_relaxed' to static property
>   target-i386: convert 'hv_vapic' to static property
>   target-i386: convert 'check' and 'enforce' to static properties
>   target-i386: cleanup 'foo' feature handling'
>   target-i386: cleanup 'foo=val' feature handling
>   target-i386: cpu: convert 'level' to static property
>   target-i386: cpu: convert 'xlevel' to static property
>   target-i386: cpu: convert 'family' to static property
>   target-i386: cpu: convert 'model' to static property
>   target-i386: cpu: convert 'stepping' to static property
>   target-i386: cpu: convert 'vendor' to static property
>   target-i386: cpu: convert 'model-id' to static property
>   target-i386: cpu: convert 'tsc-frequency' to static property
>   target-i386: set [+-]feature using static properties
>   qdev: introduce qdev_prop_find_bit()
>   target-i386: use static properties in check_features_against_host() to
> print CPUID feature names
>   target-i386: use static properties to list CPUID features
>   target-i386: remove unused *_feature_name arrays
> 
>  hw/core/qdev-properties.c|  15 +
>  include/hw/qdev-properties.h |  13 +
>  target-i386/Makefile.objs|   2 +-
>  target-i386/cpu-qom.h|   6 +
>  target-i386/cpu.c| 705 
> +--
>  target-i386/cpu.h|   4 +
>  target-i386/hyperv.c |  64 
>  target-i386/hyperv.h |  45 ---
>  target-i386/kvm.c|  36 ++-
>  9 files changed, 415 insertions(+), 475 deletions(-)
>  delete mode 100644 target-i386/hyperv.c
>  delete mode 100644 target-i386/hyperv.h
> 

ping?

Hi Igor,
Looks fine with me.
Best regards,
Vadim.

Re: [Qemu-devel] updated: kvm PCI todo wiki

[Vadim Rozenfeld]

On Wed, 2013-08-21 at 14:45 +0200, Hannes Reinecke wrote:
> On 08/21/2013 12:48 PM, Michael S. Tsirkin wrote:
> > Hey guys,
> > I've put up a wiki page with a kvm PCI todo list,
> > mainly to avoid effort duplication, but also in the hope
> > to draw attention to what I think we should try addressing
> > in KVM:
> >
> > http://www.linux-kvm.org/page/PCITodo
> >
> > This page could cover all PCI related activity in KVM,
> > it is very incomplete.
> > We should probably add e.g. IOMMU related stuff.
> >
> > Note: if there's no developer listed for an item,
> > this just means I don't know of anyone actively working
> > on an issue at the moment, not that no one intends to.
> >
> > I would appreciate it if others working on one of the items on this list
> > would add their names so we can communicate better.  If others like this
> > wiki page, please go ahead and add stuff you are working on if any.
> >
> > It would be especially nice to add testing projects.
> >
> > Also, feel free to add links to bugzillas items.
> >
> On a related note, did anyone ever tried to test MSI / MSI-X with a 
> windows guest? I've tried to enable it for virtio but for some reason

MSI-X is a default mode for NetKvm and viostor on Vista and forward.
It must work. Just make sure that CPU family is 0xf or higher, otherwise
Windows will not activate MSI-X.
Vadim.
 
>  
> Windows didn't wanted to enable it. AHCI was even worse; the stock 
> Windows version doesn't support MSI and the Intel one doesn't like our 
> implementation :-(.
> 
> Anyone ever managed to get this to work?
> 
> If not it'd be a good topic for the wiki ...
> 
> Cheers,
> 
> Hannes

Re: [Qemu-devel] [SeaBIOS] [PATCH] don't expose pvpanic device in the UI

[Vadim Rozenfeld]

- Original Message -
From: "Gleb Natapov" 
To: "Vadim Rozenfeld" 
Cc: "Michael S. Tsirkin" , "Daniel P. Berrange" 
, "Marcel Apfelbaum" , 
seab...@seabios.org, qemu-devel@nongnu.org, "Gerd Hoffmann" 
, "Paolo Bonzini" , "Eric Blake" 
, "Andreas Färber" 
Sent: Tuesday, August 6, 2013 6:05:27 PM
Subject: Re: [SeaBIOS] [PATCH] don't expose pvpanic device in the UI

On Tue, Aug 06, 2013 at 04:03:17AM -0400, Vadim Rozenfeld wrote:
> 
> 
> - Original Message -
> From: "Gleb Natapov" 
> To: "Michael S. Tsirkin" 
> Cc: "Daniel P. Berrange" , "Marcel Apfelbaum" 
> , seab...@seabios.org, qemu-devel@nongnu.org, "Gerd 
> Hoffmann" , "Paolo Bonzini" , "Eric 
> Blake" , "Andreas Färber" 
> Sent: Tuesday, August 6, 2013 5:34:06 PM
> Subject: Re: [SeaBIOS] [PATCH] don't expose pvpanic device in the UI
> 
> On Mon, Aug 05, 2013 at 09:32:18PM +0300, Michael S. Tsirkin wrote:
> > > > As you see we do let people change many parameters
> > > > that do affect activation.
> > > By editing XML user can shoot himself in the foot, we should not prevent
> > > that.
> > 
> > So that's what I'm saying basically.
> > At the moment there's no way to remove this device from XML.
> > That's just wrong.
> Can say the same about PV acpi hotpulg device.
> 
> > In QEMU, we have a standard way to specify devices with -device.
> > That should be the interface for anything new really
> > unless there's a very compelling reason for something else.
> We are disagree on compelling reason in this case obviously.
> 
> > *Not* building it into the PC machine type.
> > 
> > > It should not be required though.
> > 
> > libvirt can pass -device pvpanic by default if nothing
> > is specified in XML. That discussion really has to happen
> > on libvirt list.
> > 
> As Paolo said you are just pushing the "problem" up the stack
> where it is harder to "solve". I put "problem" and "solve" in
> quotes because I disagree that the problem that need to be solved
> is identified correctly. The correct problem to be solved IMO is
> writing Windows driver for the device.
> 
> [VR]
> This one shouldn't be too complicated. Can be done on weekend.
Gal says he did it already.

[VR]
If so, we can add it to our build and make it public.

--
Gleb.

Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device supporting the tcm_vhost Linux kernel module

[Vadim Rozenfeld]

Hi Asias,

Windows driver should be able to support as many logical units and targets
as reported by QEMU. In case of VIRTIO_SCSI_S_BAD_TARGET it will just propagate
the relevant SRB error code to the port driver.
In any case, I will try reproducing this problem on my system. 

Best,
Vadim.

- Original Message -
From: "Asias He" 
To: "Libaiqing" 
Cc: "Paolo Bonzini" , "Wenchao Xia" 
, qemu-devel@nongnu.org, n...@linux-iscsi.org, 
"Michael S. Tsirkin" , "Haofeng" , "Vadim 
Rozenfeld" , "Yan Vugenfirer" 
Sent: Friday, July 5, 2013 4:52:05 PM
Subject: Re: [Qemu-devel] [PATCH 6/9] vhost-scsi: new device supporting the 
tcm_vhost Linux kernel module

[CCing Vadim and Yan]

On Thu, Jul 04, 2013 at 07:00:49AM +, Libaiqing wrote:
> Hi asias,
> 1 Window can not boot from vhost-scsi device;
> 2 A non-bootable vhost-scsi device can not be driven by windows guest.(I 
> used the driver virtio-win-0.1-59 version.)
> 
> Do you have any plan about these?

I can reproduce this issue on win2003 (Linux guest works fine). The guest
hangs in the boot process. OS is on virito-blk disk, vhost-scsi is
attached as the second disk.

Guest probes from target 0 to 255. Only target 1 is available.
vhost-scsi sends VIRTIO_SCSI_S_BAD_TARGET back to target 0 and 255 except
tareget 1. Howerver, from the log we can see, guest is sending to target
0 again and hangs afterwards.

Vadim and Yan, any ideas?

[ 3109.954237] br0: port 2(tap0) entered disabled state
[ 3109.954387] device tap0 left promiscuous mode
[ 3109.954389] br0: port 2(tap0) entered disabled state
[ 3119.534136] device tap0 entered promiscuous mode
[ 3119.534169] br0: port 2(tap0) entered forwarding state
[ 3119.534180] br0: port 2(tap0) entered forwarding state
[ 3120.138334] vhost_scsi_ctl_handle_kick: The handling func for control queue.
[ 3120.138666] vhost_get_vq_desc: head: 0, out: 1 in: 2
[ 3120.138669] Calling __copy_from_user: vq->iov[0].iov_base: 7f8f28006c15, 
len: 51
[ 3120.138671] target=0, tpg=  (null)
[ 3120.138672] send bad target head=0, out=1
[ 3120.138673] vhost_get_vq_desc: head: 128, out: 1 in: 2
[ 3120.139219] vhost_get_vq_desc: head: 0, out: 1 in: 2
[ 3120.139221] Calling __copy_from_user: vq->iov[0].iov_base: 7f8f28006c15, 
len: 51
[ 3120.139223] target=1, tpg=88021f8fc800
[ 3120.139225] Allocated tv_cmd: 880223cbf800 exp_data_len: 36, 
data_direction: 2
[ 3120.139226] vhost_scsi got command opcode: 0x12, lun: 0
[ 3120.139228] vhost_scsi_map_iov_to_sgl sg 8802242bde60 sgl_count 1 is_err 0
[ 3120.139229] Mapping 1 iovecs for 1 pages
[ 3120.139233] vhost_get_vq_desc: head: 128, out: 1 in: 2
[ 3120.139261] vhost_scsi_complete_cmd_work tv_cmd 880223cbf800 resid 0 
status 0x0
[ 3120.139470] vhost_get_vq_desc: head: 0, out: 1 in: 1
[ 3120.139472] Calling __copy_from_user: vq->iov[0].iov_base: 7f8f28006bd9, 
len: 51
[ 3120.139474] target=1, tpg=88021f8fc800
[ 3120.139475] Allocated tv_cmd: 880223cbf800 exp_data_len: 0, 
data_direction: 3
[ 3120.139476] vhost_scsi got command opcode: 0x0, lun: 0
[ 3120.139480] vhost_get_vq_desc: head: 128, out: 1 in: 1
[ 3120.139487] vhost_scsi_complete_cmd_work tv_cmd 880223cbf800 resid 0 
status 0x0
[ 3120.139554] vhost_get_vq_desc: head: 0, out: 1 in: 2
[ 3120.139557] Calling __copy_from_user: vq->iov[0].iov_base: 7f8f28006c15, 
len: 51
[ 3120.139558] target=1, tpg=88021f8fc800
[ 3120.139560] Allocated tv_cmd: 880223cbf800 exp_data_len: 8, 
data_direction: 2
[ 3120.139561] vhost_scsi got command opcode: 0x25, lun: 0
[ 3120.139563] vhost_scsi_map_iov_to_sgl sg 8802242bde60 sgl_count 1 is_err 0
[ 3120.139564] Mapping 1 iovecs for 1 pages
[ 3120.139568] vhost_get_vq_desc: head: 128, out: 1 in: 2
[ 3120.139575] vhost_scsi_complete_cmd_work tv_cmd 880223cbf800 resid 0 
status 0x0
[ 3120.139783] vhost_get_vq_desc: head: 0, out: 1 in: 2
[ 3120.139785] Calling __copy_from_user: vq->iov[0].iov_base: 7f8f28006c15, 
len: 51
[ 3120.139787] target=2, tpg=  (null)
[ 3120.139788] send bad target head=0, out=1
[ 3120.139789] vhost_get_vq_desc: head: 128, out: 1 in: 2
[ 3120.139938] vhost_get_vq_desc: head: 0, out: 1 in: 2
[ 3120.139940] Calling __copy_from_user: vq->iov[0].iov_base: 7f8f28006c15, 
len: 51

...

[ 3120.170209] vhost_get_vq_desc: head: 128, out: 1 in: 2
[ 3120.170304] vhost_get_vq_desc: head: 0, out: 1 in: 2
[ 3120.170305] Calling __copy_from_user: vq->iov[0].iov_base: 7f8f28006c15, 
len: 51
[ 3120.170306] target=255, tpg=  (null)
[ 3120.170306] send bad target head=0, out=1
[ 3120.170307] vhost_get_vq_desc: head: 128, out: 1 in: 2
[ 3120.474648] vhost_get_vq_desc: head: 0, out: 1 in: 2
[ 3120.474652] Calling __copy_from_user: vq->iov[0].iov_base: 7f8f280efe85, 
len: 51
[ 3120.474654] target=1, tpg=88021f8fc800
[ 3120.474656] Allocated tv_cmd: 8

Re: [Qemu-devel] [RFC PATCH 04/10] qemu-ga: Add Windows VSS provider to quiesce applications on fsfreeze

[Vadim Rozenfeld]

On Tue, 2013-03-26 at 16:30 +, Tomoki Sekiyama wrote:
> On 3/26/13 4:44 , "Vadim Rozenfeld"  wrote:
> 
> >On Tue, 2013-03-26 at 08:09 +0100, Paolo Bonzini wrote:
> >> Il 25/03/2013 21:50, Tomoki Sekiyama ha scritto:
> >>> Unfortunately, if I remove importlib("stdole2.tlb"), generated .tlb
> >>>seems
> >> > rejected to register into Windows COM+ Catalog.
> >> > 
> >> > Wine has stdole2.tlb in its fakedlls directory, but widl does not
> >>accept
> >> > this by
> >> > 
> >> >   error: Wrong or unsupported typelib magic 405a4d
> >> > 
> >> > Even if I copied native stdole2.tlb, widl fails with the same error.
> >> > 
> >> > Do you have any idea about this error?
> >
> >Seems like your tlb has nonstandard identifying characters. Check first
> >several bytes of the tlb file. Usually it should be something like '4D
> >53 46 54', or '4D 5A 90'
> 
> I found '4D 53 46 54' at offset 0x300 of stdole2.tlb.
> Wine's stdole2.tlb also have the signature at offset 0x738.
> 

I rechecked stdole2.tlb provided by MS. All three versions (arm, x86,
and x64) begin with 'MSFT' (4D 53 46 54) and have 00 00 00 00  at offset
0x300

> (might have an additional header before the main part?)
> 
> Widl accepted the wine's stdole2.tlb when I removed the header,
> but still, the generated qga-provider.tlb was not accepted by Windows...:(
> 
> >> 
> >> No, I suggest you ask on the Wine mailing lists.  In the meanwhile we
> >> can include a precompiled .tlb file in the QEMU repository and use midl.
> >> 
> >> Paolo
> 
> I will take this way so far.
> 
> Thanks,
> 
> Tomoki Sekiyama
> 

Re: [Qemu-devel] [RFC PATCH 04/10] qemu-ga: Add Windows VSS provider to quiesce applications on fsfreeze

[Vadim Rozenfeld]

On Tue, 2013-03-26 at 08:09 +0100, Paolo Bonzini wrote:
> Il 25/03/2013 21:50, Tomoki Sekiyama ha scritto:
> > Hi,
> > 
> > Paolo Bonzini  wrote:
> >> Il 14/02/2013 07:10, Tomoki Sekiyama ha scritto:
> >>> diff --git a/qga/vss-win32-provider/qga-provider.idl
> >> b/qga/vss-win32-provider/qga-provider.idl
> >>> new file mode 100644
> >>> index 000..17abca0
> >>> --- /dev/null
> >>> +++ b/qga/vss-win32-provider/qga-provider.idl
> >>> @@ -0,0 +1,20 @@
> >>> +import "oaidl.idl";
> >>> +import "ocidl.idl";
> >>> +
> >>> +[
> >>> +uuid(103B8142-6CE5-48A7-BDE1-794D3192FCF1),
> >>> +version(1.0),
> >>> +helpstring("QGAVSSProvider Type Library")
> >>> +]
> >>> +library QGAVSSHWProviderLib
> >>> +{
> >>> +importlib("stdole2.tlb");
> >>> +[
> >>> +uuid(6E6A3492-8D4D-440C-9619-5E5D0CC31CA8),
> >>> +helpstring("QGAVSSProvider Class")
> >>> +]
> >>> +coclass QGAVSSHWProvider
> >>> +{
> >>> +[default] interface IUnknown;
> >>> +};
> >>> +};
> >>
> >> Ok, I checked widl and it chokes on the importlib line.  If that can be
> >> removed, it's fine to use widl.
> >>
> >> The invocation is
> >>
> >>widl -m32/-m64 -o qga-provider.tlb -t qga-provider.idl
> >>
> >> where code to choose between -m32 and -m64 is already in the configure
> >> script (search for `case "$cpu"`).
> >>
> >> Paolo
> > 
> > Unfortunately, if I remove importlib("stdole2.tlb"), generated .tlb seems
> > rejected to register into Windows COM+ Catalog.
> > 
> > Wine has stdole2.tlb in its fakedlls directory, but widl does not accept
> > this by
> > 
> >   error: Wrong or unsupported typelib magic 405a4d
> > 
> > Even if I copied native stdole2.tlb, widl fails with the same error.
> > 
> > Do you have any idea about this error?

Seems like your tlb has nonstandard identifying characters. Check first
several bytes of the tlb file. Usually it should be something like '4D
53 46 54', or '4D 5A 90'
   
> 
> No, I suggest you ask on the Wine mailing lists.  In the meanwhile we
> can include a precompiled .tlb file in the QEMU repository and use midl.
> 
> Paolo
> 

Re: [Qemu-devel] Headsup: windows virtio networking does not work on current git

[Vadim Rozenfeld]

On Thu, 2013-02-07 at 14:33 +0100, Laszlo Ersek wrote:
> Apologies in advance for asking a possibly exorbitantly lame question...
> 
> On 02/06/13 10:47, Vadim Rozenfeld wrote:
> > On Tue, 2013-02-05 at 13:58 +0200, Michael S. Tsirkin wrote:
> >> On Tue, Feb 05, 2013 at 03:45:38PM +0400, Michael Tokarev wrote:
> >>> 05.02.2013 15:31, Vadim Rozenfeld wrote:
> >>>> On Mon, 2013-02-04 at 08:41 -0600, Anthony Liguori wrote:
> 
> >>>>> But adding feature bits an altering the config size doesn't constitute a
> >>>>> change in the software interface IMHO.
> >>>>
> >>>> I agree, feature bits are good. The only one problem with them, is that
> >>>> driver usually doesn't have access to PCI space during the driver
> >>>> loading phase.
> >>>
> >>> Vadim, can you please describe in a bit more details what the actual issue
> >>> here is, from the windows or windows driver point of view? 
> 
> > If a driver receives descriptor with memory type resources it needs to
> > map physical address to logical. This process requires the number of
> > bytes to be mapped, and it is the best place for sanity check to verify
> > that the resources are valid and not corrupted. We usually do it by
> > comparing the resource size with some predefined value, that we expect
> > to see.
> 
> >>>  Is it really
> >>> that bad that the config space size changed?  Why it has this effect?
> 
> > Because in this case it's hard to distinguish between resource's
> > corruption and HW update.
> 
> In theory, would the following approach work?
> 
> (1) insist on revision-id being 0,
> 
> (2) only require a minimum size of VIRTIO_PCI_CONFIG_NOMSI == 20 bytes
> from the iomem BAR (= common virtio header, guaranteed by the virtio
> spec for revision-id==0) when loading the driver,
> 
> (3) at first, only map this initial (guaranteed) part of the resource,
> 
> (4) this should provide access to the feature bits, allowing
> verification of the full BAR size, including MSI-X fields and device
> type specific fields,
> 
> (5a) remap the BAR with full size if there's a match,
I would try avoiding any remapping in virtio block and scsi drivers,
especially when they are operating in system installation, crash dump
and hibernation modes.
Best regards,
Vadim. 
> (5b) if there's a mismatch, set "permanent hardware failure" or some
> such in the loaded drier.
> 
> It would be probably overkill; I'm just wondering if it made sense in
> theory.
> 
> Thanks
> Laszlo

Re: [Qemu-devel] Headsup: windows virtio networking does not work on current git

[Vadim Rozenfeld]

On Thu, 2013-02-07 at 13:33 +0200, Michael S. Tsirkin wrote:
> On Thu, Feb 07, 2013 at 09:53:39PM +1100, Vadim Rozenfeld wrote:
> > On Thu, 2013-02-07 at 12:18 +0200, Michael S. Tsirkin wrote:
> > > On Thu, Feb 07, 2013 at 08:24:10PM +1100, Vadim Rozenfeld wrote:
> > > > On Thu, 2013-02-07 at 11:33 +1030, Rusty Russell wrote:
> > > > > Vadim Rozenfeld  writes:
> > > > > > On Tue, 2013-02-05 at 13:58 +0200, Michael S. Tsirkin wrote:
> > > > > >> On Tue, Feb 05, 2013 at 03:45:38PM +0400, Michael Tokarev wrote:
> > > > > >>  Is it really
> > > > > >> > that bad that the config space size changed?  Why it has this 
> > > > > >> > effect?
> > > > > > Because in this case it's hard to distinguish between resource's
> > > > > > corruption and HW update.
> > > > > 
> > > > > But it's also true that if we'd incremented revid you'd have the same
> > > > > failure in this case, right?
> > > > 
> > > > It depends. If we have explicitly specified revision id in inf file and
> > > > this id doesn't mach the new revision id, Windows will not try to load
> > > > the "incompatible" driver, and finish up with "device driver not found"
> > > > dialog.
> > > > 
> > > > Best regards,
> > > > Vadim.
> > > >   
> > > > > 
> > > > > Cheers,
> > > > > Rusty.
> > > 
> > > Well that's all in theory, in practice it does not look like revision ID
> > > is specified in the NetKVM inf so this won't work?
> > > 
> > > From what I see this inf specifies:
> > > 
> > > NetKVM/wlh/netkvm.inf:%kvmnet6.DeviceDesc%= kvmnet6.ndi, 
> > > PCI\VEN_1AF4&DEV_1000&SUBSYS_00011AF4
> > > NetKVM/wxp/netkvm.inf:%kvmnet5.DeviceDesc%= kvmnet5.ndi, 
> > > PCI\VEN_1AF4&DEV_1000&SUBSYS_00011AF4
> > > NetKVM/wxp/netkvm2k.inf:%kvmnet5.DeviceDesc%= kvmnet5.ndi, 
> > > PCI\VEN_1AF4&DEV_1000&SUBSYS_00011AF4
> > > 
> > > So we can tweak any of vendor device and subsystem id.
> > > 
> > Unfortunately, it won't. Only balloon has revision id, specified as a
> > part of device HW descriptor. But it's only because virtio doesn't use 
> > revision ids. Otherwise it differential will be there. 
> 
> So your driver will load and attempt to work on rev=2 devices?

All virtio-win drivers (net, serial, block, and scsi), except for
balloon will.
 
> If yes it's a bug.  virtio spec specifies revision id as an ABI version.
> Linux driver does:
> 
> if (pci_dev->revision != VIRTIO_PCI_ABI_VERSION) {
> printk(KERN_ERR "virtio_pci: expected ABI version %d, got 
> %d\n",
>VIRTIO_PCI_ABI_VERSION, pci_dev->revision);
> return -ENODEV;
> }
> 
> 
> > > 
> > > Changing subsystem vendor ID actually will be completely
> > > transparent to linux which for some reason looks at the
> > > subsystem device ID (why? no idea) but not the subsystem vendor ID.
> > > Of course this requires a valid vendor ID, getting this
> > > costs $3000 I think.
> > > We could tweak device ID too but that might break some other guests
> > > which don't copy the crazy 'replace device id with subsystem device id'
> > > logic from Linux.
> > > 
> > 
> 
> Apropos, would you guys like to start to copy your patches to
> virtualizat...@lists.linux-foundation.org?
> If you do, you might get some review and feedback, allowing
> us to catch such forward compatibility issues earlier.
> 
> Of course it's your project so entirely up to you.
> 
> 

Re: [Qemu-devel] Headsup: windows virtio networking does not work on current git

[Vadim Rozenfeld]

On Thu, 2013-02-07 at 12:18 +0200, Michael S. Tsirkin wrote:
> On Thu, Feb 07, 2013 at 08:24:10PM +1100, Vadim Rozenfeld wrote:
> > On Thu, 2013-02-07 at 11:33 +1030, Rusty Russell wrote:
> > > Vadim Rozenfeld  writes:
> > > > On Tue, 2013-02-05 at 13:58 +0200, Michael S. Tsirkin wrote:
> > > >> On Tue, Feb 05, 2013 at 03:45:38PM +0400, Michael Tokarev wrote:
> > > >>  Is it really
> > > >> > that bad that the config space size changed?  Why it has this effect?
> > > > Because in this case it's hard to distinguish between resource's
> > > > corruption and HW update.
> > > 
> > > But it's also true that if we'd incremented revid you'd have the same
> > > failure in this case, right?
> > 
> > It depends. If we have explicitly specified revision id in inf file and
> > this id doesn't mach the new revision id, Windows will not try to load
> > the "incompatible" driver, and finish up with "device driver not found"
> > dialog.
> > 
> > Best regards,
> > Vadim.
> >   
> > > 
> > > Cheers,
> > > Rusty.
> 
> Well that's all in theory, in practice it does not look like revision ID
> is specified in the NetKVM inf so this won't work?
> 
> From what I see this inf specifies:
> 
> NetKVM/wlh/netkvm.inf:%kvmnet6.DeviceDesc%= kvmnet6.ndi, 
> PCI\VEN_1AF4&DEV_1000&SUBSYS_00011AF4
> NetKVM/wxp/netkvm.inf:%kvmnet5.DeviceDesc%= kvmnet5.ndi, 
> PCI\VEN_1AF4&DEV_1000&SUBSYS_00011AF4
> NetKVM/wxp/netkvm2k.inf:%kvmnet5.DeviceDesc%= kvmnet5.ndi, 
> PCI\VEN_1AF4&DEV_1000&SUBSYS_00011AF4
> 
> So we can tweak any of vendor device and subsystem id.
> 
Unfortunately, it won't. Only balloon has revision id, specified as a
part of device HW descriptor. But it's only because virtio doesn't use 
revision ids. Otherwise it differential will be there. 
> 
> Changing subsystem vendor ID actually will be completely
> transparent to linux which for some reason looks at the
> subsystem device ID (why? no idea) but not the subsystem vendor ID.
> Of course this requires a valid vendor ID, getting this
> costs $3000 I think.
> We could tweak device ID too but that might break some other guests
> which don't copy the crazy 'replace device id with subsystem device id'
> logic from Linux.
> 

Re: [Qemu-devel] Headsup: windows virtio networking does not work on current git

[Vadim Rozenfeld]

On Thu, 2013-02-07 at 11:33 +1030, Rusty Russell wrote:
> Vadim Rozenfeld  writes:
> > On Tue, 2013-02-05 at 13:58 +0200, Michael S. Tsirkin wrote:
> >> On Tue, Feb 05, 2013 at 03:45:38PM +0400, Michael Tokarev wrote:
> >>  Is it really
> >> > that bad that the config space size changed?  Why it has this effect?
> > Because in this case it's hard to distinguish between resource's
> > corruption and HW update.
> 
> But it's also true that if we'd incremented revid you'd have the same
> failure in this case, right?

It depends. If we have explicitly specified revision id in inf file and
this id doesn't mach the new revision id, Windows will not try to load
the "incompatible" driver, and finish up with "device driver not found"
dialog.

Best regards,
Vadim.
  
> 
> Cheers,
> Rusty.

Re: [Qemu-devel] Headsup: windows virtio networking does not work on current git

[Vadim Rozenfeld]

On Tue, 2013-02-05 at 13:58 +0200, Michael S. Tsirkin wrote:
> On Tue, Feb 05, 2013 at 03:45:38PM +0400, Michael Tokarev wrote:
> > 05.02.2013 15:31, Vadim Rozenfeld wrote:
> > >On Mon, 2013-02-04 at 08:41 -0600, Anthony Liguori wrote:
> > >>Vadim Rozenfeld  writes:
> > 
> > >>>http://msdn.microsoft.com/en-us/library/windows/hardware/gg463287.aspx
> > >>
> > >>That's a useful link, thanks.
> > >>
> > >>I don't see anything in that link that would strictly require us to
> > >>change the revision ID.  It seems to focus on when the "software
> > >>interface changes".  I take that to mean, "change the revision ID if an
> > >>old driver wouldn't work anymore" which makes complete sense.
> > >Right, nobody can force you to change the revision id. It's just a good
> > >engineering practice to increase RevID every time the HW interface has
> > >changed, and you expect some compatibility issue between the new HW and
> > >old drivers. In this case, if Windows cannot locate the INF file which
> > >matches the new device identification strings, it just reports that it
> > >cannot find a suitable driver.
> > >>
> > >>But adding feature bits an altering the config size doesn't constitute a
> > >>change in the software interface IMHO.
> > >
> > >I agree, feature bits are good. The only one problem with them, is that
> > >driver usually doesn't have access to PCI space during the driver
> > >loading phase.
> > 
> > Vadim, can you please describe in a bit more details what the actual issue
> > here is, from the windows or windows driver point of view? 
If a driver receives descriptor with memory type resources it needs to
map physical address to logical. This process requires the number of
bytes to be mapped, and it is the best place for sanity check to verify
that the resources are valid and not corrupted. We usually do it by
comparing the resource size with some predefined value, that we expect
to see.
>  Is it really
> > that bad that the config space size changed?  Why it has this effect?
Because in this case it's hard to distinguish between resource's
corruption and HW update.
> > Is this size specified in the inf file somehow?  Just for us to actually
> > understand the issue?
No, it is not specified in INF. We usually keep it hard-coded, but
technically it can be specified in INF and the Registry.  

Best regards,
Vadim.
> > 
> > Thanks!
> > 
> > /mjt
> 
> This should be educational:
> https://github.com/YanVugenfirer/kvm-guest-drivers-windows/commit/10413d2bbef295cc0e0e75131147793ccc382155
> 

Re: [Qemu-devel] Headsup: windows virtio networking does not work on current git

[Vadim Rozenfeld]

On Mon, 2013-02-04 at 08:41 -0600, Anthony Liguori wrote:
> Vadim Rozenfeld  writes:
> 
> > On Mon, 2013-02-04 at 14:22 +0200, Michael S. Tsirkin wrote:
> >> On Mon, Feb 04, 2013 at 02:00:46PM +0200, Yan Vugenfirer wrote:
> >> > 
> >> virtio spec is very explicit that revision never changes:
> >> "The device must also have a Revision ID of 0 to match this
> >> specification."
> >
> > With all my respect to the virtio spec, let me point that Windows lives
> > by different rules:
> > http://msdn.microsoft.com/en-us/library/windows/hardware/gg463287.aspx
> 
> That's a useful link, thanks.
> 
> I don't see anything in that link that would strictly require us to
> change the revision ID.  It seems to focus on when the "software
> interface changes".  I take that to mean, "change the revision ID if an
> old driver wouldn't work anymore" which makes complete sense.
Right, nobody can force you to change the revision id. It's just a good
engineering practice to increase RevID every time the HW interface has
changed, and you expect some compatibility issue between the new HW and
old drivers. In this case, if Windows cannot locate the INF file which
matches the new device identification strings, it just reports that it
cannot find a suitable driver.  
> 
> But adding feature bits an altering the config size doesn't constitute a
> change in the software interface IMHO.

I agree, feature bits are good. The only one problem with them, is that
driver usually doesn't have access to PCI space during the driver
loading phase.
Best regards,
Vadim.
 
> 
> Regards,
> 
> Anthony Liguori
> 
> >
> >
> >> It also explicitly documents the use of feature bits for
> >> adding new fields:
> >> 
> >> "In particular, new fields in the device configuration header are
> >> indicated by offering a feature bit, so the guest can check before
> >> accessing that part of the configuration space.
> >> 
> >> This allows for forwards and backwards compatibility: if the device is
> >> enhanced with a new feature bit, older guests will not write that
> >> feature bit back to the Guest Features field and it can go into
> >> backwards compatibility mode. Similarly, if a guest is enhanced with a
> >> feature that the device doesn't support, it will not see that feature
> >> bit in the Device Features field and can go into backwards compatibility
> >> mode (or, for poor implementations, set the FAILED Device Status bit).
> >> "
> >> 
> >> I really don't see how this can be interpreted except as a
> >> promise to add fields and a requirement for guest drivers
> >> to be forward compatible.
> >> 
> >> > > It really can be very useful, at
> >> > > least for virtio Windows drivers.
> >> > > BTW, Yan already fixed this problem in the Windows driver code. So we
> >> > > can make a new build and make it public. But it probably will not be
> >> > > WHQL'ed in the nearest future.
> >> > > 
> >> > >> authoritative, we've had a lot of issues like this and being able to
> >> > >> make work arounds conditional on the driver identification string 
> >> > >> would
> >> > >> be nice.
> >> > >> 
> >> > >> Regards,
> >> > >> 
> >> > >> Anthony Liguori
> >> > >> 
> >> > >>> 
> >> > >>> How difficult it is to fix it in win driver?
> >> > >>> 
> >> > >>> Thanks,
> >> > >>> 
> >> > >>> /mjt
> >> > > 
> >> > > 

Re: [Qemu-devel] Headsup: windows virtio networking does not work on current git

[Vadim Rozenfeld]

On Mon, 2013-02-04 at 14:22 +0200, Michael S. Tsirkin wrote:
> On Mon, Feb 04, 2013 at 02:00:46PM +0200, Yan Vugenfirer wrote:
> > 
> > On Feb 4, 2013, at 1:30 AM, Vadim Rozenfeld wrote:
> > 
> > > On Sun, 2013-02-03 at 15:09 -0600, Anthony Liguori wrote:
> > >> Michael Tokarev  writes:
> > >> 
> > >>> 03.02.2013 17:23, Yan Vugenfirer wrote:
> > >>> 
> > >>>>> If it helps, mq changes the config size from 8 to 16 bytes.  If the
> > >>>>> driver was making an assumption about an 8-byte config size, that's
> > >>>>> likely what the problem is.
> > >>>>> 
> > >>>> That's exactly the problem.
> > >>> 
> > >>> So what do we do?  It isn't nice to break existing setups.
> > >>> Maybe mq can be disabled by default (together with Antony's
> > >>> patch) until fixed drivers will be more widely available?
> > >> 
> > >> I've got a patch that does exactly like this.  It's pretty ugly though
> > >> because of the relationship between virtio-pci and virtio-net.  I'm
> > >> going to try to see if I can find a cleaner way to do it on Monday.
> > >> 
> > >> I'm also contemplating just disabling mq by default.  Since a special
> > >> command line is needed to enable it anyway (on the backend), having to
> > >> specify mq=on for the device doesn't seem so bad.
> > >> 
> > >> But yeah, we don't want Windows guests to break with -M pc by default so
> > >> we should do something to work around it.
> > >> 
> > >> N.B. this is a pretty nasty bug in the guest driver.  Any new virtio-net
> > >> feature is going to trigger it (not just multiqueue).  So while pc-1.3
> > >> will work forever with this guest image, it's pretty much guaranteed to
> > >> break at some point in the future.
> > >> 
> > >>> It's easy to turn off mq by default and turn it on when
> > >>> needed...
> > >>> 
> > >>> The problem now is that it isn't obvious why your existing
> > >>> setup breaks when you upgrade.  While when you especially
> > >>> play with mq, you may look at options available around it...
> > >> 
> > >> If we ever to get virtio2, a really handy feature to have would be a
> > >> driver identification string.  Even if was only informative (and not
> > > 
> > > Why not just use revision id for that?
> > 
> > That's what would be expected from real HW if size of the BAR is changed.
> 
> virtio spec is very explicit that revision never changes:
> "The device must also have a Revision ID of 0 to match this
> specification."

With all my respect to the virtio spec, let me point that Windows lives
by different rules:
http://msdn.microsoft.com/en-us/library/windows/hardware/gg463287.aspx


> It also explicitly documents the use of feature bits for
> adding new fields:
> 
> "In particular, new fields in the device configuration header are
> indicated by offering a feature bit, so the guest can check before
> accessing that part of the configuration space.
> 
> This allows for forwards and backwards compatibility: if the device is
> enhanced with a new feature bit, older guests will not write that
> feature bit back to the Guest Features field and it can go into
> backwards compatibility mode. Similarly, if a guest is enhanced with a
> feature that the device doesn't support, it will not see that feature
> bit in the Device Features field and can go into backwards compatibility
> mode (or, for poor implementations, set the FAILED Device Status bit).
> "
> 
> I really don't see how this can be interpreted except as a
> promise to add fields and a requirement for guest drivers
> to be forward compatible.
> 
> > > It really can be very useful, at
> > > least for virtio Windows drivers.
> > > BTW, Yan already fixed this problem in the Windows driver code. So we
> > > can make a new build and make it public. But it probably will not be
> > > WHQL'ed in the nearest future.
> > > 
> > >> authoritative, we've had a lot of issues like this and being able to
> > >> make work arounds conditional on the driver identification string would
> > >> be nice.
> > >> 
> > >> Regards,
> > >> 
> > >> Anthony Liguori
> > >> 
> > >>> 
> > >>> How difficult it is to fix it in win driver?
> > >>> 
> > >>> Thanks,
> > >>> 
> > >>> /mjt
> > > 
> > > 

Re: [Qemu-devel] Headsup: windows virtio networking does not work on current git

[Vadim Rozenfeld]

On Sun, 2013-02-03 at 15:09 -0600, Anthony Liguori wrote:
> Michael Tokarev  writes:
> 
> > 03.02.2013 17:23, Yan Vugenfirer wrote:
> >
> >>> If it helps, mq changes the config size from 8 to 16 bytes.  If the
> >>> driver was making an assumption about an 8-byte config size, that's
> >>> likely what the problem is.
> >>>
> >> That's exactly the problem.
> >
> > So what do we do?  It isn't nice to break existing setups.
> > Maybe mq can be disabled by default (together with Antony's
> > patch) until fixed drivers will be more widely available?
> 
> I've got a patch that does exactly like this.  It's pretty ugly though
> because of the relationship between virtio-pci and virtio-net.  I'm
> going to try to see if I can find a cleaner way to do it on Monday.
> 
> I'm also contemplating just disabling mq by default.  Since a special
> command line is needed to enable it anyway (on the backend), having to
> specify mq=on for the device doesn't seem so bad.
> 
> But yeah, we don't want Windows guests to break with -M pc by default so
> we should do something to work around it.
> 
> N.B. this is a pretty nasty bug in the guest driver.  Any new virtio-net
> feature is going to trigger it (not just multiqueue).  So while pc-1.3
> will work forever with this guest image, it's pretty much guaranteed to
> break at some point in the future.
> 
> > It's easy to turn off mq by default and turn it on when
> > needed...
> >
> > The problem now is that it isn't obvious why your existing
> > setup breaks when you upgrade.  While when you especially
> > play with mq, you may look at options available around it...
> 
> If we ever to get virtio2, a really handy feature to have would be a
> driver identification string.  Even if was only informative (and not

Why not just use revision id for that? It really can be very useful, at
least for virtio Windows drivers.
BTW, Yan already fixed this problem in the Windows driver code. So we
can make a new build and make it public. But it probably will not be
WHQL'ed in the nearest future.
 
> authoritative, we've had a lot of issues like this and being able to
> make work arounds conditional on the driver identification string would
> be nice.
> 
> Regards,
> 
> Anthony Liguori
> 
> >
> > How difficult it is to fix it in win driver?
> >
> > Thanks,
> >
> > /mjt

Re: [Qemu-devel] Headsup: windows virtio networking does not work on current git

[Vadim Rozenfeld]

On Sat, 2013-02-02 at 20:42 +0800, Jason Wang wrote:
> On 02/02/2013 05:13 AM, Anthony Liguori wrote:
> > Michael Tokarev  writes:
> >
> >> 02.02.2013 00:36, Anthony Liguori wrote:
> >>> Michael Tokarev  writes:
> >>>
>  02.02.2013 00:18, Michael Tokarev wrote:
> > Just a heads-up for now, no real diagnostics or anything like that.
> >
> > Current git master (a9c87c586ba9ee290792a98dc126b2861b7f8b03), when 
> > booted
> > a windows guest, results in no virtio-net inside.  Neither winXP nor 
> > Win7,
> > neither older nor latest (22 Jan 2013) virtio-net drivers works.
> >
> > Windows displays a yellow exclamation mark near the virtio-net device 
> > and
> > says it can't start the device (Code 10).
> >
> > Linux guests work fine, quick test anyway.
> >
> > Cc'ing Jason since his virtio-net changes was last.  But I repeat: no
> > diagnostics as of yet, no bisection.
>  Bisection was easy, since win works fine right before the multiqueue
>  virtio-net series.  This is the first bad commit:
> >>> Adding Vadim and Michael.
> >>>
> >>> If you use -M pc-1.3 or explicitly disable multiqueue, does the driver 
> >>> work?
> >> Neither one of these nor both makes any visible difference.
> >> Neither does -M pc-1.1 (just in case).
> > Hrm, then it's very likely not a driver problem.  Thanks.
> >
> > Regards,
> >
> > Anthony Liguori
> 
> Have a look at this issue. It was caused by multiqueue patch who adds a
> new field to virtio_net_cfg. Not sure multiqueue is the root cause since
> I also find even w/o multiqueue, adding any new field to virtio_net_cfg
> will break windows guest. Haven't had a clue on this, will continue
> investigate.

cc'ing Yan, our NDIS guy.
Thank you,
Vadim.
> >
> >>> Regards,
> >>>
> >>> Anthony Liguori
> >>>
>  commit fed699f9ca6ae8a0fb62803334cf46fa64d1eb91
>  Author: Jason Wang 
>  Date:   Wed Jan 30 19:12:39 2013 +0800
> 
>    virtio-net: multiqueue support
> 
>    This patch implements both userspace and vhost support for 
>  multiple queue
>    virtio-net (VIRTIO_NET_F_MQ). This is done by introducing an array 
>  of
>    VirtIONetQueue to VirtIONet.
> 
>    Signed-off-by: Jason Wang 
>    Signed-off-by: Anthony Liguori 
> 
>  After this commit, win guest (winXP and win7) shows yellow
>  exclamation sign and is unable to start the device with
>  code 10.
> 
>  FWIW.  I'm not sure it is a good idea to make a release with
>  such a breakage, even rc0.
> 
>  Thanks,
> 
>  /mjt
> >
> 

Re: [Qemu-devel] [PATCH] dataplane: support viostor virtio-pci status bit setting

[Vadim Rozenfeld]

On Friday, January 18, 2013 05:59:37 PM Stefan Hajnoczi wrote:
> On Thu, Jan 17, 2013 at 04:46:54PM +0100, Stefan Hajnoczi wrote:
> > The viostor virtio-blk driver for Windows does not use the
> > VIRTIO_CONFIG_S_DRIVER bit.  It only sets the VIRTIO_CONFIG_S_DRIVER_OK
> > bit.
Will be added in the next build.
Thank you,
Vadim.
> > 
> > The viostor driver refreshes the virtio-pci status byte sometimes while
> > the guest is running.  We misinterpret 0x4 (VIRTIO_CONFIG_S_DRIVER_OK)
> > as an indication that virtio-blk-data-plane should be stopped since 0x2
> > (VIRTIO_CONFIG_S_DRIVER) is missing.  The result is that the device
> > becomes unresponsive.
> > 
> > Signed-off-by: Stefan Hajnoczi 
> > ---
> > 
> >  hw/virtio-blk.c | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> Applied to my block tree:
> https://github.com/stefanha/qemu/commits/block
> 
> Stefan

Re: [Qemu-devel] Windows and I/O size

[Vadim Rozenfeld]

On Tuesday, January 08, 2013 12:09:11 PM Peter Lieven wrote:
> Am 08.01.2013 um 10:29 schrieb Vadim Rozenfeld :
> > On Tuesday, January 08, 2013 10:53:44 AM Peter Lieven wrote:
> >> Am 08.01.2013 um 09:50 schrieb Vadim Rozenfeld :
> >>> On Tuesday, January 08, 2013 10:16:48 AM Peter Lieven wrote:
> >>>> Hi all,
> >>>> 
> >>>> I came across the fact that Windows seems to requests greater 64KB
> >>>> into pieces leading to a lot of IOPs on the storage side.
> >>>> 
> >>>> Can anyone imagine of a way to merge them before sending them to e.g.
> >>>> an iSCSI Storage? 64KB I/O Size is not optimal when e.g. large
> >>>> sequential operations with an iSCSI target.
> >>>> 
> >>>> Thank you,
> >>>> Peter
> >>> 
> >>> Hi Peter.
> >>> Is it viostor? Which version? The most recent one is able to handle
> >>> 256K blocks.
> >> 
> >> Not the recent. I will try 0.1.49 now.
> >> 
> >> 256KB is still not that much but definitely better than 64KB. are this
> >> windows limits?
> > 
> > not exactly. it came from the driver itself. actually, with indirect
> > buffer support in virtio the sky is the limit.
> 
> is indirect buffering supported on all windows platforms?
yes.
btw, forgot to mention that vioscsi doesn't have this feature yet. 
> 
> Peter
> 
> >> I have found docs in the net that windows splits up everything into 64kB
> >> requests. Is this info old?
> >> 
> >> thank you,
> >> Peter
> >> 
> >>> Best regards,
> >>> Vadim.

Re: [Qemu-devel] Windows and I/O size

[Vadim Rozenfeld]

On Tuesday, January 08, 2013 11:47:54 AM Peter Lieven wrote:
> Am 08.01.2013 um 10:29 schrieb Vadim Rozenfeld :
> > On Tuesday, January 08, 2013 10:53:44 AM Peter Lieven wrote:
> >> Am 08.01.2013 um 09:50 schrieb Vadim Rozenfeld :
> >>> On Tuesday, January 08, 2013 10:16:48 AM Peter Lieven wrote:
> >>>> Hi all,
> >>>> 
> >>>> I came across the fact that Windows seems to requests greater 64KB
> >>>> into pieces leading to a lot of IOPs on the storage side.
> >>>> 
> >>>> Can anyone imagine of a way to merge them before sending them to e.g.
> >>>> an iSCSI Storage? 64KB I/O Size is not optimal when e.g. large
> >>>> sequential operations with an iSCSI target.
> >>>> 
> >>>> Thank you,
> >>>> Peter
> >>> 
> >>> Hi Peter.
> >>> Is it viostor? Which version? The most recent one is able to handle
> >>> 256K blocks.
> >> 
> >> Not the recent. I will try 0.1.49 now.
> >> 
> >> 256KB is still not that much but definitely better than 64KB. are this
> >> windows limits?
> > 
> > not exactly. it came from the driver itself. actually, with indirect
> > buffer support in virtio the sky is the limit.
> 
> would it be possible to make this value user adjustable in the driver
> settings?
> 
technically, yes. 
> I can meanwhile confirm that the IOPS for sequential reads (writes not
> tested) have dropped to 1/4 as expected.
> 
> I think 256K is a reasonable value. What was the reason to choose it?
In Windows cache manager operates with 256 KB blocks. 
Cheers,
Vadim.
> 
> Thank you,
> Peter
> 
> >> I have found docs in the net that windows splits up everything into 64kB
> >> requests. Is this info old?
> >> 
> >> thank you,
> >> Peter
> >> 
> >>> Best regards,
> >>> Vadim.

Re: [Qemu-devel] Windows and I/O size

[Vadim Rozenfeld]

On Tuesday, January 08, 2013 10:53:44 AM Peter Lieven wrote:
> Am 08.01.2013 um 09:50 schrieb Vadim Rozenfeld :
> > On Tuesday, January 08, 2013 10:16:48 AM Peter Lieven wrote:
> >> Hi all,
> >> 
> >> I came across the fact that Windows seems to requests greater 64KB into
> >> pieces leading to a lot of IOPs on the storage side.
> >> 
> >> Can anyone imagine of a way to merge them before sending them to e.g. an
> >> iSCSI Storage? 64KB I/O Size is not optimal when e.g. large sequential
> >> operations with an iSCSI target.
> >> 
> >> Thank you,
> >> Peter
> > 
> > Hi Peter.
> > Is it viostor? Which version? The most recent one is able to handle 256K
> > blocks.
> 
> Not the recent. I will try 0.1.49 now.
> 
> 256KB is still not that much but definitely better than 64KB. are this
> windows limits?

not exactly. it came from the driver itself. actually, with indirect buffer 
support in virtio the sky is the limit.  

> 
> I have found docs in the net that windows splits up everything into 64kB
> requests. Is this info old?
> 
> thank you,
> Peter
> 
> > Best regards,
> > Vadim.

Re: [Qemu-devel] Windows and I/O size

[Vadim Rozenfeld]

On Tuesday, January 08, 2013 10:16:48 AM Peter Lieven wrote:
> Hi all,
> 
> I came across the fact that Windows seems to requests greater 64KB into
> pieces leading to a lot of IOPs on the storage side.
> 
> Can anyone imagine of a way to merge them before sending them to e.g. an
> iSCSI Storage? 64KB I/O Size is not optimal when e.g. large sequential
> operations with an iSCSI target.
> 
> Thank you,
> Peter
Hi Peter.
Is it viostor? Which version? The most recent one is able to handle 256K 
blocks.

Best regards,
Vadim.

Re: [Qemu-devel] [Bug 990364] [NEW] virtio_ioport_write: unexpected address 0x13 value 0x1

[Vadim Rozenfeld]

On Monday, April 30, 2012 07:17:09 PM Vadim Rozenfeld wrote:
> On Monday, April 30, 2012 03:31:03 PM Stefan Hajnoczi wrote:
> > Hi Vadim,
> > Here is a recent bug report with virtio-win-0.1-22.iso.  Wanted to
> > bring it to your attention, please let me know if you already monitor
> > these bug emails.
> 
> Hi Stefan,
> Yes, it's on my radar.
> Cheers,
> Vadim.
> 
seems to be ndis related 
(https://bugzilla.redhat.com/show_bug.cgi?id=808654#c10)
cc'ing Yan.

> > Stefan
> > 
> > On Sat, Apr 28, 2012 at 9:49 AM, Vitalis  wrote:
> > > Public bug reported:
> > > 
> > > Hello! I have:
> > > 
> > > virtio_ioport_write: unexpected address 0x13 value 0x1
> > > 
> > > on config:
> > > 
> > > LC_ALL=C
> > > PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/sbin:/sbin:/bin
> > > QEMU_AUDIO_DRV=none /usr/bin/kvm -S -M pc-0.12 -cpu qemu32 -enable-kvm
> > > -m 3072 -smp 1 -name nata_xp -uuid da607499-1d8f-e7ef-d1d2-38
> > > 1c1839e4ba -chardev
> > > socket,id=monitor,path=/var/lib/libvirt/qemu/nata_xp.monitor,server,now
> > > a it -monitor chardev:monitor -localtime -boot c -drive
> > > file=/root/nata_xp.qcow2,if=virtio,index=0,boot=on,format=raw
> > > ,cache=none -drive
> > > file=/home/admino/virtio-win-0.1-22.iso,if=ide,media=cdrom,index=2,form
> > > a t=raw -net
> > > nic,macaddr=00:16:36:06:02:69,vlan=0,model=virtio,name=virtio.0 -net
> > > tap,fd=43,vlan=0,name=tap.0 -serial none -parallel none -usb -usbdevice
> > > tablet -vnc 127.0.0.1:3 -k en-us -vga cirrus pci_add_option_rom: failed
> > > to find romfile "pxe-virtio.bin"
> > > 
> > > with kernel 2.6.32-40-generic #87-Ubuntu SMP Tue Mar 6 00:56:56 UTC
> > > 2012 x86_64 GNU/Linux qemu drivers are virtio-win-0.1-22.iso
> > > kvm version 1:84+dfsg-0ubuntu16+0.12.3+noroms+0ubuntu9.18
> > > qemu 0.12.3+noroms-0ubuntu9.18
> > > 
> > > ** Affects: qemu
> > > 
> > > Importance: Undecided
> > > 
> > > Status: New
> > > 
> > > ** Tags: bug kvm virtio
> > > 
> > > --
> > > You received this bug notification because you are a member of qemu-
> > > devel-ml, which is subscribed to QEMU.
> > > https://bugs.launchpad.net/bugs/990364
> > > 
> > > Title:
> > >  virtio_ioport_write: unexpected address 0x13 value 0x1
> > > 
> > > Status in QEMU:
> > >  New
> > > 
> > > Bug description:
> > >  Hello! I have:
> > >  
> > >  virtio_ioport_write: unexpected address 0x13 value 0x1
> > >  
> > >  on config:
> > >  
> > >  LC_ALL=C
> > > 
> > > PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/sbin:/sbin:/bin
> > > QEMU_AUDIO_DRV=none /usr/bin/kvm -S -M pc-0.12 -cpu qemu32 -enable-kvm
> > > -m 3072 -smp 1 -name nata_xp -uuid da607499-1d8f-e7ef-d1d2-38
> > > 1c1839e4ba -chardev
> > > socket,id=monitor,path=/var/lib/libvirt/qemu/nata_xp.monitor,server,now
> > > a it -monitor chardev:monitor -localtime -boot c -drive
> > > file=/root/nata_xp.qcow2,if=virtio,index=0,boot=on,format=raw
> > > ,cache=none -drive
> > > file=/home/admino/virtio-win-0.1-22.iso,if=ide,media=cdrom,index=2,form
> > > a t=raw -net
> > > nic,macaddr=00:16:36:06:02:69,vlan=0,model=virtio,name=virtio.0 -net
> > > tap,fd=43,vlan=0,name=tap.0 -serial none -parallel none -usb -usbdevice
> > > tablet -vnc 127.0.0.1:3 -k en-us -vga cirrus pci_add_option_rom: failed
> > > to find romfile "pxe-virtio.bin"
> > > 
> > >  with kernel 2.6.32-40-generic #87-Ubuntu SMP Tue Mar 6 00:56:56 UTC
> > >  2012
> > > 
> > > x86_64 GNU/Linux qemu drivers are virtio-win-0.1-22.iso
> > > 
> > >  kvm version 1:84+dfsg-0ubuntu16+0.12.3+noroms+0ubuntu9.18
> > >  qemu 0.12.3+noroms-0ubuntu9.18
> > > 
> > > To manage notifications about this bug go to:
> > > https://bugs.launchpad.net/qemu/+bug/990364/+subscriptions

Re: [Qemu-devel] [Bug 990364] [NEW] virtio_ioport_write: unexpected address 0x13 value 0x1

[Vadim Rozenfeld]

On Monday, April 30, 2012 03:31:03 PM Stefan Hajnoczi wrote:
> Hi Vadim,
> Here is a recent bug report with virtio-win-0.1-22.iso.  Wanted to
> bring it to your attention, please let me know if you already monitor
> these bug emails.
Hi Stefan,
Yes, it's on my radar.
Cheers,
Vadim.
> 
> Stefan
> 
> On Sat, Apr 28, 2012 at 9:49 AM, Vitalis  wrote:
> > Public bug reported:
> > 
> > Hello! I have:
> > 
> > virtio_ioport_write: unexpected address 0x13 value 0x1
> > 
> > on config:
> > 
> > LC_ALL=C
> > PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/sbin:/sbin:/bin
> > QEMU_AUDIO_DRV=none /usr/bin/kvm -S -M pc-0.12 -cpu qemu32 -enable-kvm
> > -m 3072 -smp 1 -name nata_xp -uuid da607499-1d8f-e7ef-d1d2-38 1c1839e4ba
> > -chardev
> > socket,id=monitor,path=/var/lib/libvirt/qemu/nata_xp.monitor,server,nowa
> > it -monitor chardev:monitor -localtime -boot c -drive
> > file=/root/nata_xp.qcow2,if=virtio,index=0,boot=on,format=raw
> > ,cache=none -drive
> > file=/home/admino/virtio-win-0.1-22.iso,if=ide,media=cdrom,index=2,forma
> > t=raw -net
> > nic,macaddr=00:16:36:06:02:69,vlan=0,model=virtio,name=virtio.0 -net
> > tap,fd=43,vlan=0,name=tap.0 -serial none -parallel none -usb -usbdevice
> > tablet -vnc 127.0.0.1:3 -k en-us -vga cirrus pci_add_option_rom: failed
> > to find romfile "pxe-virtio.bin"
> > 
> > with kernel 2.6.32-40-generic #87-Ubuntu SMP Tue Mar 6 00:56:56 UTC 2012
> > x86_64 GNU/Linux qemu drivers are virtio-win-0.1-22.iso
> > kvm version 1:84+dfsg-0ubuntu16+0.12.3+noroms+0ubuntu9.18
> > qemu 0.12.3+noroms-0ubuntu9.18
> > 
> > ** Affects: qemu
> > Importance: Undecided
> > Status: New
> > 
> > 
> > ** Tags: bug kvm virtio
> > 
> > --
> > You received this bug notification because you are a member of qemu-
> > devel-ml, which is subscribed to QEMU.
> > https://bugs.launchpad.net/bugs/990364
> > 
> > Title:
> >  virtio_ioport_write: unexpected address 0x13 value 0x1
> > 
> > Status in QEMU:
> >  New
> > 
> > Bug description:
> >  Hello! I have:
> > 
> >  virtio_ioport_write: unexpected address 0x13 value 0x1
> > 
> >  on config:
> > 
> >  LC_ALL=C
> > PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/sbin:/sbin:/bin
> > QEMU_AUDIO_DRV=none /usr/bin/kvm -S -M pc-0.12 -cpu qemu32 -enable-kvm
> > -m 3072 -smp 1 -name nata_xp -uuid da607499-1d8f-e7ef-d1d2-38 1c1839e4ba
> > -chardev
> > socket,id=monitor,path=/var/lib/libvirt/qemu/nata_xp.monitor,server,nowa
> > it -monitor chardev:monitor -localtime -boot c -drive
> > file=/root/nata_xp.qcow2,if=virtio,index=0,boot=on,format=raw
> > ,cache=none -drive
> > file=/home/admino/virtio-win-0.1-22.iso,if=ide,media=cdrom,index=2,forma
> > t=raw -net
> > nic,macaddr=00:16:36:06:02:69,vlan=0,model=virtio,name=virtio.0 -net
> > tap,fd=43,vlan=0,name=tap.0 -serial none -parallel none -usb -usbdevice
> > tablet -vnc 127.0.0.1:3 -k en-us -vga cirrus pci_add_option_rom: failed
> > to find romfile "pxe-virtio.bin"
> > 
> >  with kernel 2.6.32-40-generic #87-Ubuntu SMP Tue Mar 6 00:56:56 UTC 2012
> > x86_64 GNU/Linux qemu drivers are virtio-win-0.1-22.iso
> >  kvm version 1:84+dfsg-0ubuntu16+0.12.3+noroms+0ubuntu9.18
> >  qemu 0.12.3+noroms-0ubuntu9.18
> > 
> > To manage notifications about this bug go to:
> > https://bugs.launchpad.net/qemu/+bug/990364/+subscriptions

Re: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

[Vadim Rozenfeld]

On Monday, April 09, 2012 06:00:59 AM Paul Lu-?R-?l wrote:
> Hi Vadim,
> 
> The driver works properly on my machine. Is it possible send us the source
> code of the driver? We'd like to build it on our environment. Thanks a
> ton.
> 
> BR
> Paul
http://people.redhat.com/vrozenfe/build-25/virtio-win-prewhql-0.1-25-
sources.zip
Vadim.
> -----Original Message-
> From: Vadim Rozenfeld [mailto:vroze...@redhat.com]
> Sent: Monday, April 09, 2012 2:33 AM
> To: Paul Lu-?R-?l
> Cc: Charles.Tsai-??-?l; Michael Roth; Stefan Hajnoczi;
> spice-de...@lists.freedesktop.org; Alex Huang-?S???t-?l; Alon Levy;
> qemu-devel Subject: Re: [Qemu-devel] [Spice-devel] Vioserial of Windows
> guest OS on Qemu 0.15
> 
> On Monday, March 19, 2012 10:31:16 PM Vadim Rozenfeld wrote:
> > On Monday, March 19, 2012 02:48:43 PM Paul Lu-???-? wrote:
> > > Hi Vadim,
> > > Here is the configuration:
> > > /usr/local/bin/qemu-system-x86_64 \
> > > 
> > >  -localtime \
> > >  -boot order=c,menu=on \
> > >  -drive file=/var/lib/libvirt/images/xxx.img \
> > >  -vga qxl \
> > >  -cdrom /home/paul/Downloads/ISO/virtio-win-0.1-15.iso \
> > >  -chardev spicevmc,id=vdagent,name=vdagent \
> > >  -spice port=5930,disable-ticketing \
> > >  -device virtio-serial-pci \
> > >  -device virtserialport,chardev=vdagent,name=com.redhat.spice.0 \
> > >  -smp 1,cores=1 -m 2048 \
> > >  -enable-kvm \
> > >  -usbdevice tablet \
> > >  -net nic -net user \
> > >  -tb-size 0 \
> > >  -qmp tcp:localhost:,nowait,server \
> > >  -D /home/paul/MyQemuLog/xxx/xxx.log \
> > >  -trace events=/home/paul/MyTestCase/xxx/events
> 
> Hi Paul,
> 
> Could you give a try to the latest build, available at
> http://people.redhat.com/vrozenfe/build-25/virtio-win-prewhql-0.1.zip
> 
> > > QEMU Version: qemu-kvm commit 30c044521889195f54a9f2c21310894f545994e8
> > > 
> > > 
> > > I use qmp command, query-pci, to check virtio-serial-pci BAR0. It shows
> > > 0xC140. However, pci_default_read_config in pci.c return 0xC141 to
> > > Guest. We also trace pci_default_wirte_config.
> > > 
> > > At some point, the BAR0 will be overwritten to 0xC141. Here is the
> > > result,
> > > 
> > > virtio_set_status vdev 0x7fbeaba594a0 val 0
> > > virtio_set_status vdev 0x7fbeaba594a0 val 0
> > > qemu-system-x86_64: 10:1,len=4
> > > qemu-system-x86_64: [WRITE]10:, len=4
> > > qemu-system-x86_64: 10:ffe1,len=4
> > > qemu-system-x86_64: [WRITE]10:1, len=4
> > > qemu-system-x86_64: [WRITE]10:c140, len=4
> > > virtio_set_status vdev 0x7fbeaba594a0 val 0
> > > qemu-system-x86_64: 10:c141,len=4
> > > qemu-system-x86_64: 10:c141,len=4
> > > qemu-system-x86_64: 10:c141,len=4
> > > qemu-system-x86_64: 10:c141,len=4
> > > qemu-system-x86_64: 10:c141,len=4
> > > virtio_set_status vdev 0x7fbeaba594a0 val 0
> > > qemu-system-x86_64: 10:c141,len=4
> > > qemu-system-x86_64: [WRITE]10:, len=4
> > > qemu-system-x86_64: 10:ffe1,len=4
> > > qemu-system-x86_64: [WRITE]10:c141, len=4
> > > virtio_set_status vdev 0x7fbeaba594a0 val 0
> > > qemu-system-x86_64: 10:c141,len=4
> > > qemu-system-x86_64: 10:c141,len=4
> > > qemu-system-x86_64: 10:c141,len=4
> > > qemu-system-x86_64: 10:c141,len=4
> > > 
> > > I think the following code in pci_default_wirte_config cause the
> > > problem,
> > > 
> > >for (i = 0; i < l; val >>= 8, ++i) {
> > >
> > > uint8_t wmask = d->wmask[addr + i];
> > > uint8_t w1cmask = d->w1cmask[addr + i];
> > > assert(!(wmask & w1cmask));
> > > d->config[addr + i] = (d->config[addr + i] & ~wmask) | (val &
> > > 
> > > wmask); d->config[addr + i] &= ~(val & w1cmask); /* W1C: Write 1 to
> > > Clear */ }
> > > 
> > > Could you elaborate it for us?
> > 
> > Hi Paul,
> > Give me a couple of days.
> > Best,
> > Vadim.
> > 
> > > Best Regards,
> > > Paul
> > > 
> > > -Original Message-
> > > From: Charles.Tsai-???-?
> > > Sent: Mon 3/19/2012 8:32 PM
> > > To: Vadim Rozenfeld
> > > Cc: Michael Roth; Stefan Hajnoczi; spice-de...@lists.freedesktop.org;
> > > Alex Huang-???-?; Alon Levy; qemu-devel; Paul Lu-???-? Subject:
> &g

Re: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

[Vadim Rozenfeld]

On Monday, March 19, 2012 10:31:16 PM Vadim Rozenfeld wrote:
> On Monday, March 19, 2012 02:48:43 PM Paul Lu-???-? wrote:
> > Hi Vadim,
> > Here is the configuration:
> > /usr/local/bin/qemu-system-x86_64 \
> > 
> >  -localtime \
> >  -boot order=c,menu=on \
> >  -drive file=/var/lib/libvirt/images/xxx.img \
> >  -vga qxl \
> >  -cdrom /home/paul/Downloads/ISO/virtio-win-0.1-15.iso \
> >  -chardev spicevmc,id=vdagent,name=vdagent \
> >  -spice port=5930,disable-ticketing \
> >  -device virtio-serial-pci \
> >  -device virtserialport,chardev=vdagent,name=com.redhat.spice.0 \
> >  -smp 1,cores=1 -m 2048 \
> >  -enable-kvm \
> >  -usbdevice tablet \
> >  -net nic -net user \
> >  -tb-size 0 \
> >  -qmp tcp:localhost:,nowait,server \
> >  -D /home/paul/MyQemuLog/xxx/xxx.log \
> >  -trace events=/home/paul/MyTestCase/xxx/events
> > 
Hi Paul,

Could you give a try to the latest build, available at 
http://people.redhat.com/vrozenfe/build-25/virtio-win-prewhql-0.1.zip
 
> > QEMU Version: qemu-kvm commit 30c044521889195f54a9f2c21310894f545994e8
> > 
> > 
> > I use qmp command, query-pci, to check virtio-serial-pci BAR0. It shows
> > 0xC140. However, pci_default_read_config in pci.c return 0xC141 to Guest.
> > We also trace pci_default_wirte_config.
> > 
> > At some point, the BAR0 will be overwritten to 0xC141. Here is the
> > result,
> > 
> > virtio_set_status vdev 0x7fbeaba594a0 val 0
> > virtio_set_status vdev 0x7fbeaba594a0 val 0
> > qemu-system-x86_64: 10:1,len=4
> > qemu-system-x86_64: [WRITE]10:, len=4
> > qemu-system-x86_64: 10:ffe1,len=4
> > qemu-system-x86_64: [WRITE]10:1, len=4
> > qemu-system-x86_64: [WRITE]10:c140, len=4
> > virtio_set_status vdev 0x7fbeaba594a0 val 0
> > qemu-system-x86_64: 10:c141,len=4
> > qemu-system-x86_64: 10:c141,len=4
> > qemu-system-x86_64: 10:c141,len=4
> > qemu-system-x86_64: 10:c141,len=4
> > qemu-system-x86_64: 10:c141,len=4
> > virtio_set_status vdev 0x7fbeaba594a0 val 0
> > qemu-system-x86_64: 10:c141,len=4
> > qemu-system-x86_64: [WRITE]10:, len=4
> > qemu-system-x86_64: 10:ffe1,len=4
> > qemu-system-x86_64: [WRITE]10:c141, len=4
> > virtio_set_status vdev 0x7fbeaba594a0 val 0
> > qemu-system-x86_64: 10:c141,len=4
> > qemu-system-x86_64: 10:c141,len=4
> > qemu-system-x86_64: 10:c141,len=4
> > qemu-system-x86_64: 10:c141,len=4
> > 
> > I think the following code in pci_default_wirte_config cause the problem,
> > 
> >for (i = 0; i < l; val >>= 8, ++i) {
> >
> > uint8_t wmask = d->wmask[addr + i];
> > uint8_t w1cmask = d->w1cmask[addr + i];
> > assert(!(wmask & w1cmask));
> > d->config[addr + i] = (d->config[addr + i] & ~wmask) | (val &
> > 
> > wmask); d->config[addr + i] &= ~(val & w1cmask); /* W1C: Write 1 to Clear
> > */ }
> > 
> > Could you elaborate it for us?
> 
> Hi Paul,
> Give me a couple of days.
> Best,
> Vadim.
> 
> > Best Regards,
> > Paul
> > 
> > -Original Message-
> > From: Charles.Tsai-???-?
> > Sent: Mon 3/19/2012 8:32 PM
> > To: Vadim Rozenfeld
> > Cc: Michael Roth; Stefan Hajnoczi; spice-de...@lists.freedesktop.org;
> > Alex Huang-???-?; Alon Levy; qemu-devel; Paul Lu-???-? Subject:
> > RE: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu
> > 0.15
> > 
> > Vadim,
> > 
> > My colleague will give you more  information we found here.
> > Qemu somehow in this particular case returns a wrong bar0 value.
> > In working case, the bar0 is 0xc140. But in failure case, the bar0 is
> > changed to 0xC141.
> > 
> > 
> > 
> > -Original Message-
> > From: Vadim Rozenfeld [mailto:vroze...@redhat.com]
> > Sent: Monday, March 19, 2012 8:03 PM
> > To: Charles.Tsai-???-?
> > Cc: Michael Roth; Stefan Hajnoczi; spice-de...@lists.freedesktop.org;
> > Alex Huang-???-?; Alon Levy; qemu-devel; Paul Lu-???-? Subject:
> > Re: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu
> > 0.15
> > 
> > On Monday, March 19, 2012 01:16:56 PM Charles.Tsai-???-? wrote:
> > > Vadim,
> > > 
> > > What do you mean "qemu configuration string"? Is it the build
> > > configuration or command line option? Please let me know it. Thanks.
> > 
> > Sorry, that was ambiguous.
> > I need the command line in order to reproduce the problem.
> &

Re: [Qemu-devel] Windows Virtio Issue

[Vadim Rozenfeld]

On Monday, March 26, 2012 05:51:37 PM Vadim Rozenfeld wrote:
> On Monday, March 26, 2012 02:45:34 PM Paul Fisher wrote:
> > On 26 March 2012 09:50, Vadim Rozenfeld  wrote:
> > > On Sunday, March 25, 2012 07:01:54 PM Yan Vugenfirer wrote:
> > > Hi Paul,
> > > Could you try reproducing this problem on "-smp 2" guest, with
> > > small memory dump option turned on, instead of kernel memory dump.
> > > 
> > > Thanks,
> > > Vadim.
> > 
> > Hi Vadim.
> > 
> > Thank you kindly for getting back to me.
> > 
> > I can certainly do that:
> > 
> > Dump and BSOD are in a zip at
> > http://dl.dropbox.com/u/12332019/2200-VirtioBSOD-2.zip
> > 
> > This time running with 2 cores:
> > 
> > qemu-kvm -m 1024 -smp sockets=1,cores=2 -cpu host -nodefaults -vga cirrus
> > -vnc :1  -drive if=none,id=block.0,format=raw,
> > cache=writeback,file=drive.img -device
> > virtio-blk-pci,bootindex=1,drive=block.0 -monitor stdio
> > 
> > Same procedure to get it to break - run crystal disk mark. Passed the
> > stream read/write and 512k block read/write - broke at the seek intensive
> > 4k level.
> > 
> > Regards,
> > Paul
> 
> Hi Paul,
> Managed to reproduce this problem, thank you. Going to fix it in the build.
> Meanwhile, instead of writeback, could you  try cache=off ?
> 
> Best regards,
> Vadim.

should be fixed in build25

http://download.devel.redhat.com/brewroot/packages/virtio-win-
prewhql/0.1/25/win/virtio-win-prewhql-0.1.zip
http://people.redhat.com/vrozenfe/build-25/virtio-win-prewhql-0.1.zip

Note that it is a pre-WHQL build, so use it on your own risk.
Use https://bugzilla.redhat.com/show_bug.cgi?id=810694 for the bug tracking.

Cheers,
Vadim.

Re: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

[Vadim Rozenfeld]

On Monday, March 19, 2012 02:48:43 PM Paul Lu-???-? wrote:
> Hi Vadim,
> Here is the configuration:
> /usr/local/bin/qemu-system-x86_64 \
>  -localtime \
>  -boot order=c,menu=on \
>  -drive file=/var/lib/libvirt/images/xxx.img \
>  -vga qxl \
>  -cdrom /home/paul/Downloads/ISO/virtio-win-0.1-15.iso \
>  -chardev spicevmc,id=vdagent,name=vdagent \
>  -spice port=5930,disable-ticketing \
>  -device virtio-serial-pci \
>  -device virtserialport,chardev=vdagent,name=com.redhat.spice.0 \
>  -smp 1,cores=1 -m 2048 \
>  -enable-kvm \
>  -usbdevice tablet \
>  -net nic -net user \
>  -tb-size 0 \
>  -qmp tcp:localhost:,nowait,server \
>  -D /home/paul/MyQemuLog/xxx/xxx.log \
>  -trace events=/home/paul/MyTestCase/xxx/events
> 
> QEMU Version: qemu-kvm commit 30c044521889195f54a9f2c21310894f545994e8
> 
> 
> I use qmp command, query-pci, to check virtio-serial-pci BAR0. It shows
> 0xC140. However, pci_default_read_config in pci.c return 0xC141 to Guest.
> We also trace pci_default_wirte_config.
> 
> At some point, the BAR0 will be overwritten to 0xC141. Here is the result,
> 
> virtio_set_status vdev 0x7fbeaba594a0 val 0
> virtio_set_status vdev 0x7fbeaba594a0 val 0
> qemu-system-x86_64: 10:1,len=4
> qemu-system-x86_64: [WRITE]10:, len=4
> qemu-system-x86_64: 10:ffe1,len=4
> qemu-system-x86_64: [WRITE]10:1, len=4
> qemu-system-x86_64: [WRITE]10:c140, len=4
> virtio_set_status vdev 0x7fbeaba594a0 val 0
> qemu-system-x86_64: 10:c141,len=4
> qemu-system-x86_64: 10:c141,len=4
> qemu-system-x86_64: 10:c141,len=4
> qemu-system-x86_64: 10:c141,len=4
> qemu-system-x86_64: 10:c141,len=4
> virtio_set_status vdev 0x7fbeaba594a0 val 0
> qemu-system-x86_64: 10:c141,len=4
> qemu-system-x86_64: [WRITE]10:, len=4
> qemu-system-x86_64: 10:ffe1,len=4
> qemu-system-x86_64: [WRITE]10:c141, len=4
> virtio_set_status vdev 0x7fbeaba594a0 val 0
> qemu-system-x86_64: 10:c141,len=4
> qemu-system-x86_64: 10:c141,len=4
> qemu-system-x86_64: 10:c141,len=4
> qemu-system-x86_64: 10:c141,len=4
> 
> I think the following code in pci_default_wirte_config cause the problem,
>for (i = 0; i < l; val >>= 8, ++i) {
> uint8_t wmask = d->wmask[addr + i];
> uint8_t w1cmask = d->w1cmask[addr + i];
> assert(!(wmask & w1cmask));
> d->config[addr + i] = (d->config[addr + i] & ~wmask) | (val &
> wmask); d->config[addr + i] &= ~(val & w1cmask); /* W1C: Write 1 to Clear
> */ }
> 
> Could you elaborate it for us?
> 
> 
> Best Regards,
> Paul
> 
Hi Paul,

1 in the lowest bit means that that it is an I/O space BAR.

Regarding installation problem on UP VM, the following patch should
fix this problem.
diff --git a/vioserial/sys/Device.c b/vioserial/sys/Device.c
index ecf2433..4fe1e12 100644
--- a/vioserial/sys/Device.c
+++ b/vioserial/sys/Device.c
@@ -547,8 +547,6 @@ VIOSerialEvtDeviceD0Entry(
 {
 VIOSerialInitAllQueues(Device);
 VIOSerialRenewAllPorts(Device);
-TraceEvents(TRACE_LEVEL_INFORMATION, DBG_INIT, "Setting 
VIRTIO_CONFIG_S_DRIVER_OK flag\n");
-VirtIODeviceAddStatus(pContext->pIODevice, 
VIRTIO_CONFIG_S_DRIVER_OK);
 }
 
 return STATUS_SUCCESS;
@@ -601,6 +599,8 @@ VIOSerialEvtDeviceD0EntryPostInterruptsEnabled(
 }
 else if (PreviousState == WdfPowerDeviceD3Final)
 {
+TraceEvents(TRACE_LEVEL_INFORMATION, DBG_INIT, "Setting 
VIRTIO_CONFIG_S_DRIVER_OK flag\n");
+VirtIODeviceAddStatus(pContext->pIODevice, 
VIRTIO_CONFIG_S_DRIVER_OK);
 TraceEvents(TRACE_LEVEL_INFORMATION, DBG_INIT, "Sending 
VIRTIO_CONSOLE_DEVICE_READY 1\n");
 VIOSerialSendCtrlMsg(WdfDevice, VIRTIO_CONSOLE_BAD_ID, 
VIRTIO_CONSOLE_DEVICE_READY, 1);
 }


Best regards,
Vadim.

> -Original Message-
> From: Charles.Tsai-???-?
> Sent: Mon 3/19/2012 8:32 PM
> To: Vadim Rozenfeld
> Cc: Michael Roth; Stefan Hajnoczi; spice-de...@lists.freedesktop.org; Alex
> Huang-???-?; Alon Levy; qemu-devel; Paul Lu-???-? Subject: RE:
> [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15
> 
> Vadim,
> 
> My colleague will give you more  information we found here.
> Qemu somehow in this particular case returns a wrong bar0 value.
> In working case, the bar0 is 0xc140. But in failure case, the bar0 is
> changed to 0xC141.
> 
> 
> 
> -Original Message-
> From: Vadim Rozenfeld [mailto:vroze...@redhat.com]
> Sent: Monday, March 19, 2012 8:03 PM
> To: Charles.Tsai-???-?
> Cc: Michael Roth; Stefan Hajnoczi; spice-de...@lists.freedesktop.org; Alex
> Huang-???-?; Alon Levy; qemu-devel; Paul Lu-???-? Subject: Re:
> [Qemu-devel] [Spice-devel] Vioserial of Win

Re: [Qemu-devel] Windows Virtio Issue

[Vadim Rozenfeld]

On Monday, March 26, 2012 02:45:34 PM Paul Fisher wrote:
> On 26 March 2012 09:50, Vadim Rozenfeld  wrote:
> > On Sunday, March 25, 2012 07:01:54 PM Yan Vugenfirer wrote:
> > Hi Paul,
> > Could you try reproducing this problem on "-smp 2" guest, with
> > small memory dump option turned on, instead of kernel memory dump.
> > 
> > Thanks,
> > Vadim.
> 
> Hi Vadim.
> 
> Thank you kindly for getting back to me.
> 
> I can certainly do that:
> 
> Dump and BSOD are in a zip at
> http://dl.dropbox.com/u/12332019/2200-VirtioBSOD-2.zip
> 
> This time running with 2 cores:
> 
> qemu-kvm -m 1024 -smp sockets=1,cores=2 -cpu host -nodefaults -vga cirrus
> -vnc :1  -drive if=none,id=block.0,format=raw,
> cache=writeback,file=drive.img -device
> virtio-blk-pci,bootindex=1,drive=block.0 -monitor stdio
> 
> Same procedure to get it to break - run crystal disk mark. Passed the
> stream read/write and 512k block read/write - broke at the seek intensive
> 4k level.
> 
> Regards,
> Paul

Hi Paul,
Managed to reproduce this problem, thank you. Going to fix it in the build.
Meanwhile, instead of writeback, could you  try cache=off ?

Best regards,
Vadim.

Re: [Qemu-devel] Windows Virtio Issue

[Vadim Rozenfeld]

On Sunday, March 25, 2012 07:01:54 PM Yan Vugenfirer wrote:
Hi Paul,
Could you try reproducing this problem on "-smp 2" guest, with
small memory dump option turned on, instead of kernel memory dump.

Thanks,
Vadim.

> Hello Paul,
> 
> Vadim is the owner of virtio-block Windows driver. He will try to help you.
> 
> Best regards,
> Yan.
> 
> On Mar 23, 2012, at 7:32 PM, Paul Fisher wrote:
> > Dear Yan,
> > 
> > We seem to be having some trouble with virtio disk on Windows Server 2008
> > R2 running on qemu-kvm. Essentially, when disk IO is stressed, it seems
> > to blue screen.
> > 
> > 
> > These are potentially contended disks, since it's public cloud with
> > multiple customers on the host - the issue could be connected to
> > contention making disk response slow?
> > 
> > Pertinent facts:
> > 
> > * qemu-kvm 1.0
> > 
> > * Hosts have linux kernel 3.2.2, 64 bit, AMD Opteron 6128
> > 
> > * VM is Windows Server 2008 R2, 64 bit - all patches downloaded from MS
> > 
> > * Virtio disk drivers are the February 2012 release .2200. Problem is
> > apparent with the older .2000 driver as well.
> > 
> > * Blue screen shows failure in viostor.sys - screen cap and minidump are
> > at http://dl.dropbox.com/u/12332019/2200BSOD.zip
> > 
> > 
> > * Replication: Yes. Easily. In this case I stressed the disk by running
> > Crystal Disk mark (a free IO measuring tool). When it got to the 4 KB
> > random seek tests - I think it was on write - it would consistently blue
> > screen.
> > 
> > * If it would help, I can provide remote access to this virtual machine
> > if you wish - it's in our cloud system.
> > 
> > * qemu-kvm command line:
> > 
> > 
> > 
> > qemu-kvm -m MEMORY -smp SMP -cpu host -nodefaults -vga cirrus -vnc :1 
> > -drive if=none,id=block.0,format=raw, cache=writeback,file=drive.img
> > -device virtio-blk-pci,bootindex=1, drive=block.0 -monitor stdio
> > 
> > Any help would be greatly appreciated.
> > 
> > Regards,
> > Paul Fisher
> > Operations Manager
> > ElasticHosts Ltd

Re: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

[Vadim Rozenfeld]

On Monday, March 19, 2012 02:48:43 PM Paul Lu-???-? wrote:
> Hi Vadim,
> Here is the configuration:
> /usr/local/bin/qemu-system-x86_64 \
>  -localtime \
>  -boot order=c,menu=on \
>  -drive file=/var/lib/libvirt/images/xxx.img \
>  -vga qxl \
>  -cdrom /home/paul/Downloads/ISO/virtio-win-0.1-15.iso \
>  -chardev spicevmc,id=vdagent,name=vdagent \
>  -spice port=5930,disable-ticketing \
>  -device virtio-serial-pci \
>  -device virtserialport,chardev=vdagent,name=com.redhat.spice.0 \
>  -smp 1,cores=1 -m 2048 \
>  -enable-kvm \
>  -usbdevice tablet \
>  -net nic -net user \
>  -tb-size 0 \
>  -qmp tcp:localhost:,nowait,server \
>  -D /home/paul/MyQemuLog/xxx/xxx.log \
>  -trace events=/home/paul/MyTestCase/xxx/events
> 
> QEMU Version: qemu-kvm commit 30c044521889195f54a9f2c21310894f545994e8
> 
> 
> I use qmp command, query-pci, to check virtio-serial-pci BAR0. It shows
> 0xC140. However, pci_default_read_config in pci.c return 0xC141 to Guest.
> We also trace pci_default_wirte_config.
> 
> At some point, the BAR0 will be overwritten to 0xC141. Here is the result,
> 
> virtio_set_status vdev 0x7fbeaba594a0 val 0
> virtio_set_status vdev 0x7fbeaba594a0 val 0
> qemu-system-x86_64: 10:1,len=4
> qemu-system-x86_64: [WRITE]10:, len=4
> qemu-system-x86_64: 10:ffe1,len=4
> qemu-system-x86_64: [WRITE]10:1, len=4
> qemu-system-x86_64: [WRITE]10:c140, len=4
> virtio_set_status vdev 0x7fbeaba594a0 val 0
> qemu-system-x86_64: 10:c141,len=4
> qemu-system-x86_64: 10:c141,len=4
> qemu-system-x86_64: 10:c141,len=4
> qemu-system-x86_64: 10:c141,len=4
> qemu-system-x86_64: 10:c141,len=4
> virtio_set_status vdev 0x7fbeaba594a0 val 0
> qemu-system-x86_64: 10:c141,len=4
> qemu-system-x86_64: [WRITE]10:, len=4
> qemu-system-x86_64: 10:ffe1,len=4
> qemu-system-x86_64: [WRITE]10:c141, len=4
> virtio_set_status vdev 0x7fbeaba594a0 val 0
> qemu-system-x86_64: 10:c141,len=4
> qemu-system-x86_64: 10:c141,len=4
> qemu-system-x86_64: 10:c141,len=4
> qemu-system-x86_64: 10:c141,len=4
> 
> I think the following code in pci_default_wirte_config cause the problem,
>for (i = 0; i < l; val >>= 8, ++i) {
> uint8_t wmask = d->wmask[addr + i];
> uint8_t w1cmask = d->w1cmask[addr + i];
> assert(!(wmask & w1cmask));
> d->config[addr + i] = (d->config[addr + i] & ~wmask) | (val &
> wmask); d->config[addr + i] &= ~(val & w1cmask); /* W1C: Write 1 to Clear
> */ }
> 
> Could you elaborate it for us?
> 
Hi Paul,
Give me a couple of days.
Best,
Vadim.
> 
> Best Regards,
> Paul
> 
> -Original Message-
> From: Charles.Tsai-???-?
> Sent: Mon 3/19/2012 8:32 PM
> To: Vadim Rozenfeld
> Cc: Michael Roth; Stefan Hajnoczi; spice-de...@lists.freedesktop.org; Alex
> Huang-???-?; Alon Levy; qemu-devel; Paul Lu-???-? Subject: RE:
> [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15
> 
> Vadim,
> 
> My colleague will give you more  information we found here.
> Qemu somehow in this particular case returns a wrong bar0 value.
> In working case, the bar0 is 0xc140. But in failure case, the bar0 is
> changed to 0xC141.
> 
> 
> 
> -Original Message-
> From: Vadim Rozenfeld [mailto:vroze...@redhat.com]
> Sent: Monday, March 19, 2012 8:03 PM
> To: Charles.Tsai-???-?
> Cc: Michael Roth; Stefan Hajnoczi; spice-de...@lists.freedesktop.org; Alex
> Huang-???-?; Alon Levy; qemu-devel; Paul Lu-???-? Subject: Re:
> [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15
> 
> On Monday, March 19, 2012 01:16:56 PM Charles.Tsai-???-????? wrote:
> > Vadim,
> > 
> > What do you mean "qemu configuration string"? Is it the build
> > configuration or command line option? Please let me know it. Thanks.
> 
> Sorry, that was ambiguous.
> I need the command line in order to reproduce the problem.
> 
> Cheers,
> Vadim.
> 
> > -Original Message-
> > From: Vadim Rozenfeld [mailto:vroze...@redhat.com]
> > Sent: Monday, March 19, 2012 5:17 PM
> > To: Charles.Tsai-???-?
> > Cc: Michael Roth; Stefan Hajnoczi; spice-de...@lists.freedesktop.org;
> > Alex
> > Huang-???-?; Alon Levy; qemu-devel; Paul Lu-???-? Subject: Re:
> > [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15
> > 
> > On Monday, March 19, 2012 08:29:41 AM Charles.Tsai-???-? wrote:
> > > Hi Vadim,
> > > 
> > >   We recently encountered with many issues with new Windows Virio
> > > 
> > > driver running on Qemu 1.0 and Qemu 1.0.50. My initial investigation
> > > was 

Re: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

[Vadim Rozenfeld]

On Monday, March 19, 2012 01:56:03 PM Christophe Fergeau wrote:
> On Mon, Mar 19, 2012 at 01:42:21PM +0200, Vadim Rozenfeld wrote:
> > On Monday, March 19, 2012 12:12:59 PM Christophe Fergeau wrote:
> > > Hey,
> > > 
> > > On Mon, Mar 19, 2012 at 02:29:41PM +0800, Charles.Tsai-蔡清海-研究發展部 wrote:
> > > > 3. When we disable and enable the new VirtIO driver several 
> > > > times
> > > > on either Qemu 1.0 or Qemu 1.0.50, VirtIo driver failed to work
> > > > after enabling the new VirtIO driver.
> > > 
> > > For what it's worth, Alon Levy also hit this particular bug a few
> > > months ago, and I successfully reproduced at that time. I think I
> > > reported it to Vadim back in the days, but I'm not 100% sure :)
> > > 
> > > Christophe
> > 
> > Thanks Christophe.
> > In your case (https://bugzilla.redhat.com/show_bug.cgi?id=750773)
> > an UP system hangs on shutdown.
> 
> In my case, the hang was during boot even though it magically went away
> sometimes in the last month
> 
> > I'm not sure whether Charles is hitting the same problem.
> 
> While trying to figure out what was going on with the bug above, I've
> definitely hit a "enabling/disabling vioserial in the device manager 3
> times causes the VM to freeze" bug.
> For what it's worth, lately I've also been experiencing VM freezes when
> installing vioserial in winxp or win7 UP VMs
OK. It looks like the same race condition, which I'm going to fix. 
> 
> Christophe

Re: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

[Vadim Rozenfeld]

On Monday, March 19, 2012 01:16:56 PM Charles.Tsai-蔡清海-研究發展部 wrote:
> Vadim,
> 
> What do you mean "qemu configuration string"? Is it the build configuration
> or command line option? Please let me know it. Thanks.
> 
> 
Sorry, that was ambiguous.
I need the command line in order to reproduce the problem.

Cheers,
Vadim.

> 
> 
> -----Original Message-
> From: Vadim Rozenfeld [mailto:vroze...@redhat.com]
> Sent: Monday, March 19, 2012 5:17 PM
> To: Charles.Tsai-蔡清海-研究發展部
> Cc: Michael Roth; Stefan Hajnoczi; spice-de...@lists.freedesktop.org; Alex
> Huang-黃必賢-研究發展部; Alon Levy; qemu-devel; Paul Lu-盧偉智-研究發展部 Subject: Re:
> [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15
> 
> On Monday, March 19, 2012 08:29:41 AM Charles.Tsai-蔡清海-研究發展部 wrote:
> > Hi Vadim,
> > 
> > We recently encountered with many issues with new Windows Virio
> > 
> > driver running on Qemu 1.0 and Qemu 1.0.50. My initial investigation
> > was found that the new Viro driver could not be installed  before Qemu
> > 1.0.50. But my colleague right now can install the new Virio driver on
> > Qemu 1.0. Such a finding is quite a bit surprise to me.
> 
> Does Windows refuse to install a new driver or just stuck?
> 
> > When we tested the new Virio driver on both Qemu 1.0 and 1.0.50, we
> > 
> > found the Virio driver failed to work after disabling and enabling the
> > driver a few times. However, the failure case largely depends on the
> > type of machine. On my machine, I did not see such a problem.
> 
> Are you running SMP or UP guest? What about others?
> 
> > Here are a few of questions that I want to clarify for us.
> > 
> > 1. Can the new VirIO driver be installed prior Qemu 1.0.50(the
> > 
> > current head branch)?
> 
> Yes, as far as I know.
> 
> > 2. Does your QA team verify the new VirtIo driver prior Qemu 1.0.50?
> > Do you recommend us to do such a test or debugging?
> 
> Our QA test our drivers on top of RHEL only. I don't know exactly what is
> the difference between our latest qemu-kvm and upstream
> 
> > 3. When we disable and enable the new VirtIO driver several times on
> > 
> > either Qemu 1.0 or Qemu 1.0.50, VirtIo driver failed to work after
> > enabling the new VirtIO driver. What we found in this particular case
> > is that the VirtIO driver was blocked inside the DPC routine where the
> > driver tried to ACK the interrupt. Based on my colleague's
> > observation,
> 
> the
> 
> > I/O read from DPC was not trapped by the front-end driver(a Linux
> > driver implemented for VirtIO)? Do you have any idea why this could
> > happen? Also, did you  find similar issues by you or your 
> > QA?
> 
> I know for sure that we have at least one race condition described here:
> https://bugzilla.redhat.com/show_bug.cgi?id=750773
> Hence, my question is whether your guest is SMP or UP?
> 
> > Please let us know these as soon as possible since we have a big
> > 
> > trouble to make the Virio driver(new and old driver) work stably in
> > any Qemu official release including Qemu 1.0.50.
> 
> I'm going to push some changes, mostly related to the above bug.
> The DPC problem is completely new for me. Please post your qemu
> configuration string and I'll try to reproduce it and investigate this
> problem.
> 
> Best regards,
> Vadim.
> 
> > -Original Message-
> > From: Vadim Rozenfeld [mailto:vroze...@redhat.com]
> > Sent: Wednesday, February 08, 2012 3:47 PM
> > To: Charles.Tsai-蔡清海-研究發展部
> > Cc: Michael Roth; Stefan Hajnoczi; spice-de...@lists.freedesktop.org;
> > Alex
> > Huang-黃必賢-研究發展部; Alon Levy; qemu-devel; Paul Lu-盧偉智-研究發展部 Subject: Re:
> > [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15
> > 
> > I'm afraid to give you any recommendations regarding QEMU stability.
> > I usually work with qemu-kvm repository. But we are always doing WHQL
> > process on RHEL platform only.
> > 
> > Maybe someone from the SPICE team can comment on your question?
> > 
> > Best regards,
> > Vadim.
> > 
> > - Original Message -
> > From: "Charles.Tsai-蔡清海-研究發展部" 
> > To: "Vadim Rozenfeld" 
> > Cc: "Michael Roth" , "Stefan Hajnoczi"
> > , spice-de...@lists.freedesktop.org, "Alex
> > Huang-黃必賢-研究發展部" , "Alon Levy"
> > , "qemu-devel" , "Paul
> > Lu-盧偉智-研究發展部"  Sent: Wednesday, February 8, 2012
> > 4:39:22 AM
> > Subject: RE: [Q

Re: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

[Vadim Rozenfeld]

On Monday, March 19, 2012 12:12:59 PM Christophe Fergeau wrote:
> Hey,
> 
> On Mon, Mar 19, 2012 at 02:29:41PM +0800, Charles.Tsai-蔡清海-研究發展部 wrote:
> > 3. When we disable and enable the new VirtIO driver several times
> > on either Qemu 1.0 or Qemu 1.0.50, VirtIo driver failed to work
> > after enabling the new VirtIO driver.
> 
> For what it's worth, Alon Levy also hit this particular bug a few months
> ago, and I successfully reproduced at that time. I think I reported it to
> Vadim back in the days, but I'm not 100% sure :)
> 
> Christophe
Thanks Christophe.
In your case (https://bugzilla.redhat.com/show_bug.cgi?id=750773)
an UP system hangs on shutdown. 
I'm not sure whether Charles is hitting the same problem.

Best,
Vadim.

Re: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

[Vadim Rozenfeld]

On Monday, March 19, 2012 08:29:41 AM Charles.Tsai-蔡清海-研究發展部 wrote:
> Hi Vadim,
> 
>   We recently encountered with many issues with new Windows Virio driver
> running on Qemu 1.0 and Qemu 1.0.50. My initial investigation was found
> that the new Viro driver could not be installed  before Qemu 1.0.50. But
> my colleague right now can install the new Virio driver on Qemu 1.0. Such
> a finding is quite a bit surprise to me.
Does Windows refuse to install a new driver or just stuck? 
> 
>   When we tested the new Virio driver on both Qemu 1.0 and 1.0.50, we 
> found
> the Virio driver failed to work after disabling and enabling the driver a
> few times. However, the failure case largely depends on the type of
> machine. On my machine, I did not see such a problem.
Are you running SMP or UP guest? What about others?
> 
>   Here are a few of questions that I want to clarify for us.
> 
>   1. Can the new VirIO driver be installed prior Qemu 1.0.50(the current
> head branch)? 
Yes, as far as I know.
> 2. Does your QA team verify the new VirtIo driver prior Qemu
> 1.0.50? Do you recommend us to do such a test or debugging?
Our QA test our drivers on top of RHEL only. I don't know exactly what
is the difference between our latest qemu-kvm and upstream
> 
>   3. When we disable and enable the new VirtIO driver several times on
> either Qemu 1.0 or Qemu 1.0.50, VirtIo driver failed to work after
> enabling the new VirtIO driver. What we found in this particular case is
> that the VirtIO driver was blocked inside the DPC routine where the driver
> tried to ACK the interrupt. Based on my colleague's  observation, 
the
> I/O read from DPC was not trapped by the front-end driver(a Linux driver
> implemented for VirtIO)? Do you have any idea why this could happen? Also,
> did you  find similar issues by you or your QA?
I know for sure that we have at least one race condition described here:
https://bugzilla.redhat.com/show_bug.cgi?id=750773
Hence, my question is whether your guest is SMP or UP? 
> 
>   Please let us know these as soon as possible since we have a big trouble
> to make the Virio driver(new and old driver) work stably in any Qemu
> official release including Qemu 1.0.50.
I'm going to push some changes, mostly related to the above bug. 
The DPC problem is completely new for me. Please post your qemu 
configuration string and I'll try to reproduce it and investigate this problem.

Best regards,
Vadim.
> 
> 
> -Original Message-
> From: Vadim Rozenfeld [mailto:vroze...@redhat.com]
> Sent: Wednesday, February 08, 2012 3:47 PM
> To: Charles.Tsai-蔡清海-研究發展部
> Cc: Michael Roth; Stefan Hajnoczi; spice-de...@lists.freedesktop.org; Alex
> Huang-黃必賢-研究發展部; Alon Levy; qemu-devel; Paul Lu-盧偉智-研究發展部 Subject: Re:
> [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15
> 
> I'm afraid to give you any recommendations regarding QEMU stability.
> I usually work with qemu-kvm repository. But we are always doing WHQL
> process on RHEL platform only.
> 
> Maybe someone from the SPICE team can comment on your question?
> 
> Best regards,
> Vadim.
> 
> - Original Message -
> From: "Charles.Tsai-蔡清海-研究發展部" 
> To: "Vadim Rozenfeld" 
> Cc: "Michael Roth" , "Stefan Hajnoczi"
> , spice-de...@lists.freedesktop.org, "Alex
> Huang-黃必賢-研究發展部" , "Alon Levy"
> , "qemu-devel" , "Paul
> Lu-盧偉智-研究發展部"  Sent: Wednesday, February 8, 2012
> 4:39:22 AM
> Subject: RE: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on
> Qemu 0.15
> 
> Vadim,
> 
> Thanks. I tested Windows guest OS driver the over qemu-kvm-devel 1.0.50
> from git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git and it worked. The
> latest Windows guest driver from (https://github.com/YanVugenfirer/) seems
> to have to work with Qemu 1.0.50. My previous test ran over Qemu 1.0 and
> that was why it failed to work.
> 
> As you mentioned, the latest driver from
> (https://github.com/YanVugenfirer/) is much more stable than the old one.
> But those drivers must work with Qemu 1.0.50 which was not verified to be
> stable. Do you think Qemu 1.0.50 is stable to be used? Please give us a
> recommendation.
> 
> 
> -Original Message-
> From: Vadim Rozenfeld [mailto:vroze...@redhat.com]
> Sent: Wednesday, February 08, 2012 3:06 AM
> To: Charles.Tsai-蔡清海-研究發展部
> Cc: Michael Roth; Stefan Hajnoczi; spice-de...@lists.freedesktop.org; Alex
> Huang-黃必賢-研究發展部; Alon Levy; qemu-devel; Paul Lu-盧偉智-研究發展部 Subject: Re:
> [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15
> 
> I have tried to reproduce the problem several times wit

Re: [Qemu-devel] BSOD when using Hyper-V extensions with Win2k8R2 guests

[Vadim Rozenfeld]

On Thursday, March 15, 2012 11:26:00 PM Paolo Bonzini wrote:
> Il 15/03/2012 20:14, Michael Roth ha scritto:
> > Unfortunately the BSOD is too early to get a kernel dump, but here are
> > the error params in case that's useful:
> > 
> > 0xFC096, 0xF800027F6200, 0x0, 0x0
> > 
> > Let me know if you need any other details.
> 
> You can use the Windows Boot Debugger.  (Disclaimer: I only used it
> once).  Enable it with "bcdedit /bootdebug {current} ON".
> 
It is not a loader problem. You even don't need to turn halbreakpoint option 
on.
> To use it, you need two Windows VMs (the one that fails and one with
> WinDbg installed).  It is the same as doing normal kernel debugging
> except that the debuggee will hang waiting for a connection even before
> showing the boot loader prompt.  You need to connect the serial consoles
> of the VMs; I usually use socat like
> 
> socat "PIPE:$tty1,unlink-close=0,noctty=1" \
>   "PIPE:$tty2,unlink-close=0,noctty=1
> 
> with the tty names taken from libvirt's XML.  It probably works with
> Unix sockets too but I never tried.
> 
> From WinDbg you should be able to get a backtrace.  If you never used
> WinDbg, remember to set it up for downloading symbols:
> http://support.microsoft.com/kb/311503
> 
> HTH,
> 
> Paolo

Re: [Qemu-devel] BSOD when using Hyper-V extensions with Win2k8R2 guests

[Vadim Rozenfeld]

On Thursday, March 15, 2012 10:00:11 PM Anthony Liguori wrote:
> On 03/15/2012 02:54 PM, Vadim Rozenfeld wrote:
> > On Thursday, March 15, 2012 09:14:39 PM Michael Roth wrote:
> >> Hi Vadim,
> >> 
> >> I've been trying to use -cpu qemu64,hv_relaxed as a workaround for a
> >> CLOCK_WATCHDOG_TIMEOUT BSOD on Windows 2008 R2 guests when a vcpu's
> >> execution is delayed for an extended period. When I do this however I
> >> get the following the BSOD:
> >> 
> >> http://msdn.microsoft.com/en-us/library/windows/hardware/ff559206(v=vs.8
> >> 5). aspx
> >> 
> >> I've also tried -cpu qemu64,hv_spinlocks=4 and -cpu qemu64,hv_vapic as a
> >> sanity check and this results in the same error being thrown.
> >> 
> >> Host is RHEL6.1 using latest qemu.git, guests are win2k8 server r2 (same
> > 
> > I'm pretty much sure that hyper-v support was not backported into RHEL
> > 6.1 KVM.
> 
> So is there a hyper-v capability for KVM then?  Or a CPUID feature?
KVM_CAP_HYPERV, but we don't use it at the moment.
> 
> Should QEMU refuse to enable hv_relaxed if the capability isn't present?
Yes. I will submit a patch.
Best regards,
Vadim.
> 
> Regards,
> 
> Anthony Liguori
> 
> > Best regards,
> > Vadim.
> > 
> >> behavior for both SP0 and SP1). Here's the full command-line:
> >> 
> >> qemu-upstream -L ../qemu-build/pc-bios -cpu qemu64,hv_relaxed
> >> --enable-kvm \ -M pc-1.1 -enable-kvm -m 4096 -smp
> >> 4,sockets=4,cores=1,threads=1 \ -name ichigo-dom45 -nodefconfig
> >> -nodefaults -rtc base=utc,driftfix=slew \ -drive
> >> file=/scratch/mdroth/win2k8r2sp1.raw,if=none,id=drive0,format=raw,cache
> >> =wr itethrough,snapshot=on \ -device
> >> virtio-blk-pci,bus=pci.0,drive=drive0,id=disk0,bootindex=1 \ -netdev
> >> tap,id=hostnet0,script=/etc/qemu-ifup \
> >> 
> >>  -device
> >> 
> >> virtio-net-pci,netdev=hostnet0,id=net0,mac=00:FF:FE:00:00:2d,bus=pci.0 \
> >> -device virtio-balloon-pci,id=balloon0,bus=pci.0 \
> >> 
> >>  -usb -device usb-tablet,id=input0 -vnc 0.0.0.0:45 -vga cirrus
> >> 
> >> Unfortunately the BSOD is too early to get a kernel dump, but here are
> >> the error params in case that's useful:
> >> 
> >> 0xFC096, 0xF800027F6200, 0x0, 0x0
> >> 
> >> Let me know if you need any other details.
> >> 
> >> Thanks!

Re: [Qemu-devel] BSOD when using Hyper-V extensions with Win2k8R2 guests

[Vadim Rozenfeld]

On Thursday, March 15, 2012 09:14:39 PM Michael Roth wrote:
> Hi Vadim,
> 
> I've been trying to use -cpu qemu64,hv_relaxed as a workaround for a
> CLOCK_WATCHDOG_TIMEOUT BSOD on Windows 2008 R2 guests when a vcpu's
> execution is delayed for an extended period. When I do this however I get
> the following the BSOD:
> 
> http://msdn.microsoft.com/en-us/library/windows/hardware/ff559206(v=vs.85).
> aspx
> 
> I've also tried -cpu qemu64,hv_spinlocks=4 and -cpu qemu64,hv_vapic as a
> sanity check and this results in the same error being thrown.
> 
> Host is RHEL6.1 using latest qemu.git, guests are win2k8 server r2 (same

I'm pretty much sure that hyper-v support was not backported into RHEL 6.1 
KVM.
Best regards,
Vadim.  

> behavior for both SP0 and SP1). Here's the full command-line:
> 
> qemu-upstream -L ../qemu-build/pc-bios -cpu qemu64,hv_relaxed --enable-kvm
> \ -M pc-1.1 -enable-kvm -m 4096 -smp 4,sockets=4,cores=1,threads=1 \ -name
> ichigo-dom45 -nodefconfig -nodefaults -rtc base=utc,driftfix=slew \ -drive
> file=/scratch/mdroth/win2k8r2sp1.raw,if=none,id=drive0,format=raw,cache=wr
> itethrough,snapshot=on \ -device
> virtio-blk-pci,bus=pci.0,drive=drive0,id=disk0,bootindex=1 \ -netdev
> tap,id=hostnet0,script=/etc/qemu-ifup \
> -device
> virtio-net-pci,netdev=hostnet0,id=net0,mac=00:FF:FE:00:00:2d,bus=pci.0 \
> -device virtio-balloon-pci,id=balloon0,bus=pci.0 \
> -usb -device usb-tablet,id=input0 -vnc 0.0.0.0:45 -vga cirrus
> 
> Unfortunately the BSOD is too early to get a kernel dump, but here are
> the error params in case that's useful:
> 
> 0xFC096, 0xF800027F6200, 0x0, 0x0
> 
> Let me know if you need any other details.
> 
> Thanks!

Re: [Qemu-devel] win7 bad i/o performance, high insn_emulation and exists

[Vadim Rozenfeld]

- Original Message -
From: "Peter Lieven" 
To: "Vadim Rozenfeld" 
Cc: qemu-devel@nongnu.org, k...@vger.kernel.org, "Gleb Natapov" 

Sent: Tuesday, February 21, 2012 4:10:22 PM
Subject: Re: win7 bad i/o performance, high insn_emulation and exists

On 21.02.2012 14:56, Vadim Rozenfeld wrote:
>
> - Original Message -
> From: "Peter Lieven"
> To: "Gleb Natapov"
> Cc: qemu-devel@nongnu.org, k...@vger.kernel.org, vroze...@redhat.com
> Sent: Tuesday, February 21, 2012 2:05:25 PM
> Subject: Re: win7 bad i/o performance, high insn_emulation and exists
>
> On 21.02.2012 12:46, Gleb Natapov wrote:
>> On Tue, Feb 21, 2012 at 12:16:16PM +0100, Peter Lieven wrote:
>>> On 21.02.2012 12:00, Gleb Natapov wrote:
>>>> On Tue, Feb 21, 2012 at 11:59:23AM +0100, Peter Lieven wrote:
>>>>> On 21.02.2012 11:56, Gleb Natapov wrote:
>>>>>> On Tue, Feb 21, 2012 at 11:50:47AM +0100, Peter Lieven wrote:
>>>>>>>> I hope it will make Windows use TSC instead, but you can't be sure
>>>>>>>> about anything with Windows :(
>>>>>>> Whatever it does now it eates more CPU has almost equal
>>>>>>> number of exits and throughput is about the same (15MB/s).
>>>>>>> If pmtimer is at 0xb008 it still reads it like hell.
>>>>>>>
>>>>>>> I checked with bcedit /v that useplatformclock is set to "No".
>>>>>> Yeah, today I noticed that it is likely virtio drivers that hammer
>>>>>> on PM timer (at least rip of the instruction that access it is
>>>>>> very close to rip of the instruction that access virtio pio).
>>>>>> Vadim, Windows driver developer,  is CCed.
>>>>> Ok, I will switch to IDE and e1000 to confirm this? Or does it not
>>>>> make sense?
>>>>>
>>>> It make perfect sense! Please try it.
>>> ~10MB/s. still a lot of 0xb008 reads.
>>>
> [VR]
> Could it be that you have Driver Verifier running in you system?
>
unfortunately not.

[VR]
Then could you try booting into "Safe Mode"?

i found the following in an old knowledge base article
(http://support.microsoft.com/kb/938448):

"Only Windows Server 2003 with Service Pack 2 uniprocessor ACPI HALs use
*PMTIMER* for QPC by default. Multiprocessor ACPI HALs will use
*PMTIMER* only if *USE_PLATFORM_CLOCK *flag is set by the BIOS or if the
*/usepmtimer *boot.ini option is used. Other HAL types don’t support
*PMTIMER* and will use *TSC* by default for QPC

By default, Windows Server 2003 Service Pack 2 (SP2) uses the PM timer
for all Advanced Configuration and Power Interface (ACPI) HALs unless
one of the following conditions aretrue:

* The check process to determine whether the BIOS supports the APIC
  or ACPI HALs fails.
* *


  Note:* If the BIOS does not support the ACPI HAL, contact the
  original equipment manufacturer to determine whether a BIOS update
  is available that will resolve the problem. If a BIOS update is
  not available, you must use the PM timer by using the
  */usepmtimer* switch.

If you are not running Windows Server 2003 SP2, you must force the AMD
computer to use the PM timer by using the */usepmtimer* switch.

*Note* The decision to use the PM timer or the TSC timer is made during
a check that is performed at startup to query the BIOS and to determine
whether the BIOS will support the PM timer functions. This check is not
completely accurate on AMD chipsets. Therefore, you must use the
*/usepmtimer* switch.

In Windows Server 2003 SP2, this section of code was rewritten.
Therefore, the correct performance monitor data appears on AMD chipsets
that have Windows Server 2003 SP2 installed, and you do not have to use
the */usepmtimer* switch.

For more information about ACPI and APCI hardware support, click the
following article number to view the article in the Microsoft Knowledge
Base:
309283 <http://support.microsoft.com/kb/309283>  HAL options after
Windows XP or Windows Server 2003 Setup
The third-party products that this article discusses are manufactured by
companies that are independent of Microsoft. Microsoft makes no
warranty, implied or otherwise, about the performance or reliability of
these products."

-

so it seems windows prefers pmtimer over tsc. has anyone an idea/hack to
make the acpi_pm timer fail without disabling acpi completely?

thanks,
peter
--
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

Re: [Qemu-devel] win7 bad i/o performance, high insn_emulation and exists

[Vadim Rozenfeld]

- Original Message -
From: "Peter Lieven" 
To: "Gleb Natapov" 
Cc: qemu-devel@nongnu.org, k...@vger.kernel.org, vroze...@redhat.com
Sent: Tuesday, February 21, 2012 2:05:25 PM
Subject: Re: win7 bad i/o performance, high insn_emulation and exists

On 21.02.2012 12:46, Gleb Natapov wrote:
> On Tue, Feb 21, 2012 at 12:16:16PM +0100, Peter Lieven wrote:
>> On 21.02.2012 12:00, Gleb Natapov wrote:
>>> On Tue, Feb 21, 2012 at 11:59:23AM +0100, Peter Lieven wrote:
 On 21.02.2012 11:56, Gleb Natapov wrote:
> On Tue, Feb 21, 2012 at 11:50:47AM +0100, Peter Lieven wrote:
>>> I hope it will make Windows use TSC instead, but you can't be sure
>>> about anything with Windows :(
>> Whatever it does now it eates more CPU has almost equal
>> number of exits and throughput is about the same (15MB/s).
>> If pmtimer is at 0xb008 it still reads it like hell.
>>
>> I checked with bcedit /v that useplatformclock is set to "No".
> Yeah, today I noticed that it is likely virtio drivers that hammer
> on PM timer (at least rip of the instruction that access it is
> very close to rip of the instruction that access virtio pio).
> Vadim, Windows driver developer,  is CCed.
 Ok, I will switch to IDE and e1000 to confirm this? Or does it not
 make sense?

>>> It make perfect sense! Please try it.
>> ~10MB/s. still a lot of 0xb008 reads.
>>
[VR]
Could it be that you have Driver Verifier running in you system?

> The same amount of reads essentially. So my theory is incorrect. Virtio
> driver probably calls Windows function to do IO and the function
> happens to be near the function that access PM timer.
>
> I wonder why time stamps in your traces are so coarse-grained. What do
> you see in /sys/bus/clocksource/devices/clocksource0/current_clocksource ?

its set to acpi_pm on the host. we changed that from tsc (choosen by 
kernel) after we encountered
a kernel bug which ooops all hosts after approx. 270 days uptime. 
(https://lkml.org/lkml/2011/7/21/343).

i am not sure if this is fixed in 2.6.38 or later kernels and we could 
go back to tsc.

for testing i already checked this, but it doesn't give better performance.

peter


> --
>   Gleb.

Re: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

[Vadim Rozenfeld]

I'm afraid to give you any recommendations regarding QEMU stability.
I usually work with qemu-kvm repository. But we are always doing WHQL
process on RHEL platform only.

Maybe someone from the SPICE team can comment on your question?

Best regards,
Vadim.

- Original Message -
From: "Charles.Tsai-蔡清海-研究發展部" 
To: "Vadim Rozenfeld" 
Cc: "Michael Roth" , "Stefan Hajnoczi" 
, spice-de...@lists.freedesktop.org, "Alex Huang-黃必賢-研究發展部" 
, "Alon Levy" , "qemu-devel" 
, "Paul Lu-盧偉智-研究發展部" 
Sent: Wednesday, February 8, 2012 4:39:22 AM
Subject: RE: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 
0.15

Vadim,

Thanks. I tested Windows guest OS driver the over qemu-kvm-devel 1.0.50 from 
git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git and it worked.
The latest Windows guest driver from (https://github.com/YanVugenfirer/) seems 
to have to work with Qemu 1.0.50. My previous test ran over Qemu 1.0 and that 
was why it failed to work.

As you mentioned, the latest driver from (https://github.com/YanVugenfirer/) is 
much more stable than the old one. But those drivers must work with Qemu 1.0.50 
which was not verified to be stable. Do you think Qemu 1.0.50 is stable to be 
used? Please give us a recommendation.


-Original Message-
From: Vadim Rozenfeld [mailto:vroze...@redhat.com]
Sent: Wednesday, February 08, 2012 3:06 AM
To: Charles.Tsai-蔡清海-研究發展部
Cc: Michael Roth; Stefan Hajnoczi; spice-de...@lists.freedesktop.org; Alex 
Huang-黃必賢-研究發展部; Alon Levy; qemu-devel; Paul Lu-盧偉智-研究發展部
Subject: Re: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 
0.15

I have tried to reproduce the problem several times without success.

QEMU:
QEMU 1.0.50 from git://git.qemu.org/qemu.git ,and qemu-kvm-devel 1.0.50 from 
git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git

My guest info:
OS Name:   Microsoft Windows 7 Enterprise
OS Version:6.1.7600 N/A Build 7600

QEMU command line:
sudo /home/vrozenfe/work/upstream/qemu/x86_64-softmmu/qemu-system-x86_64 -m 
1024 -smp 1,sockets=1,cores=1,threads=1 -name SERIAL -uuid 
d9388815-ddd3-c38e-33c2-a9d5fcc7a775 -monitor stdio -rtc base=localtime -device 
virtio-serial-pci,id=virtio-serial0,bus=pci.0,multifunction=on,addr=0x5.0x0 
-drive 
file=/home/vrozenfe/work/images/win7.qcow2,if=none,id=drive-ide0-0-0,format=qcow2
 -device 
ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1 -netdev 
tap,id=hostnet0 -device 
e1000,netdev=hostnet0,id=net0,mac=22:3A:40:3F:2F:12,bus=pci.0,multifunction=on,addr=0x3.0x0
 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 
-chardev spicevmc,id=charchannel0,name=vdagent -device 
virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0
 -usb -device usb-tablet,id=input0 -device 
virtio-balloon-pci,id=balloon0,bus=pci.0,multifunction=on,addr=0x4.0x0 -cdrom 
/home/vrozenfe/work/virtio-win-1.4.0.iso -snapshot -enable-kvm

Drivers:
Both, MS signed from RHEL6.2 virtio-win RPM, as well as compiled by myself with 
the sources from our internal repository (which contains absolutely the same 
code as in Yan's repository).



- Original Message -
From: "Charles.Tsai-蔡清海-研究發展部" 
To: "Vadim Rozenfeld" 
Cc: "Michael Roth" , "Stefan Hajnoczi" 
, spice-de...@lists.freedesktop.org, "Alex Huang-黃必賢-研究發展部" 
, "Alon Levy" , "qemu-devel" 
, "Paul Lu-盧偉智-研究發展部" 
Sent: Monday, February 6, 2012 3:08:55 PM
Subject: RE: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 
0.15

Vadim,

I did the same test again today and no luck to made it work.
Let us what you find since we might have missed some points when we did the 
test.


-Original Message-
From: Vadim Rozenfeld [mailto:vroze...@redhat.com]
Sent: Sunday, February 05, 2012 2:14 AM
To: Charles.Tsai-蔡清海-研究發展部
Cc: Michael Roth; Stefan Hajnoczi; spice-de...@lists.freedesktop.org; Alex 
Huang-黃必賢-研究發展部; Alon Levy; qemu-devel; Paul Lu-盧偉智-研究發展部
Subject: Re: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 
0.15

Thanks,
I'll check this problem.
Vadim.

- Original Message -
From: "Charles.Tsai-蔡清海-研究發展部" 
To: "Charles.Tsai-蔡清海-研究發展部" , "Vadim Rozenfeld" 

Cc: "Michael Roth" , "Stefan Hajnoczi" 
, spice-de...@lists.freedesktop.org, "Alex Huang-黃必賢-研究發展部" 
, "Alon Levy" , "qemu-devel" 
, "Paul Lu-盧偉智-研究發展部" 
Sent: Saturday, February 4, 2012 5:39:26 AM
Subject: RE: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 
0.15

Vadim,

We tested the free build driver on 32-bit Windows 7 and the symptom was the 
same. In other words, the latest driver source from 
https://github.com/YanVugenfirer/ is buggy and it was not workable at all.



-Origina

Re: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

[Vadim Rozenfeld]

I have tried to reproduce the problem several times without success.

QEMU:
QEMU 1.0.50 from git://git.qemu.org/qemu.git
,and
qemu-kvm-devel 1.0.50 from git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git

My guest info:
OS Name:   Microsoft Windows 7 Enterprise
OS Version:6.1.7600 N/A Build 7600

QEMU command line:
sudo /home/vrozenfe/work/upstream/qemu/x86_64-softmmu/qemu-system-x86_64 -m 
1024 -smp 1,sockets=1,cores=1,threads=1 -name SERIAL -uuid 
d9388815-ddd3-c38e-33c2-a9d5fcc7a775 -monitor stdio -rtc base=localtime -device 
virtio-serial-pci,id=virtio-serial0,bus=pci.0,multifunction=on,addr=0x5.0x0 
-drive 
file=/home/vrozenfe/work/images/win7.qcow2,if=none,id=drive-ide0-0-0,format=qcow2
 -device 
ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1 -netdev 
tap,id=hostnet0 -device 
e1000,netdev=hostnet0,id=net0,mac=22:3A:40:3F:2F:12,bus=pci.0,multifunction=on,addr=0x3.0x0
 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 
-chardev spicevmc,id=charchannel0,name=vdagent -device 
virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0
 -usb -device usb-tablet,id=input0 -device 
virtio-balloon-pci,id=balloon0,bus=pci.0,multifunction=on,addr=0x4.0x0 -cdrom 
/home/vrozenfe/work/virtio-win-1.4.0.iso -snapshot -enable-kvm

Drivers:
Both, MS signed from RHEL6.2 virtio-win RPM, as well as
compiled by myself with the sources from our internal repository
(which contains absolutely the same code as in Yan's repository).



- Original Message -
From: "Charles.Tsai-蔡清海-研究發展部" 
To: "Vadim Rozenfeld" 
Cc: "Michael Roth" , "Stefan Hajnoczi" 
, spice-de...@lists.freedesktop.org, "Alex Huang-黃必賢-研究發展部" 
, "Alon Levy" , "qemu-devel" 
, "Paul Lu-盧偉智-研究發展部" 
Sent: Monday, February 6, 2012 3:08:55 PM
Subject: RE: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 
0.15

Vadim,

I did the same test again today and no luck to made it work.
Let us what you find since we might have missed some points when we did the 
test.


-Original Message-
From: Vadim Rozenfeld [mailto:vroze...@redhat.com]
Sent: Sunday, February 05, 2012 2:14 AM
To: Charles.Tsai-蔡清海-研究發展部
Cc: Michael Roth; Stefan Hajnoczi; spice-de...@lists.freedesktop.org; Alex 
Huang-黃必賢-研究發展部; Alon Levy; qemu-devel; Paul Lu-盧偉智-研究發展部
Subject: Re: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 
0.15

Thanks,
I'll check this problem.
Vadim.

----- Original Message -
From: "Charles.Tsai-蔡清海-研究發展部" 
To: "Charles.Tsai-蔡清海-研究發展部" , "Vadim Rozenfeld" 

Cc: "Michael Roth" , "Stefan Hajnoczi" 
, spice-de...@lists.freedesktop.org, "Alex Huang-黃必賢-研究發展部" 
, "Alon Levy" , "qemu-devel" 
, "Paul Lu-盧偉智-研究發展部" 
Sent: Saturday, February 4, 2012 5:39:26 AM
Subject: RE: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 
0.15

Vadim,

We tested the free build driver on 32-bit Windows 7 and the symptom was the 
same. In other words, the latest driver source from 
https://github.com/YanVugenfirer/ is buggy and it was not workable at all.



-Original Message-
From: Charles.Tsai-蔡清海-研究發展部
Sent: Friday, February 03, 2012 12:01 PM
To: 'Vadim Rozenfeld'
Cc: Michael Roth; Stefan Hajnoczi; spice-de...@lists.freedesktop.org; Alex 
Huang-黃必賢-研究發展部; Alon Levy; qemu-devel; Paul Lu-盧偉智-研究發展部
Subject: RE: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 
0.15

Vadim,

I downloaded the latest Windows guest driver code from 
(https://github.com/YanVugenfirer/) and built the test binary driver code.
When I tested the release build Vioserial driver on 64-bit Windows 7, the 
driver seemed to wait for something to happen and the update driver Windows 
dialog simply just stayed in busy state. Finally, the Windows system entered a 
busy loop. However, if I tested the debugging build driver, the driver could be 
installed. But it took for a long time to complete.

Our installed Qemu is 1.0. Is there Qemu build requirement so that we can 
verify the vioserial driver? From my test, the latest code from 
(https://github.com/YanVugenfirer/) seemed to be worst than the one we tested 
before. Let me know if we did anything wrong.


-Original Message-
From: Vadim Rozenfeld [mailto:vroze...@redhat.com]
Sent: Friday, January 20, 2012 8:48 PM
To: Charles.Tsai-蔡清海-研究發展部
Cc: Michael Roth; Stefan Hajnoczi; spice-de...@lists.freedesktop.org; Alex 
Huang-黃必賢-研究發展部; Alon Levy; qemu-devel
Subject: Re: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 
0.15

This code is slightly buggy.
Please try Yan's repository
at github (https://github.com/YanVugenfirer/).
I believe that the most critical changes have been merged already by Yan into 
this public repository.
I will ask to update binaries and so

Re: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

[Vadim Rozenfeld]

Thanks,
I'll check this problem.
Vadim.

- Original Message -
From: "Charles.Tsai-蔡清海-研究發展部" 
To: "Charles.Tsai-蔡清海-研究發展部" , "Vadim Rozenfeld" 

Cc: "Michael Roth" , "Stefan Hajnoczi" 
, spice-de...@lists.freedesktop.org, "Alex Huang-黃必賢-研究發展部" 
, "Alon Levy" , "qemu-devel" 
, "Paul Lu-盧偉智-研究發展部" 
Sent: Saturday, February 4, 2012 5:39:26 AM
Subject: RE: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 
0.15

Vadim,

We tested the free build driver on 32-bit Windows 7 and the symptom was the 
same. In other words, the latest driver source from 
https://github.com/YanVugenfirer/ is buggy and it was not workable at all.



-Original Message-
From: Charles.Tsai-蔡清海-研究發展部
Sent: Friday, February 03, 2012 12:01 PM
To: 'Vadim Rozenfeld'
Cc: Michael Roth; Stefan Hajnoczi; spice-de...@lists.freedesktop.org; Alex 
Huang-黃必賢-研究發展部; Alon Levy; qemu-devel; Paul Lu-盧偉智-研究發展部
Subject: RE: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 
0.15

Vadim,

I downloaded the latest Windows guest driver code from 
(https://github.com/YanVugenfirer/) and built the test binary driver code.
When I tested the release build Vioserial driver on 64-bit Windows 7, the 
driver seemed to wait for something to happen and the update driver Windows 
dialog simply just stayed in busy state. Finally, the Windows system entered a 
busy loop. However, if I tested the debugging build driver, the driver could be 
installed. But it took for a long time to complete.

Our installed Qemu is 1.0. Is there Qemu build requirement so that we can 
verify the vioserial driver? From my test, the latest code from 
(https://github.com/YanVugenfirer/) seemed to be worst than the one we tested 
before. Let me know if we did anything wrong.


-Original Message-
From: Vadim Rozenfeld [mailto:vroze...@redhat.com]
Sent: Friday, January 20, 2012 8:48 PM
To: Charles.Tsai-蔡清海-研究發展部
Cc: Michael Roth; Stefan Hajnoczi; spice-de...@lists.freedesktop.org; Alex 
Huang-黃必賢-研究發展部; Alon Levy; qemu-devel
Subject: Re: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 
0.15

This code is slightly buggy.
Please try Yan's repository
at github (https://github.com/YanVugenfirer/).
I believe that the most critical changes have been merged already by Yan into 
this public repository.
I will ask to update binaries and sources at fedoraproject site as well.

Best regards,
Vadim.


- Original Message -
From: "Charles.Tsai-蔡清海-研究發展部" 
To: "Vadim Rozenfeld" 
Cc: "Michael Roth" , "Stefan Hajnoczi" 
, spice-de...@lists.freedesktop.org, "Alex Huang-黃必賢-研究發展部" 
, "Alon Levy" , "qemu-devel" 

Sent: Friday, January 20, 2012 3:25:51 AM
Subject: RE: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 
0.15

Vadim,

We downloaded the driver source from the following website.
===
wget --no-check-certificate 
https://alt.fedoraproject.org/pub/alt/virtio-win/latest/images/src/virtio-win-prewhql-0.1-15-sources.zip

-Original Message-
From: Vadim Rozenfeld [mailto:vroze...@redhat.com]
Sent: Thursday, January 19, 2012 8:25 PM
To: Charles.Tsai-蔡清海-研究發展部
Cc: Michael Roth; Stefan Hajnoczi; spice-de...@lists.freedesktop.org; Alex 
Huang-黃必賢-研究發展部; Alon Levy; qemu-devel
Subject: Re: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 
0.15

Just to be sure that we are on the same page:
could you tell me about the origin of the source?
Is it the latest from the Yan's repository at github.com?

- Original Message -
From: "Charles.Tsai-蔡清海-研究發展部" 
To: "Vadim Rozenfeld" 
Cc: "Michael Roth" , "Stefan Hajnoczi" 
, spice-de...@lists.freedesktop.org, "Alex Huang-黃必賢-研究發展部" 
, "Alon Levy" , "qemu-devel" 

Sent: Thursday, January 19, 2012 12:06:16 PM
Subject: RE: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 
0.15

Vadim,

We built it from the driver source. Up to this moment, we always use the same 
binary to test Qemu.


-Original Message-
From: Vadim Rozenfeld [mailto:vroze...@redhat.com]
Sent: Thursday, January 19, 2012 5:39 PM
To: Charles.Tsai-蔡清海-研究發展部
Cc: Michael Roth; Stefan Hajnoczi; spice-de...@lists.freedesktop.org; Alex 
Huang-黃必賢-研究發展部; Alon Levy; qemu-devel
Subject: RE: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 
0.15

On Thu, 2012-01-19 at 16:33 +0800, Charles.Tsai-蔡清海-研究發展部 wrote:
> Vadim,
>
> It is SMP system.
What about vioserial driver itself?
did you build it from sources or is
it one, available through RHEL channels?

>
> -Original Message-
> From: Vadim Rozenfeld [mailto:vroze...@redhat.com]
> Sent: Thursday, January 19, 2012 3:58 PM
> To: Charles.Tsai-蔡清海-研究發展部
> Cc: Michael Roth; Stefan 

Re: [Qemu-devel] [PATCH] hyperv: fix build on non-KVM hosts

[Vadim Rozenfeld]

- Original Message -
From: "Blue Swirl" 
To: vroze...@redhat.com, "qemu-devel" 
Sent: Monday, January 23, 2012 10:10:51 PM
Subject: [PATCH] hyperv: fix build on non-KVM hosts

Signed-off-by: Blue Swirl 
---

Maybe a better fix would be to allow hyperv to be used also on TCG.

[VR] Yes, it could be nice. But, sadly, I have no time to do it, 
at least not in the near future.
Best,
Vadim.

---
 Makefile.target  |2 +-
 target-i386/hyperv.h |4 +++-
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/Makefile.target b/Makefile.target
index 092565a..69193d4 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -201,7 +201,7 @@ obj-$(CONFIG_VGA_CIRRUS) += cirrus_vga.o
 obj-y += memory.o savevm.o
 LIBS+=-lz

-obj-i386-y +=hyperv.o
+obj-i386-$(CONFIG_KVM) += hyperv.o

 QEMU_CFLAGS += $(VNC_TLS_CFLAGS)
 QEMU_CFLAGS += $(VNC_SASL_CFLAGS)
diff --git a/target-i386/hyperv.h b/target-i386/hyperv.h
index 15467bf..bacb1d4 100644
--- a/target-i386/hyperv.h
+++ b/target-i386/hyperv.h
@@ -14,7 +14,9 @@
 #define QEMU_HW_HYPERV_H 1

 #include "qemu-common.h"
+#ifdef CONFIG_KVM
 #include 
+#endif

 #ifndef HYPERV_SPINLOCK_NEVER_RETRY
 #define HYPERV_SPINLOCK_NEVER_RETRY 0x
@@ -24,7 +26,7 @@
 #define KVM_CPUID_SIGNATURE_NEXT0x4100
 #endif

-#ifndef CONFIG_USER_ONLY
+#if !defined(CONFIG_USER_ONLY) && defined(CONFIG_KVM)
 void hyperv_enable_vapic_recommended(bool val);
 void hyperv_enable_relaxed_timing(bool val);
 void hyperv_set_spinlock_retries(int val);
-- 
1.7.9.rc0

Re: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

[Vadim Rozenfeld]

This code is slightly buggy.
Please try Yan's repository
at github (https://github.com/YanVugenfirer/).
I believe that the most critical changes
have been merged already by Yan into this
public repository.
I will ask to update binaries and sources at
fedoraproject site as well.

Best regards,
Vadim.


- Original Message -
From: "Charles.Tsai-蔡清海-研究發展部" 
To: "Vadim Rozenfeld" 
Cc: "Michael Roth" , "Stefan Hajnoczi" 
, spice-de...@lists.freedesktop.org, "Alex Huang-黃必賢-研究發展部" 
, "Alon Levy" , "qemu-devel" 

Sent: Friday, January 20, 2012 3:25:51 AM
Subject: RE: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 
0.15

Vadim,

We downloaded the driver source from the following website.
===
wget --no-check-certificate 
https://alt.fedoraproject.org/pub/alt/virtio-win/latest/images/src/virtio-win-prewhql-0.1-15-sources.zip

-Original Message-
From: Vadim Rozenfeld [mailto:vroze...@redhat.com]
Sent: Thursday, January 19, 2012 8:25 PM
To: Charles.Tsai-蔡清海-研究發展部
Cc: Michael Roth; Stefan Hajnoczi; spice-de...@lists.freedesktop.org; Alex 
Huang-黃必賢-研究發展部; Alon Levy; qemu-devel
Subject: Re: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 
0.15

Just to be sure that we are on the same page:
could you tell me about the origin of the source?
Is it the latest from the Yan's repository at github.com?

- Original Message -
From: "Charles.Tsai-蔡清海-研究發展部" 
To: "Vadim Rozenfeld" 
Cc: "Michael Roth" , "Stefan Hajnoczi" 
, spice-de...@lists.freedesktop.org, "Alex Huang-黃必賢-研究發展部" 
, "Alon Levy" , "qemu-devel" 

Sent: Thursday, January 19, 2012 12:06:16 PM
Subject: RE: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 
0.15

Vadim,

We built it from the driver source. Up to this moment, we always use the same 
binary to test Qemu.


-Original Message-
From: Vadim Rozenfeld [mailto:vroze...@redhat.com]
Sent: Thursday, January 19, 2012 5:39 PM
To: Charles.Tsai-蔡清海-研究發展部
Cc: Michael Roth; Stefan Hajnoczi; spice-de...@lists.freedesktop.org; Alex 
Huang-黃必賢-研究發展部; Alon Levy; qemu-devel
Subject: RE: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 
0.15

On Thu, 2012-01-19 at 16:33 +0800, Charles.Tsai-蔡清海-研究發展部 wrote:
> Vadim,
>
> It is SMP system.
What about vioserial driver itself?
did you build it from sources or is
it one, available through RHEL channels?

>
> -Original Message-
> From: Vadim Rozenfeld [mailto:vroze...@redhat.com]
> Sent: Thursday, January 19, 2012 3:58 PM
> To: Charles.Tsai-蔡清海-研究發展部
> Cc: Michael Roth; Stefan Hajnoczi; spice-de...@lists.freedesktop.org;
> Alex Huang-黃必賢-研究發展部; Alon Levy; qemu-devel
> Subject: RE: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS
> on Qemu 0.15
>
> On Thu, 2012-01-19 at 09:41 +0800, Charles.Tsai-蔡清海-研究發展部 wrote:
> > Vadim,
> >
> > I tested on Qemu 1.0.50. and found the VioSerial driver had problem to 
> > install on 64-bit Win7 guest.
> > During the driver installation, the system hung after the driver
> > being installed. After I rebooted the guest OS, the Vioserial driver work. 
> > The hang system seemed to be found only during the driver installation.
> >
> On UP or SMP system?
> >
> > -Original Message-
> > From: Vadim Rozenfeld [mailto:vroze...@redhat.com]
> > Sent: Wednesday, January 18, 2012 4:57 AM
> > To: Michael Roth
> > Cc: Charles.Tsai-蔡清海-研究發展部; Stefan Hajnoczi;
> > spice-de...@lists.freedesktop.org; Alex Huang-黃必賢-研究發展部; Alon Levy;
> > qemu-devel
> > Subject: Re: [Qemu-devel] [Spice-devel] Vioserial of Windows guest
> > OS on Qemu 0.15
> >
> > On Mon, 2012-01-16 at 19:50 -0600, Michael Roth wrote:
> > > On 01/15/2012 08:02 PM, Charles.Tsai-蔡清海-研究發展部 wrote:
> > > > Vadim,
> > > >
> > > > Thank you for your prompt reply. Here are the information for our test 
> > > > case.
> > > >
> > > >
> > > > 1) we use the following command line to launch the guest OS
> > > >
> > > >
> > > > /usr/bin/kvm -S -M pc-0.14 -enable-kvm -m 1024 -smp
> > > > 1,sockets=1,cores=1,threads=1 -name win_xp -uuid
> > > > d9388815-ddd3-c38e-33c2-a9d5fcc7a775 -nodefconfig -nodefaults
> > > > -chardev
> > > > socket,id=charmonitor,path=/var/lib/libvirt/qemu/win_xp.monitor,
> > > > se rv er,nowait -mon
> > > > chardev=charmonitor,id=monitor,mode=readline
> > > > -rtc base=localtime
> > > > -device
> > > > virtio-serial-pci,id=virtio-serial0,bus=pci.0,multifunction=on,a
> > > &

Re: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

[Vadim Rozenfeld]

Just to be sure that we are on the same page:
could you tell me about the origin of the source?
Is it the latest from the Yan's repository at github.com?

- Original Message -
From: "Charles.Tsai-蔡清海-研究發展部" 
To: "Vadim Rozenfeld" 
Cc: "Michael Roth" , "Stefan Hajnoczi" 
, spice-de...@lists.freedesktop.org, "Alex Huang-黃必賢-研究發展部" 
, "Alon Levy" , "qemu-devel" 

Sent: Thursday, January 19, 2012 12:06:16 PM
Subject: RE: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 
0.15

Vadim,

We built it from the driver source. Up to this moment, we always use the same 
binary to test Qemu.


-Original Message-
From: Vadim Rozenfeld [mailto:vroze...@redhat.com]
Sent: Thursday, January 19, 2012 5:39 PM
To: Charles.Tsai-蔡清海-研究發展部
Cc: Michael Roth; Stefan Hajnoczi; spice-de...@lists.freedesktop.org; Alex 
Huang-黃必賢-研究發展部; Alon Levy; qemu-devel
Subject: RE: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 
0.15

On Thu, 2012-01-19 at 16:33 +0800, Charles.Tsai-蔡清海-研究發展部 wrote:
> Vadim,
>
> It is SMP system.
What about vioserial driver itself?
did you build it from sources or is
it one, available through RHEL channels?

>
> -Original Message-
> From: Vadim Rozenfeld [mailto:vroze...@redhat.com]
> Sent: Thursday, January 19, 2012 3:58 PM
> To: Charles.Tsai-蔡清海-研究發展部
> Cc: Michael Roth; Stefan Hajnoczi; spice-de...@lists.freedesktop.org;
> Alex Huang-黃必賢-研究發展部; Alon Levy; qemu-devel
> Subject: RE: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS
> on Qemu 0.15
>
> On Thu, 2012-01-19 at 09:41 +0800, Charles.Tsai-蔡清海-研究發展部 wrote:
> > Vadim,
> >
> > I tested on Qemu 1.0.50. and found the VioSerial driver had problem to 
> > install on 64-bit Win7 guest.
> > During the driver installation, the system hung after the driver
> > being installed. After I rebooted the guest OS, the Vioserial driver work. 
> > The hang system seemed to be found only during the driver installation.
> >
> On UP or SMP system?
> >
> > -Original Message-
> > From: Vadim Rozenfeld [mailto:vroze...@redhat.com]
> > Sent: Wednesday, January 18, 2012 4:57 AM
> > To: Michael Roth
> > Cc: Charles.Tsai-蔡清海-研究發展部; Stefan Hajnoczi;
> > spice-de...@lists.freedesktop.org; Alex Huang-黃必賢-研究發展部; Alon Levy;
> > qemu-devel
> > Subject: Re: [Qemu-devel] [Spice-devel] Vioserial of Windows guest
> > OS on Qemu 0.15
> >
> > On Mon, 2012-01-16 at 19:50 -0600, Michael Roth wrote:
> > > On 01/15/2012 08:02 PM, Charles.Tsai-蔡清海-研究發展部 wrote:
> > > > Vadim,
> > > >
> > > > Thank you for your prompt reply. Here are the information for our test 
> > > > case.
> > > >
> > > >
> > > > 1) we use the following command line to launch the guest OS
> > > >
> > > >
> > > > /usr/bin/kvm -S -M pc-0.14 -enable-kvm -m 1024 -smp
> > > > 1,sockets=1,cores=1,threads=1 -name win_xp -uuid
> > > > d9388815-ddd3-c38e-33c2-a9d5fcc7a775 -nodefconfig -nodefaults
> > > > -chardev
> > > > socket,id=charmonitor,path=/var/lib/libvirt/qemu/win_xp.monitor,
> > > > se rv er,nowait -mon
> > > > chardev=charmonitor,id=monitor,mode=readline
> > > > -rtc base=localtime
> > > > -device
> > > > virtio-serial-pci,id=virtio-serial0,bus=pci.0,multifunction=on,a
> > > > dd
> > > > r=
> > > > 0x5.0x0 -drive
> > > > file=/media/Images/Windows-XP.img,if=none,id=drive-ide0-0-0,form
> > > > at
> > > > =r
> > > > aw -device
> > > > ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,boot
> > > > in
> > > > de
> > > > x=1
> > > > -netdev tap,fd=17,id=hostnet0
> > > > -device
> > > > rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:e8:dc:b1,bus=pci.0,
> > > > mu
> > > > lt
> > > > ifunction=on,addr=0x3.0x0
> > > > -chardev pty,id=charserial0
> > > > -device isa-serial,chardev=charserial0,id=serial0
> > > > -chardev spicevmc,id=charchannel0,name=vdagent
> > > > -device
> > > > virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id
> > > > =c
> > > > ha
> > > > nnel0,name=com.redhat.spice.0
> > > > -usb -device usb-tablet,id=input0 -spice
> > > > port=5900,addr=0.0.0.0,disable-ticketing
> > > > -vga qxl -global qxl-vga.vram_size=67108864 -device
> > > > virtio-balloon-pci,id=balloon0,bus=pci.0,multifunction=on,addr=0
> > >

[Qemu-devel] [PATCH] hyper-v. Fix broken build due to missing references. All credits go to Jan Kiszka, who reported and fixed this issue.

[Vadim Rozenfeld]

---
 target-i386/hyperv.h |6 ++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/target-i386/hyperv.h b/target-i386/hyperv.h
index 0d742f8..15467bf 100644
--- a/target-i386/hyperv.h
+++ b/target-i386/hyperv.h
@@ -24,9 +24,15 @@
 #define KVM_CPUID_SIGNATURE_NEXT0x4100
 #endif
 
+#ifndef CONFIG_USER_ONLY
 void hyperv_enable_vapic_recommended(bool val);
 void hyperv_enable_relaxed_timing(bool val);
 void hyperv_set_spinlock_retries(int val);
+#else
+static inline void hyperv_enable_vapic_recommended(bool val) { }
+static inline void hyperv_enable_relaxed_timing(bool val) { }
+static inline void hyperv_set_spinlock_retries(int val) { }
+#endif
 
 bool hyperv_enabled(void);
 bool hyperv_hypercall_available(void);
-- 
1.7.4.4

Re: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

[Vadim Rozenfeld]

On Thu, 2012-01-19 at 16:33 +0800, Charles.Tsai-蔡清海-研究發展部 wrote:
> Vadim,
> 
> It is SMP system.
What about vioserial driver itself? 
did you build it from sources or is
it one, available through RHEL channels?

> 
> -Original Message-
> From: Vadim Rozenfeld [mailto:vroze...@redhat.com] 
> Sent: Thursday, January 19, 2012 3:58 PM
> To: Charles.Tsai-蔡清海-研究發展部
> Cc: Michael Roth; Stefan Hajnoczi; spice-de...@lists.freedesktop.org; Alex 
> Huang-黃必賢-研究發展部; Alon Levy; qemu-devel
> Subject: RE: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 
> 0.15
> 
> On Thu, 2012-01-19 at 09:41 +0800, Charles.Tsai-蔡清海-研究發展部 wrote:
> > Vadim,
> > 
> > I tested on Qemu 1.0.50. and found the VioSerial driver had problem to 
> > install on 64-bit Win7 guest.
> > During the driver installation, the system hung after the driver being 
> > installed. After I rebooted the guest OS, the Vioserial driver work. The 
> > hang system seemed to be found only during the driver installation.
> > 
> On UP or SMP system?
> > 
> > -Original Message-
> > From: Vadim Rozenfeld [mailto:vroze...@redhat.com]
> > Sent: Wednesday, January 18, 2012 4:57 AM
> > To: Michael Roth
> > Cc: Charles.Tsai-蔡清海-研究發展部; Stefan Hajnoczi; 
> > spice-de...@lists.freedesktop.org; Alex Huang-黃必賢-研究發展部; Alon Levy; 
> > qemu-devel
> > Subject: Re: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS 
> > on Qemu 0.15
> > 
> > On Mon, 2012-01-16 at 19:50 -0600, Michael Roth wrote:
> > > On 01/15/2012 08:02 PM, Charles.Tsai-蔡清海-研究發展部 wrote:
> > > > Vadim,
> > > >
> > > > Thank you for your prompt reply. Here are the information for our test 
> > > > case.
> > > >
> > > >
> > > > 1) we use the following command line to launch the guest OS
> > > >
> > > >
> > > > /usr/bin/kvm -S -M pc-0.14 -enable-kvm -m 1024 -smp
> > > > 1,sockets=1,cores=1,threads=1 -name win_xp -uuid
> > > > d9388815-ddd3-c38e-33c2-a9d5fcc7a775 -nodefconfig -nodefaults 
> > > > -chardev 
> > > > socket,id=charmonitor,path=/var/lib/libvirt/qemu/win_xp.monitor,se
> > > > rv er,nowait -mon chardev=charmonitor,id=monitor,mode=readline
> > > > -rtc base=localtime
> > > > -device
> > > > virtio-serial-pci,id=virtio-serial0,bus=pci.0,multifunction=on,add
> > > > r=
> > > > 0x5.0x0 -drive
> > > > file=/media/Images/Windows-XP.img,if=none,id=drive-ide0-0-0,format
> > > > =r
> > > > aw -device
> > > > ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootin
> > > > de
> > > > x=1
> > > > -netdev tap,fd=17,id=hostnet0
> > > > -device
> > > > rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:e8:dc:b1,bus=pci.0,mu
> > > > lt
> > > > ifunction=on,addr=0x3.0x0
> > > > -chardev pty,id=charserial0
> > > > -device isa-serial,chardev=charserial0,id=serial0
> > > > -chardev spicevmc,id=charchannel0,name=vdagent
> > > > -device
> > > > virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=c
> > > > ha
> > > > nnel0,name=com.redhat.spice.0
> > > > -usb -device usb-tablet,id=input0
> > > > -spice port=5900,addr=0.0.0.0,disable-ticketing
> > > > -vga qxl -global qxl-vga.vram_size=67108864 -device
> > > > virtio-balloon-pci,id=balloon0,bus=pci.0,multifunction=on,addr=0x4
> > > > .0
> > > > x0
> > > >
> > > >
> > > >
> > > > 2). In Guest Windows XP OS
> > > >
> > > >
> > > > When the following callback function of the vioserial device  is called 
> > > > in guest OS. The allocated resources is empty.
> > > >
> > > >
> > > > VIOSerialEvtDevicePrepareHardware() ---This function is to get the I/O 
> > > > address of the vioserial device and map the physical address to the 
> > > > logical address space.
> > > >
> > > > I added the following trace and the value of nListSize is ZERO.
> > > > TraceEvents(TRACE_LEVEL_INFORMATION, DBG_PNP, "%s 
> > > > (nListSize=%d)\n", __FUNCTION__,nListSize);
> > > >
> > > >
> > > > So far, we have tested Qemu 0.14 without any problem but Qemu 0.15 
> > > > seemed to be broken in vioserial device.
> > > > Let me know if you need further information. Thanks.
> > > >
> > 

Re: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

[Vadim Rozenfeld]

On Thu, 2012-01-19 at 09:41 +0800, Charles.Tsai-蔡清海-研究發展部 wrote:
> Vadim,
> 
> I tested on Qemu 1.0.50. and found the VioSerial driver had problem to 
> install on 64-bit Win7 guest.
> During the driver installation, the system hung after the driver being 
> installed. After I rebooted the
> guest OS, the Vioserial driver work. The hang system seemed to be found only 
> during the driver installation.
> 
On UP or SMP system?
> 
> -----Original Message-
> From: Vadim Rozenfeld [mailto:vroze...@redhat.com] 
> Sent: Wednesday, January 18, 2012 4:57 AM
> To: Michael Roth
> Cc: Charles.Tsai-蔡清海-研究發展部; Stefan Hajnoczi; 
> spice-de...@lists.freedesktop.org; Alex Huang-黃必賢-研究發展部; Alon Levy; qemu-devel
> Subject: Re: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 
> 0.15
> 
> On Mon, 2012-01-16 at 19:50 -0600, Michael Roth wrote:
> > On 01/15/2012 08:02 PM, Charles.Tsai-蔡清海-研究發展部 wrote:
> > > Vadim,
> > >
> > > Thank you for your prompt reply. Here are the information for our test 
> > > case.
> > >
> > >
> > > 1) we use the following command line to launch the guest OS
> > >
> > >
> > > /usr/bin/kvm -S -M pc-0.14 -enable-kvm -m 1024 -smp 
> > > 1,sockets=1,cores=1,threads=1 -name win_xp -uuid 
> > > d9388815-ddd3-c38e-33c2-a9d5fcc7a775 -nodefconfig -nodefaults 
> > > -chardev 
> > > socket,id=charmonitor,path=/var/lib/libvirt/qemu/win_xp.monitor,serv
> > > er,nowait -mon chardev=charmonitor,id=monitor,mode=readline
> > > -rtc base=localtime
> > > -device 
> > > virtio-serial-pci,id=virtio-serial0,bus=pci.0,multifunction=on,addr=
> > > 0x5.0x0 -drive 
> > > file=/media/Images/Windows-XP.img,if=none,id=drive-ide0-0-0,format=r
> > > aw -device 
> > > ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootinde
> > > x=1
> > > -netdev tap,fd=17,id=hostnet0
> > > -device 
> > > rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:e8:dc:b1,bus=pci.0,mult
> > > ifunction=on,addr=0x3.0x0
> > > -chardev pty,id=charserial0
> > > -device isa-serial,chardev=charserial0,id=serial0
> > > -chardev spicevmc,id=charchannel0,name=vdagent
> > > -device 
> > > virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=cha
> > > nnel0,name=com.redhat.spice.0
> > > -usb -device usb-tablet,id=input0
> > > -spice port=5900,addr=0.0.0.0,disable-ticketing
> > > -vga qxl -global qxl-vga.vram_size=67108864 -device 
> > > virtio-balloon-pci,id=balloon0,bus=pci.0,multifunction=on,addr=0x4.0
> > > x0
> > >
> > >
> > >
> > > 2). In Guest Windows XP OS
> > >
> > >
> > > When the following callback function of the vioserial device  is called 
> > > in guest OS. The allocated resources is empty.
> > >
> > >
> > > VIOSerialEvtDevicePrepareHardware() ---This function is to get the I/O 
> > > address of the vioserial device and map the physical address to the 
> > > logical address space.
> > >
> > > I added the following trace and the value of nListSize is ZERO.
> > > TraceEvents(TRACE_LEVEL_INFORMATION, DBG_PNP, "%s (nListSize=%d)\n", 
> > > __FUNCTION__,nListSize);
> > >
> > >
> > > So far, we have tested Qemu 0.14 without any problem but Qemu 0.15 seemed 
> > > to be broken in vioserial device.
> > > Let me know if you need further information. Thanks.
> > >
> > 
> > Hi Charles,
> > 
> > What versions of the virtio-win drivers are you using?
> > 
> > I've been testing virtio-serial on windows using the latest qemu.git 
> > (1.0). Linux guests work fine, but I've been having various issues 
> > with Windows 7, XP SP3, and Server 2008 R1. XP SP3 works 
> > intermittently for me using RHEL6.0 virtio-win, as well as the drivers at:
> > 
> 
> I have seen some virtio serial port initialization problems on 1.0.50.
> Will try to look into this problem in the following week(s).
> 
> > http://alt.fedoraproject.org/pub/alt/virtio-win/latest/images/bin/
> > 
> > But I've been getting a mix of issues such as guest hangs, vioser-test 
> > failing to enumerate any virtio-serial devices, or various 
> > non-critical error messages from qemu that seem to coincide with the 
> > channel being open/closed (occasionally resulting in the channel becoming 
> > unresponsive).
> > 
> > Do any of these seem similar to the behaviour you're seeing? If so 
> > I'll see if the issues go away on 0.14.0 and follow-up with a git bisect.
> > 
> 
> 
> 

Re: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

[Vadim Rozenfeld]

On Mon, 2012-01-16 at 19:50 -0600, Michael Roth wrote:
> On 01/15/2012 08:02 PM, Charles.Tsai-蔡清海-研究發展部 wrote:
> > Vadim,
> >
> > Thank you for your prompt reply. Here are the information for our test case.
> >
> >
> > 1) we use the following command line to launch the guest OS
> >
> >
> > /usr/bin/kvm -S -M pc-0.14 -enable-kvm -m 1024 -smp 
> > 1,sockets=1,cores=1,threads=1 -name win_xp -uuid 
> > d9388815-ddd3-c38e-33c2-a9d5fcc7a775 -nodefconfig -nodefaults -chardev 
> > socket,id=charmonitor,path=/var/lib/libvirt/qemu/win_xp.monitor,server,nowait
> > -mon chardev=charmonitor,id=monitor,mode=readline
> > -rtc base=localtime
> > -device 
> > virtio-serial-pci,id=virtio-serial0,bus=pci.0,multifunction=on,addr=0x5.0x0
> > -drive 
> > file=/media/Images/Windows-XP.img,if=none,id=drive-ide0-0-0,format=raw
> > -device 
> > ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1
> > -netdev tap,fd=17,id=hostnet0
> > -device 
> > rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:e8:dc:b1,bus=pci.0,multifunction=on,addr=0x3.0x0
> > -chardev pty,id=charserial0
> > -device isa-serial,chardev=charserial0,id=serial0
> > -chardev spicevmc,id=charchannel0,name=vdagent
> > -device 
> > virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0
> > -usb -device usb-tablet,id=input0
> > -spice port=5900,addr=0.0.0.0,disable-ticketing
> > -vga qxl -global qxl-vga.vram_size=67108864 -device 
> > virtio-balloon-pci,id=balloon0,bus=pci.0,multifunction=on,addr=0x4.0x0
> >
> >
> >
> > 2). In Guest Windows XP OS
> >
> >
> > When the following callback function of the vioserial device  is called in 
> > guest OS. The allocated resources is empty.
> >
> >
> > VIOSerialEvtDevicePrepareHardware() ---This function is to get the I/O 
> > address of the vioserial device and map the physical address to the logical 
> > address space.
> >
> > I added the following trace and the value of nListSize is ZERO.
> > TraceEvents(TRACE_LEVEL_INFORMATION, DBG_PNP, "%s (nListSize=%d)\n", 
> > __FUNCTION__,nListSize);
> >
> >
> > So far, we have tested Qemu 0.14 without any problem but Qemu 0.15 seemed 
> > to be broken in vioserial device.
> > Let me know if you need further information. Thanks.
> >
> 
> Hi Charles,
> 
> What versions of the virtio-win drivers are you using?
> 
> I've been testing virtio-serial on windows using the latest qemu.git 
> (1.0). Linux guests work fine, but I've been having various issues with 
> Windows 7, XP SP3, and Server 2008 R1. XP SP3 works intermittently for 
> me using RHEL6.0 virtio-win, as well as the drivers at:
> 

I have seen some virtio serial port initialization problems on 1.0.50.
Will try to look into this problem in the following week(s).

> http://alt.fedoraproject.org/pub/alt/virtio-win/latest/images/bin/
> 
> But I've been getting a mix of issues such as guest hangs, vioser-test 
> failing to enumerate any virtio-serial devices, or various non-critical 
> error messages from qemu that seem to coincide with the channel being 
> open/closed (occasionally resulting in the channel becoming unresponsive).
> 
> Do any of these seem similar to the behaviour you're seeing? If so I'll 
> see if the issues go away on 0.14.0 and follow-up with a git bisect.
> 

Re: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

[Vadim Rozenfeld]

On Tue, 2012-01-17 at 10:03 +0800, Charles.Tsai-蔡清海-研究發展部 wrote:
> Vadim,
> 
> I am sorry that it was my mistake because I did not see there was a PIC 
> device which was  created with no  device driver installed.
> Instead of updating the driver, I ran the hardware installation wizard to 
> install the Vioserial driver.
> As such, the system  could not install the device for me since it was taken 
> over by another device already.
> Thank you for your help and I learned a lot about how a hardware device is 
> virtualized by Qemu.
> 

You're welcome.
Vadim.
 
> 
> -Original Message-
> From: Vadim Rozenfeld [mailto:vroze...@redhat.com] 
> Sent: Tuesday, January 17, 2012 5:28 AM
> To: Charles.Tsai-蔡清海-研究發展部
> Cc: Stefan Hajnoczi; Alon Levy; spice-de...@lists.freedesktop.org; Alex 
> Huang-黃必賢-研究發展部; qemu-devel
> Subject: RE: [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15
> 
> On Mon, 2012-01-16 at 17:17 +0800, Charles.Tsai-蔡清海-研究發展部 wrote:
> > Vadim,
> > 
> > I just ran the Qemu monitor to get the PCI information. The information is 
> > listed belowe.
> > From the listed information, I did not see anything wrong with the BAR0.
> > ---
> Thank you.
> 
> > > 
> > > 2). In Guest Windows XP OS
> > >
> SP3?
> Can you try reproducing this problem on Win7?
> 
> Best regards,
> Vadim. 
> 
> 

Re: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

[Vadim Rozenfeld]

On Mon, 2012-01-16 at 17:17 +0800, Charles.Tsai-蔡清海-研究發展部 wrote:
> Vadim,
> 
> I just ran the Qemu monitor to get the PCI information. The information is 
> listed belowe.
> From the listed information, I did not see anything wrong with the BAR0.
> ---
Thank you.

> > 
> > 2). In Guest Windows XP OS
> >
SP3?
Can you try reproducing this problem on Win7?

Best regards,
Vadim. 

Re: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

[Vadim Rozenfeld]

On Mon, 2012-01-16 at 10:02 +0800, Charles.Tsai-蔡清海-研究發展部 wrote:
> Vadim,
> 
> Thank you for your prompt reply. Here are the information for our test case.
> 
> 
> 1) we use the following command line to launch the guest OS
> 
> 
> /usr/bin/kvm -S -M pc-0.14 -enable-kvm -m 1024 -smp 
> 1,sockets=1,cores=1,threads=1 -name win_xp -uuid 
> d9388815-ddd3-c38e-33c2-a9d5fcc7a775 -nodefconfig -nodefaults -chardev 
> socket,id=charmonitor,path=/var/lib/libvirt/qemu/win_xp.monitor,server,nowait
> -mon chardev=charmonitor,id=monitor,mode=readline
> -rtc base=localtime
> -device 
> virtio-serial-pci,id=virtio-serial0,bus=pci.0,multifunction=on,addr=0x5.0x0
> -drive file=/media/Images/Windows-XP.img,if=none,id=drive-ide0-0-0,format=raw
> -device 
> ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1
> -netdev tap,fd=17,id=hostnet0
> -device 
> rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:e8:dc:b1,bus=pci.0,multifunction=on,addr=0x3.0x0
> -chardev pty,id=charserial0
> -device isa-serial,chardev=charserial0,id=serial0
> -chardev spicevmc,id=charchannel0,name=vdagent
> -device 
> virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0
> -usb -device usb-tablet,id=input0
> -spice port=5900,addr=0.0.0.0,disable-ticketing
> -vga qxl -global qxl-vga.vram_size=67108864 -device 
> virtio-balloon-pci,id=balloon0,bus=pci.0,multifunction=on,addr=0x4.0x0
> 
> 
> 
> 2). In Guest Windows XP OS
> 
> 
> When the following callback function of the vioserial device  is called in 
> guest OS. The allocated resources is empty.
> 
> 
> VIOSerialEvtDevicePrepareHardware() ---This function is to get the I/O 
> address of the vioserial device and map the physical address to the logical 
> address space.
> 
> I added the following trace and the value of nListSize is ZERO.
> TraceEvents(TRACE_LEVEL_INFORMATION, DBG_PNP, "%s (nListSize=%d)\n", 
> __FUNCTION__,nListSize); 
> 
> 
> So far, we have tested Qemu 0.14 without any problem but Qemu 0.15 seemed to 
> be broken in vioserial device.
> Let me know if you need further information. Thanks.
> 
Hi Charles,
You're right. 
If WdfCmResourceListGetCount returns zero, 
it must be a problem with resources list.
Output of "info pci" and "info qtree" commands
could be helpful in analyzing this problem.

Best regards,
Vadim.
> 
> 
> 
> -Original Message-
> From: Vadim Rozenfeld [mailto:vroze...@redhat.com] 
> Sent: Sunday, January 15, 2012 7:42 PM
> To: Stefan Hajnoczi
> Cc: Charles.Tsai-蔡清海-研究發展部; Alon Levy; spice-de...@lists.freedesktop.org; 
> Alex Huang-黃必賢-研究發展部; qemu-devel
> Subject: Re: [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15
> 
> On Sun, 2012-01-15 at 11:27 +, Stefan Hajnoczi wrote:
> > 2012/1/14 Charles.Tsai-蔡清海-研究發展部 :
> > >I tested Qemu 0.15 for Windows XP guest OS. But I found that the 
> > > Virtual Serial I/O driver failed in driver initialization.
> > >The root cause of this problem is because the hardware 
> > > resources(I/O in this device) is not allocated to the virtual serial I/O.
> > >When I debugged on the vioserial driver, no hardware resource 
> > > actually is allocated to this device.
> > >This bug seems to be in the area of Qemu. Do you know whom I can 
> > > consult to fix this problem? Please let me know if you know the group or 
> > > the person.
> > 
> > I have CCed Vadim (virtio Windows driver) and the QEMU mailing list.
> > 
> > Please post your QEMU command-line so we can see how the guest is 
> > configured.
> > 
> > You mentioned that you debugged the driver and hardware resources 
> > weren't allocated.  Do you have a virtio PCI device inside the guest 
> > for this virtio-serial device?  Were you able to tell which part of 
> > driver initialization failed (finding the PCI device, mapping its 
> > resources (BARs), etc)?
> > 
> > Stefan
> 
> Could you post "pci info" output?
> 
> thanks,
> Vadim.
> 

Re: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

[Vadim Rozenfeld]

On Sun, 2012-01-15 at 11:27 +, Stefan Hajnoczi wrote:
> 2012/1/14 Charles.Tsai-蔡清海-研究發展部 :
> >I tested Qemu 0.15 for Windows XP guest OS. But I found that the 
> > Virtual Serial I/O driver failed in driver initialization.
> >The root cause of this problem is because the hardware resources(I/O 
> > in this device) is not allocated to the virtual serial I/O.
> >When I debugged on the vioserial driver, no hardware resource 
> > actually is allocated to this device.
> >This bug seems to be in the area of Qemu. Do you know whom I can 
> > consult to fix this problem? Please let me know if you know the group or 
> > the person.
> 
> I have CCed Vadim (virtio Windows driver) and the QEMU mailing list.
> 
> Please post your QEMU command-line so we can see how the guest is configured.
> 
> You mentioned that you debugged the driver and hardware resources
> weren't allocated.  Do you have a virtio PCI device inside the guest
> for this virtio-serial device?  Were you able to tell which part of
> driver initialization failed (finding the PCI device, mapping its
> resources (BARs), etc)?
> 
> Stefan

Could you post "pci info" output?

thanks,
Vadim.

Re: [Qemu-devel] KVM call agenda for Tuesday 3

[Vadim Rozenfeld]

On Tue, 2012-01-03 at 13:12 +, Stefan Hajnoczi wrote:
> On Tue, Jan 3, 2012 at 12:15 PM, Dor Laor  wrote:
> > On 01/03/2012 10:33 AM, Stefan Hajnoczi wrote:
> >>
> >> On Mon, Jan 02, 2012 at 01:09:40PM +0100, Juan Quintela wrote:
> >>>
> >>> Please send in any agenda items you are interested in covering.
> >>
> >>
> >> Status of virtio drivers for Windows:
> >>  * Unsupported in community today
> >
> >
> > Why?
> 
> Because there is no one around to answer questions or look into bugs
> in a timely manner.
> 
> I'm not saying that virtio Windows drivers are unsupported, I'm saying
> that the _QEMU community_ isn't supporting them if you look at the
> mailing list and bug tracker activity.  Perhaps we should direct
> questions about the virtio drivers to some place?  I've already been
> CCing and bouncing questions from users to Vadim for several months.
> 
> >>  * Bugs languish on bug tracker/mailing list
> >
> >
> > There are 1.2 developers on them and Vadim does the enlightenment support
> > for kvm too. I don't see plenty of issues that are currently actively, open,
> > can you point us to such?
> 
> Yes, this is exactly the point.  Vadim is doing a great job but he's
> only 1 person.  Having 1.2 people that handle virtio Windows driver
> means the bus factor is dangerous and we cannot scale.
> 
> The bug that brought this to mind again:
> https://bugs.launchpad.net/qemu/+bug/818673
> 
> Another email thread on virtio-balloon driver issues (looks unsolved):
> http://lists.gnu.org/archive/html/qemu-devel/2011-10/msg01240.html
> 
> > There is a legal issue w/ WHQL drivers but self sign is not a probably and I
> > believe that's what we have today.
> 
> For a user anything other than first-class native drivers is a red
> flag that this software may work poorly - on modern Windows that means
> properly signed drivers.
> 
> Although signing might seem like a secondary issue I think it's what
> actually has stopped us from growing a community around the virtio
> Windows drivers.  There are very few people who can help because a
> development environment where you can only contribute patches but not
> build the code fully takes the fun away.
> 
> Basically I'm asking: is there a way we can do the virtio Windows
> driver development more in public, in the community, so that we will
> grow stronger in KVM Windows guest support?
> 
More QA resources for WHQL testing against upstream QEMU and KVM, and
different distributions, including Fedora, Ubuntu, etc. And one more
Software Engineer/Software Engineer In Test who will be in touch with
community.

Cheers,
Vadim.
> How do we bootstrap this into more than 1.2 people who can hack on and
> help with guest drivers?
> 
> My suggestions are for those already involved to actively join IRC,
> mailing list, and bug tracker so they can pass on their knowledge and
> watch for questions.  Also, if there are known bugs and TODOs then
> please post them so folks with time and interest can help get them
> fixed.
> 
> Stefan

[Qemu-devel] [PATCH RFC v3 2/2] hyper-v: initialize Hyper-V CPUID leaves.

[Vadim Rozenfeld]

---
 target-i386/kvm.c |   65 +++-
 1 files changed, 63 insertions(+), 2 deletions(-)

diff --git a/target-i386/kvm.c b/target-i386/kvm.c
index 9080996..731cc8d 100644
--- a/target-i386/kvm.c
+++ b/target-i386/kvm.c
@@ -29,6 +29,7 @@
 #include "hw/pc.h"
 #include "hw/apic.h"
 #include "ioport.h"
+#include "hyperv.h"
 
 //#define DEBUG_KVM
 
@@ -381,11 +382,16 @@ int kvm_arch_init_vcpu(CPUState *env)
 cpuid_i = 0;
 
 /* Paravirtualization CPUIDs */
-memcpy(signature, "KVMKVMKVM\0\0\0", 12);
 c = &cpuid_data.entries[cpuid_i++];
 memset(c, 0, sizeof(*c));
 c->function = KVM_CPUID_SIGNATURE;
-c->eax = 0;
+if (!hyperv_enabled()) {
+memcpy(signature, "KVMKVMKVM\0\0\0", 12);
+c->eax = 0;
+} else {
+memcpy(signature, "Microsoft Hv", 12);
+c->eax = HYPERV_CPUID_MIN;
+}
 c->ebx = signature[0];
 c->ecx = signature[1];
 c->edx = signature[2];
@@ -396,6 +402,54 @@ int kvm_arch_init_vcpu(CPUState *env)
 c->eax = env->cpuid_kvm_features &
 kvm_arch_get_supported_cpuid(s, KVM_CPUID_FEATURES, 0, R_EAX);
 
+if (hyperv_enabled()) {
+memcpy(signature, "Hv#1\0\0\0\0\0\0\0\0", 12);
+c->eax = signature[0];
+
+c = &cpuid_data.entries[cpuid_i++];
+memset(c, 0, sizeof(*c));
+c->function = HYPERV_CPUID_VERSION;
+c->eax = 0x1bbc;
+c->ebx = 0x00060001;
+
+c = &cpuid_data.entries[cpuid_i++];
+memset(c, 0, sizeof(*c));
+c->function = HYPERV_CPUID_FEATURES;
+if (hyperv_relaxed_timing_enabled()) {
+c->eax |= HV_X64_MSR_HYPERCALL_AVAILABLE;
+}
+if (hyperv_vapic_recommended()) {
+c->eax |= HV_X64_MSR_HYPERCALL_AVAILABLE;
+c->eax |= HV_X64_MSR_APIC_ACCESS_AVAILABLE;
+}
+
+c = &cpuid_data.entries[cpuid_i++];
+memset(c, 0, sizeof(*c));
+c->function = HYPERV_CPUID_ENLIGHTMENT_INFO;
+if (hyperv_relaxed_timing_enabled()) {
+c->eax |= HV_X64_RELAXED_TIMING_RECOMMENDED;
+}
+if (hyperv_vapic_recommended()) {
+c->eax |= HV_X64_APIC_ACCESS_RECOMMENDED;
+}
+c->ebx = hyperv_get_spinlock_retries();
+
+c = &cpuid_data.entries[cpuid_i++];
+memset(c, 0, sizeof(*c));
+c->function = HYPERV_CPUID_IMPLEMENT_LIMITS;
+c->eax = 0x40;
+c->ebx = 0x40;
+
+c = &cpuid_data.entries[cpuid_i++];
+memset(c, 0, sizeof(*c));
+c->function = KVM_CPUID_SIGNATURE_NEXT;
+memcpy(signature, "KVMKVMKVM\0\0\0", 12);
+c->eax = 0;
+c->ebx = signature[0];
+c->ecx = signature[1];
+c->edx = signature[2];
+}
+
 has_msr_async_pf_en = c->eax & (1 << KVM_FEATURE_ASYNC_PF);
 
 cpu_x86_cpuid(env, 0, 0, &limit, &unused, &unused, &unused);
@@ -962,6 +1016,13 @@ static int kvm_put_msrs(CPUState *env, int level)
 kvm_msr_entry_set(&msrs[n++], MSR_KVM_ASYNC_PF_EN,
   env->async_pf_en_msr);
 }
+if (hyperv_hypercall_available()) {
+kvm_msr_entry_set(&msrs[n++], HV_X64_MSR_GUEST_OS_ID, 0);
+kvm_msr_entry_set(&msrs[n++], HV_X64_MSR_HYPERCALL, 0);
+}
+if (hyperv_vapic_recommended()) {
+kvm_msr_entry_set(&msrs[n++], HV_X64_MSR_APIC_ASSIST_PAGE, 0);
+}
 }
 if (env->mcg_cap) {
 int i;
-- 
1.7.4.4

[Qemu-devel] [PATCH RFC v3 1/2] hyper-v: introduce Hyper-V support infrastructure.

[Vadim Rozenfeld]

---
 Makefile.target  |2 +
 target-i386/cpuid.c  |   14 ++
 target-i386/hyperv.c |   65 ++
 target-i386/hyperv.h |   37 
 4 files changed, 118 insertions(+), 0 deletions(-)
 create mode 100644 target-i386/hyperv.c
 create mode 100644 target-i386/hyperv.h

diff --git a/Makefile.target b/Makefile.target
index 6e742c2..6245796 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -209,6 +209,8 @@ obj-$(CONFIG_NO_KVM) += kvm-stub.o
 obj-y += memory.o
 LIBS+=-lz
 
+obj-i386-y +=hyperv.o
+
 QEMU_CFLAGS += $(VNC_TLS_CFLAGS)
 QEMU_CFLAGS += $(VNC_SASL_CFLAGS)
 QEMU_CFLAGS += $(VNC_JPEG_CFLAGS)
diff --git a/target-i386/cpuid.c b/target-i386/cpuid.c
index 1e8bcff..4193df1 100644
--- a/target-i386/cpuid.c
+++ b/target-i386/cpuid.c
@@ -27,6 +27,8 @@
 #include "qemu-option.h"
 #include "qemu-config.h"
 
+#include "hyperv.h"
+
 /* feature flags taken from "Intel Processor Identification and the CPUID
  * Instruction" and AMD's "CPUID Specification".  In cases of disagreement
  * between feature naming conventions, aliases may be added.
@@ -716,6 +718,14 @@ static int cpu_x86_find_by_name(x86_def_t *x86_cpu_def, 
const char *cpu_model)
 goto error;
 }
 x86_cpu_def->tsc_khz = tsc_freq / 1000;
+} else if (!strcmp(featurestr, "hv_spinlocks")) {
+char *err;
+numvalue = strtoul(val, &err, 0);
+if (!*val || *err) {
+fprintf(stderr, "bad numerical value %s\n", val);
+goto error;
+}
+hyperv_set_spinlock_retries(numvalue);
 } else {
 fprintf(stderr, "unrecognized feature %s\n", featurestr);
 goto error;
@@ -724,6 +734,10 @@ static int cpu_x86_find_by_name(x86_def_t *x86_cpu_def, 
const char *cpu_model)
 check_cpuid = 1;
 } else if (!strcmp(featurestr, "enforce")) {
 check_cpuid = enforce_cpuid = 1;
+} else if (!strcmp(featurestr, "hv_relaxed")) {
+hyperv_enable_relaxed_timing(true);
+} else if (!strcmp(featurestr, "hv_vapic")) {
+hyperv_enable_vapic_recommended(true);
 } else {
 fprintf(stderr, "feature string `%s' not in format 
(+feature|-feature|feature=xyz)\n", featurestr);
 goto error;
diff --git a/target-i386/hyperv.c b/target-i386/hyperv.c
new file mode 100644
index 000..b2e57ad
--- /dev/null
+++ b/target-i386/hyperv.c
@@ -0,0 +1,65 @@
+/*
+ * QEMU Hyper-V support
+ *
+ * Copyright Red Hat, Inc. 2011
+ *
+ * Author: Vadim Rozenfeld 
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ *
+ */
+
+#include "hyperv.h"
+
+static bool hyperv_vapic;
+static bool hyperv_relaxed_timing;
+static int hyperv_spinlock_attempts = HYPERV_SPINLOCK_NEVER_RETRY;
+
+void hyperv_enable_vapic_recommended(bool val)
+{
+hyperv_vapic = val;
+}
+
+void hyperv_enable_relaxed_timing(bool val)
+{
+hyperv_relaxed_timing = val;
+}
+
+void hyperv_set_spinlock_retries(int val)
+{
+hyperv_spinlock_attempts = val;
+if (hyperv_spinlock_attempts < 0xFFF) {
+hyperv_spinlock_attempts = 0xFFF;
+}
+}
+
+bool hyperv_enabled(void)
+{
+return hyperv_hypercall_available() || hyperv_relaxed_timing_enabled();
+}
+
+bool hyperv_hypercall_available(void)
+{
+if (hyperv_vapic ||
+(hyperv_spinlock_attempts != HYPERV_SPINLOCK_NEVER_RETRY)) {
+  return true;
+}
+return false;
+}
+
+bool hyperv_vapic_recommended(void)
+{
+return hyperv_vapic;
+}
+
+bool hyperv_relaxed_timing_enabled(void)
+{
+return hyperv_relaxed_timing;
+}
+
+int hyperv_get_spinlock_retries(void)
+{
+return hyperv_spinlock_attempts;
+}
+
diff --git a/target-i386/hyperv.h b/target-i386/hyperv.h
new file mode 100644
index 000..0d742f8
--- /dev/null
+++ b/target-i386/hyperv.h
@@ -0,0 +1,37 @@
+/*
+ * QEMU Hyper-V support
+ *
+ * Copyright Red Hat, Inc. 2011
+ *
+ * Author: Vadim Rozenfeld 
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ *
+ */
+
+#ifndef QEMU_HW_HYPERV_H
+#define QEMU_HW_HYPERV_H 1
+
+#include "qemu-common.h"
+#include 
+
+#ifndef HYPERV_SPINLOCK_NEVER_RETRY
+#define HYPERV_SPINLOCK_NEVER_RETRY 0x
+#endif
+
+#ifndef KVM_CPUID_SIGNATURE_NEXT
+#define KVM_CPUID_SIGNATURE_NEXT0x4100
+#endif
+
+void hyperv_enable_vapic_recommended(bool val);
+void hyperv_enable_relaxed_timing(bool val);
+void hyperv_set_spinlock_retries(int val);
+
+bool hyperv_enabled(void);
+bool hyperv_hypercall_available(void);
+bool hyperv_vapic_recommended(void);
+bool hyperv_relaxed_timing_enabled(void);
+int hyperv_get_spinlock_retries(void);
+
+#endif /* QEMU_HW_HYPERV_H */
-- 
1.7.4.4

[Qemu-devel] [PATCH RFC v3 0/2] Initial support for Microsoft Hyper-V.

[Vadim Rozenfeld]

With the following series of patches we are starting to implement
some basic Microsoft Hyper-V Enlightenment functionality. This series
is mostly about adding support for relaxed timing, spinlock,
and virtual apic.

For more Hyper-V related information please see:
"Hypervisor Functional Specification v2.0: For Windows Server 2008 R2" at
http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=18673

Changelog:
 v3->v2
  - fix indention,
  - drop reading HV MSRs inside of kvm_get_msrs routine.
 v2->v1
  - remove KVM_CAP_IRQCHIP ifdef,
  - remove CONFIG_HYPERV config option,
  - move KVM leaves to new location (0x4100),
  - cosmetic changes.
 v0->v1
  - move hyper-v parameters under cpu category,
  - move hyper-v stuff to target-i386 directory,
  - make CONFIG_HYPERV enabled by default for
i386-softmmu and x86_64-softmmu configurations,
  - rearrange the patches from v0,
  - set HV_X64_MSR_HYPERCALL, HV_X64_MSR_GUEST_OS_ID,
and HV_X64_MSR_APIC_ASSIST_PAGE to 0 on system reset.


Vadim Rozenfeld (2):
  hyper-v: introduce Hyper-V support infrastructure.
  hyper-v: initialize Hyper-V CPUID leaves.

 Makefile.target  |2 +
 target-i386/cpuid.c  |   14 ++
 target-i386/hyperv.c |   65 ++
 target-i386/hyperv.h |   37 
 target-i386/kvm.c|   65 -
 5 files changed, 181 insertions(+), 2 deletions(-)
 create mode 100644 target-i386/hyperv.c
 create mode 100644 target-i386/hyperv.h

-- 
1.7.4.4

Re: [Qemu-devel] [PATCH 2/2] [PATCH RFC v2 2/2] hyper-v: initialize Hyper-V CPUID leaves.

[Vadim Rozenfeld]

On Thu, 2011-12-01 at 15:52 +0100, Jan Kiszka wrote:
> On 2011-10-23 17:39, Vadim Rozenfeld wrote:
> > ---
> >  target-i386/kvm.c |   73 
> > +++-
> >  1 files changed, 71 insertions(+), 2 deletions(-)
> > 
> > diff --git a/target-i386/kvm.c b/target-i386/kvm.c
> > index 82fec8c..c061e3b 100644
> > --- a/target-i386/kvm.c
> > +++ b/target-i386/kvm.c
> > @@ -29,6 +29,7 @@
> >  #include "hw/pc.h"
> >  #include "hw/apic.h"
> >  #include "ioport.h"
> > +#include "hyperv.h"
> >  
> >  //#define DEBUG_KVM
> >  
> > @@ -380,11 +381,16 @@ int kvm_arch_init_vcpu(CPUState *env)
> >  cpuid_i = 0;
> >  
> >  /* Paravirtualization CPUIDs */
> > -memcpy(signature, "KVMKVMKVM\0\0\0", 12);
> >  c = &cpuid_data.entries[cpuid_i++];
> >  memset(c, 0, sizeof(*c));
> >  c->function = KVM_CPUID_SIGNATURE;
> > -c->eax = 0;
> > +if (!hyperv_enabled()) {
> > +memcpy(signature, "KVMKVMKVM\0\0\0", 12);
> > +c->eax = 0;
> > +} else {
> > +memcpy(signature, "Microsoft Hv", 12);
> > +c->eax = HYPERV_CPUID_MIN;
> > +}
> >  c->ebx = signature[0];
> >  c->ecx = signature[1];
> >  c->edx = signature[2];
> > @@ -395,6 +401,54 @@ int kvm_arch_init_vcpu(CPUState *env)
> >  c->eax = env->cpuid_kvm_features &
> >  kvm_arch_get_supported_cpuid(s, KVM_CPUID_FEATURES, 0, R_EAX);
> >  
> > +if (hyperv_enabled()) {
> > +memcpy(signature, "Hv#1\0\0\0\0\0\0\0\0", 12);
> > +c->eax = signature[0];
> > +
> > +c = &cpuid_data.entries[cpuid_i++];
> > +memset(c, 0, sizeof(*c));
> > +c->function = HYPERV_CPUID_VERSION;
> > +c->eax = 0x1bbc;
> > +c->ebx = 0x00060001;
> > +
> > +c = &cpuid_data.entries[cpuid_i++];
> > +memset(c, 0, sizeof(*c));
> > +c->function = HYPERV_CPUID_FEATURES;
> > +if (hyperv_relaxed_timing_enabled()) {
> > +c->eax |= HV_X64_MSR_HYPERCALL_AVAILABLE;
> > +}
> > +if (hyperv_vapic_recommended()) {
> > +c->eax |= HV_X64_MSR_HYPERCALL_AVAILABLE;
> > +c->eax |= HV_X64_MSR_APIC_ACCESS_AVAILABLE;
> > +}
> > +
> > +c = &cpuid_data.entries[cpuid_i++];
> > +memset(c, 0, sizeof(*c));
> > +c->function = HYPERV_CPUID_ENLIGHTMENT_INFO;
> > +if (hyperv_relaxed_timing_enabled()) {
> > +c->eax |= HV_X64_RELAXED_TIMING_RECOMMENDED;
> > +}
> > +if (hyperv_vapic_recommended()) {
> > +c->eax |= HV_X64_APIC_ACCESS_RECOMMENDED;
> > +}
> > +c->ebx = hyperv_get_spinlock_retries();
> > +
> > +c = &cpuid_data.entries[cpuid_i++];
> > +memset(c, 0, sizeof(*c));
> > +c->function = HYPERV_CPUID_IMPLEMENT_LIMITS;
> > +c->eax = 0x40;
> > +c->ebx = 0x40;
> > +
> > +c = &cpuid_data.entries[cpuid_i++];
> > +memset(c, 0, sizeof(*c));
> > +c->function = KVM_CPUID_SIGNATURE_NEXT;
> > +memcpy(signature, "KVMKVMKVM\0\0\0", 12);
> > +c->eax = 0;
> > +c->ebx = signature[0];
> > +c->ecx = signature[1];
> > +c->edx = signature[2];
> > +}
> > +
> >  has_msr_async_pf_en = c->eax & (1 << KVM_FEATURE_ASYNC_PF);
> >  
> >  cpu_x86_cpuid(env, 0, 0, &limit, &unused, &unused, &unused);
> > @@ -953,6 +1007,13 @@ static int kvm_put_msrs(CPUState *env, int level)
> >  kvm_msr_entry_set(&msrs[n++], MSR_KVM_ASYNC_PF_EN,
> >env->async_pf_en_msr);
> >  }
> > +if (hyperv_hypercall_available()) {
> > +kvm_msr_entry_set(&msrs[n++], HV_X64_MSR_GUEST_OS_ID, 0);
> > +kvm_msr_entry_set(&msrs[n++], HV_X64_MSR_HYPERCALL, 0);
> > +}
> > +if (hyperv_vapic_recommended()) {
> > +kvm_msr_entry_set(&msrs[n++], HV_X64_MSR_APIC_ASSIST_PAGE, 0);
> > +}
> >  }
> >  if (env->mcg_cap) {
> >  int i;
> > @@ -1190,6 +1251,14 @@ static int kvm_get_msrs(CPUState *env)
> >  msrs[n++].index = MSR_KVM_ASYNC_PF_EN;
> >  }
> >  
> > +if (hyperv_hypercall_available()) {
> > +msrs[n++].index = HV_X64_MSR_GUEST_OS_ID;
> > +msrs[n++].index = HV_X64_MSR_HYPERCALL;
> > +}
> > +if (hyperv_vapic_recommended()) {
> > +msrs[n++].index = HV_X64_MSR_APIC_ASSIST_PAGE;
> > +}
> > +
> >  if (env->mcg_cap) {
> >  msrs[n++].index = MSR_MCG_STATUS;
> >  msrs[n++].index = MSR_MCG_CTL;
> 
> Not sure if we discussed this already: Is there no need to save/restore
> the HV MSR values in the vcpu structure? Specifcially kvm_get_msrs looks
> fishy as you request to read the state from the kernel but then simply
> ignore it.

You're right. We don't need to keep hyper-v msrs in the vcpu structure
at the moment. I will revert kvm_get_msrs changes back to the original
state.
Vadim. 
> 
> Jan
>