Re: [RFC QEMU PATCH v9 2/2] virtio-pci: implement No_Soft_Reset bit

[Yan Vugenfirer]

On Wed, Apr 17, 2024 at 6:13 AM Chen, Jiqian  wrote:
>
> On 2024/4/16 23:45, Igor Mammedov wrote:
> > On Tue, 16 Apr 2024 15:01:27 +0800
> > Jiqian Chen  wrote:
> >
> >> In current code, when guest does S3, virtio-gpu are reset due to the
> >> bit No_Soft_Reset is not set. After resetting, the display resources
> >> of virtio-gpu are destroyed, then the display can't come back and only
> >> show blank after resuming.
> >
> > Just a high level question.
> > Typically when system goes into S3 all devices (modulo RAM) loose context
> > (aka powered off), and then it's upto device driver to recover whatever
> > was lost.
> No, what you said is just one situation that when system goes into S3 devices 
> loose context and fully reinitialized and be D0-uninitialized state.
> The other situation is the context must be maintained so that the devices can 
> quickly be D0-active state after resuming.
> There are some descriptions in PCIe specification in Chapter 5.3.1.4 D3 state:
> " Functional context is required to be maintained by Functions in the D3Hot 
> state if the No_Soft_Reset field in the PMCSR is
> Set. In this case, System Software is not required to re-initialize the 
> Function after a transition from D3Hot to D0 (the
> Function will be in the D0active state). If the No_Soft_Reset bit is Clear, 
> functional context is not required to be
> maintained by the Function in the D3Hot state, however it is not guaranteed 
> that functional context will be cleared and
> software must not depend on such behavior. As a result, in this case System 
> Software is required to fully re-initialize the
> Function after a transition to D0 as the Function will be in the 
> D0uninitialized state."
>
BTW: according to Windows documentation D3 Hot state implementation is
a must for real HW devices.
https://learn.microsoft.com/en-us/windows-hardware/drivers/kernel/device-sleeping-states
"Device power states D1, D2, and D3 are the device low-power states.
Starting with Windows 8, D3 is divided into two substates, D3hot and
D3cold.

D1 and D2 are intermediate low-power states. Many classes of devices
do not define these states. All devices must define D3hot."

Best regards,
Yan.


> What's more, not all virtio devices' context can be recovered by driver after 
> resuming, like virtio-gpu, we have not enough information to re-create all
> display resources, that is discussed in my previous version email thread.
>
> > So why should we implement hw(qemu) workaround for a driver problem?
> I think this is not a workaround, No_Soft_Reset bit is also described in PCIe 
> specification, it can be set or not.
> And we can set this bit for the specific device which we want to maintain 
> context during S3.
>
> >
> >>
> >> Implement No_Soft_Reset bit of PCI_PM_CTRL register, then guest can check
> >> this bit, if this bit is set, the devices resetting will not be done, and
> >> then the display can work after resuming.
> >>
> >> No_Soft_Reset bit is implemented for all virtio devices, and was tested
> >> only on virtio-gpu device. Set it false by default for safety.
> >>
> >> Signed-off-by: Jiqian Chen 
> >> ---
> >>  hw/virtio/virtio-pci.c | 37 ++
> >>  include/hw/virtio/virtio-pci.h |  5 +
> >>  2 files changed, 42 insertions(+)
> >>
> >> diff --git a/hw/virtio/virtio-pci.c b/hw/virtio/virtio-pci.c
> >> index a1b61308e7a0..82fa4defe5cd 100644
> >> --- a/hw/virtio/virtio-pci.c
> >> +++ b/hw/virtio/virtio-pci.c
> >> @@ -2230,6 +2230,11 @@ static void virtio_pci_realize(PCIDevice *pci_dev, 
> >> Error **errp)
> >>  pcie_cap_lnkctl_init(pci_dev);
> >>  }
> >>
> >> +if (proxy->flags & VIRTIO_PCI_FLAG_PM_NO_SOFT_RESET) {
> >> +pci_set_word(pci_dev->config + pos + PCI_PM_CTRL,
> >> + PCI_PM_CTRL_NO_SOFT_RESET);
> >> +}
> >> +
> >>  if (proxy->flags & VIRTIO_PCI_FLAG_INIT_PM) {
> >>  /* Init Power Management Control Register */
> >>  pci_set_word(pci_dev->wmask + pos + PCI_PM_CTRL,
> >> @@ -2292,11 +2297,37 @@ static void virtio_pci_reset(DeviceState *qdev)
> >>  }
> >>  }
> >>
> >> +static bool virtio_pci_no_soft_reset(PCIDevice *dev)
> >> +{
> >> +uint16_t pmcsr;
> >> +
> >> +if (!pci_is_express(dev) || !dev->exp.pm_cap) {
> >> +return false;
> >> +}
> >> +
> >> +pmcsr = pci_get_word(dev->config + dev->exp.pm_cap + PCI_PM_CTRL);
> >> +
> >> +/*
> >> + * When No_Soft_Reset bit is set and the device
> >> + * is in D3hot state, don't reset device
> >> + */
> >> +return (pmcsr & PCI_PM_CTRL_NO_SOFT_RESET) &&
> >> +   (pmcsr & PCI_PM_CTRL_STATE_MASK) == 3;
> >> +}
> >> +
> >>  static void virtio_pci_bus_reset_hold(Object *obj)
> >>  {
> >>  PCIDevice *dev = PCI_DEVICE(obj);
> >>  DeviceState *qdev = DEVICE(obj);
> >>
> >> +/*
> >> + * Note that: a proposal to add SUSPEND bit is being discussed,
> >> + * may need to consider 

Re: [PATCH v9 13/20] virtio-net: Return an error when vhost cannot enable RSS

[Yan Vugenfirer]

On Mon, Apr 8, 2024 at 4:31 AM Akihiko Odaki  wrote:
>
> On 2024/04/08 6:46, Yuri Benditovich wrote:
> > On Wed, Apr 3, 2024 at 2:11 PM Akihiko Odaki  
> > wrote:
> >>
> >> vhost requires eBPF for RSS. When eBPF is not available, virtio-net
> >> implicitly disables RSS even if the user explicitly requests it. Return
> >> an error instead of implicitly disabling RSS if RSS is requested but not
> >> available.
> >>
> >> Signed-off-by: Akihiko Odaki 
> >> ---
> >>   hw/net/virtio-net.c | 97 
> >> ++---
> >>   1 file changed, 48 insertions(+), 49 deletions(-)
> >>
> >> diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
> >> index 61b49e335dea..3d53eba88cfc 100644
> >> --- a/hw/net/virtio-net.c
> >> +++ b/hw/net/virtio-net.c
> >> @@ -793,9 +793,6 @@ static uint64_t virtio_net_get_features(VirtIODevice 
> >> *vdev, uint64_t features,
> >>   return features;
> >>   }
> >>
> >> -if (!ebpf_rss_is_loaded(>ebpf_rss)) {
> >> -virtio_clear_feature(, VIRTIO_NET_F_RSS);
> >> -}
> >>   features = vhost_net_get_features(get_vhost_net(nc->peer), features);
> >>   vdev->backend_features = features;
> >>
> >> @@ -3591,6 +3588,50 @@ static bool 
> >> failover_hide_primary_device(DeviceListener *listener,
> >>   return qatomic_read(>failover_primary_hidden);
> >>   }
> >>
> >> +static void virtio_net_device_unrealize(DeviceState *dev)
> >> +{
> >> +VirtIODevice *vdev = VIRTIO_DEVICE(dev);
> >> +VirtIONet *n = VIRTIO_NET(dev);
> >> +int i, max_queue_pairs;
> >> +
> >> +if (virtio_has_feature(n->host_features, VIRTIO_NET_F_RSS)) {
> >> +virtio_net_unload_ebpf(n);
> >> +}
> >> +
> >> +/* This will stop vhost backend if appropriate. */
> >> +virtio_net_set_status(vdev, 0);
> >> +
> >> +g_free(n->netclient_name);
> >> +n->netclient_name = NULL;
> >> +g_free(n->netclient_type);
> >> +n->netclient_type = NULL;
> >> +
> >> +g_free(n->mac_table.macs);
> >> +g_free(n->vlans);
> >> +
> >> +if (n->failover) {
> >> +qobject_unref(n->primary_opts);
> >> +device_listener_unregister(>primary_listener);
> >> +migration_remove_notifier(>migration_state);
> >> +} else {
> >> +assert(n->primary_opts == NULL);
> >> +}
> >> +
> >> +max_queue_pairs = n->multiqueue ? n->max_queue_pairs : 1;
> >> +for (i = 0; i < max_queue_pairs; i++) {
> >> +virtio_net_del_queue(n, i);
> >> +}
> >> +/* delete also control vq */
> >> +virtio_del_queue(vdev, max_queue_pairs * 2);
> >> +qemu_announce_timer_del(>announce_timer, false);
> >> +g_free(n->vqs);
> >> +qemu_del_nic(n->nic);
> >> +virtio_net_rsc_cleanup(n);
> >> +g_free(n->rss_data.indirections_table);
> >> +net_rx_pkt_uninit(n->rx_pkt);
> >> +virtio_cleanup(vdev);
> >> +}
> >> +
> >>   static void virtio_net_device_realize(DeviceState *dev, Error **errp)
> >>   {
> >>   VirtIODevice *vdev = VIRTIO_DEVICE(dev);
> >> @@ -3760,53 +3801,11 @@ static void virtio_net_device_realize(DeviceState 
> >> *dev, Error **errp)
> >>
> >>   net_rx_pkt_init(>rx_pkt);
> >>
> >> -if (virtio_has_feature(n->host_features, VIRTIO_NET_F_RSS)) {
> >> -virtio_net_load_ebpf(n);
> >> -}
> >> -}
> >> -
> >> -static void virtio_net_device_unrealize(DeviceState *dev)
> >> -{
> >> -VirtIODevice *vdev = VIRTIO_DEVICE(dev);
> >> -VirtIONet *n = VIRTIO_NET(dev);
> >> -int i, max_queue_pairs;
> >> -
> >> -if (virtio_has_feature(n->host_features, VIRTIO_NET_F_RSS)) {
> >> -virtio_net_unload_ebpf(n);
> >> +if (virtio_has_feature(n->host_features, VIRTIO_NET_F_RSS) &&
> >
> > I disagree with this change of qemu behavior.
> >  From my point of view:
> > - this is not a major problem and it should not be a reason to stop VM 
> > execution
> > - it is enough to disable the RSS feature and continue working. Depending on
> >other qemu parameters (number of queues, number of cpus) this might be 
> > just
> >suboptimal. might be a minor problem and might be not a problem at all
>

I think the basic example is when the kernel doesn't support ebpf
loading (either old kernel or kernel that, for some security reason,
disabled the capability). In this case, we will get a behavior change.

Best regards,
Yan.

>
> The reasoning is that we shouldn't disable what the user explicitly
> requested. c.f.,
> https://lore.kernel.org/all/20231102091717-mutt-send-email-...@kernel.org/
>
> > - this change defines rss as _only_ feature whose absence breaks the VM 
> > start,
> >_all_ other features are dropped silently and only rss is not. Why??
>
> I'm following what QEMU does in the other places rather than what it
> does just in virtio-net. I have pointed out virtio-gpu raises errors in
> such a situation. c.f.,
> https://lore.kernel.org/all/8880b6f9-f556-46f7-a191-eeec0fe20...@daynix.com
>
> > - the series has a title 'Fixes and improvements' . This is not a 

Re: [PATCH v4 1/3] qga/commands-win32: Declare const qualifier before type

[Yan Vugenfirer]

On Mon, Mar 4, 2024 at 3:45 PM Konstantin Kostiuk  wrote:
>
> From: Philippe Mathieu-Daudé 
>
> Most of the code base use the 'const' qualifier *before*
> the type being qualified. Use the same style to unify.
>
> Signed-off-by: Philippe Mathieu-Daudé 
> Message-ID: <20240222152835.72095-2-phi...@linaro.org>
> Reviewed-by: Konstantin Kostiuk 
> Signed-off-by: Konstantin Kostiuk 
>
> ---
>  qga/commands-win32.c | 22 +++---
>  1 file changed, 11 insertions(+), 11 deletions(-)
>
> diff --git a/qga/commands-win32.c b/qga/commands-win32.c
> index a1015757d8..79b5a580c9 100644
> --- a/qga/commands-win32.c
> +++ b/qga/commands-win32.c
> @@ -2120,11 +2120,11 @@ GuestUserList *qmp_guest_get_users(Error **errp)
>  typedef struct _ga_matrix_lookup_t {
>  int major;
>  int minor;
> -char const *version;
> -char const *version_id;
> +const char *version;
> +const char *version_id;
>  } ga_matrix_lookup_t;
>
> -static ga_matrix_lookup_t const WIN_VERSION_MATRIX[2][7] = {
> +static const ga_matrix_lookup_t WIN_VERSION_MATRIX[2][7] = {
>  {
>  /* Desktop editions */
>  { 5, 0, "Microsoft Windows 2000",   "2000"},
> @@ -2148,18 +2148,18 @@ static ga_matrix_lookup_t const 
> WIN_VERSION_MATRIX[2][7] = {
>
>  typedef struct _ga_win_10_0_t {
>  int first_build;
> -char const *version;
> -char const *version_id;
> +const char *version;
> +const char *version_id;
>  } ga_win_10_0_t;
>
> -static ga_win_10_0_t const WIN_10_0_SERVER_VERSION_MATRIX[4] = {
> +static const ga_win_10_0_t WIN_10_0_SERVER_VERSION_MATRIX[4] = {
>  {14393, "Microsoft Windows Server 2016","2016"},
>  {17763, "Microsoft Windows Server 2019","2019"},
>  {20344, "Microsoft Windows Server 2022","2022"},
>  {0, 0}
>  };
>
> -static ga_win_10_0_t const WIN_10_0_CLIENT_VERSION_MATRIX[3] = {
> +static const ga_win_10_0_t WIN_10_0_CLIENT_VERSION_MATRIX[3] = {
>  {10240, "Microsoft Windows 10","10"},
>  {22000, "Microsoft Windows 11","11"},
>  {0, 0}
> @@ -2185,16 +2185,16 @@ static void ga_get_win_version(RTL_OSVERSIONINFOEXW 
> *info, Error **errp)
>  return;
>  }
>
> -static char *ga_get_win_name(OSVERSIONINFOEXW const *os_version, bool id)
> +static char *ga_get_win_name(const OSVERSIONINFOEXW *os_version, bool id)
>  {
>  DWORD major = os_version->dwMajorVersion;
>  DWORD minor = os_version->dwMinorVersion;
>  DWORD build = os_version->dwBuildNumber;
>  int tbl_idx = (os_version->wProductType != VER_NT_WORKSTATION);
> -ga_matrix_lookup_t const *table = WIN_VERSION_MATRIX[tbl_idx];
> -ga_win_10_0_t const *win_10_0_table = tbl_idx ?
> +const ga_matrix_lookup_t *table = WIN_VERSION_MATRIX[tbl_idx];
> +const ga_win_10_0_t *win_10_0_table = tbl_idx ?
>      WIN_10_0_SERVER_VERSION_MATRIX : WIN_10_0_CLIENT_VERSION_MATRIX;
> -ga_win_10_0_t const *win_10_0_version = NULL;
> +const ga_win_10_0_t *win_10_0_version = NULL;
>  while (table->version != NULL) {
>  if (major == 10 && minor == 0) {
>  while (win_10_0_table->version != NULL) {
> --
> 2.44.0
>

Reviewed-by: Yan Vugenfirer 

Re: [PATCH v4 3/3] qga-win: Add support of Windows Server 2025 in get-osinfo command

[Yan Vugenfirer]

On Mon, Mar 4, 2024 at 3:45 PM Konstantin Kostiuk  wrote:
>
> From: Dehan Meng 
>
> Add support of Windows Server 2025 in get-osinfo command
>
> Signed-off-by: Dehan Meng 
> Message-ID: <20240222152835.72095-4-phi...@linaro.org>
> Signed-off-by: Philippe Mathieu-Daudé 
> Reviewed-by: Konstantin Kostiuk 
> Signed-off-by: Konstantin Kostiuk 
> ---
>  qga/commands-win32.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/qga/commands-win32.c b/qga/commands-win32.c
> index a830f1494e..d1cf1a87db 100644
> --- a/qga/commands-win32.c
> +++ b/qga/commands-win32.c
> @@ -2153,6 +2153,7 @@ static const ga_win_10_0_t 
> WIN_10_0_SERVER_VERSION_MATRIX[] = {
>  {14393, "Microsoft Windows Server 2016","2016"},
>  {17763, "Microsoft Windows Server 2019","2019"},
>  {20344, "Microsoft Windows Server 2022",    "2022"},
> +{26040, "MIcrosoft Windows Server 2025","2025"},
>  { }
>  };
>
> --
> 2.44.0
>

Reviewed-by: Yan Vugenfirer 

Re: [PATCH v4 2/3] qga/commands-win32: Do not set matrix_lookup_t/win_10_0_t arrays size

[Yan Vugenfirer]

On Mon, Mar 4, 2024 at 3:45 PM Konstantin Kostiuk  wrote:
>
> From: Philippe Mathieu-Daudé 
>
> ga_get_win_name() iterates over all elements in the arrays by
> checking the 'version' field is non-NULL. Since the arrays are
> guarded by a NULL terminating element, we don't need to specify
> their size:
>
>   static char *ga_get_win_name(...)
>   {
>   ...
>   const ga_matrix_lookup_t *table = WIN_VERSION_MATRIX[tbl_idx];
>   const ga_win_10_0_t *win_10_0_table = ...
>   ...
>   while (table->version != NULL) {
> ^^^
>   while (win_10_0_table->version != NULL) {
>  ^^^
>
> This will simplify maintenance when adding new entries to these
> arrays.
>
> Split WIN_VERSION_MATRIX into WIN_CLIENT_VERSION_MATRIX and
> WIN_SERVER_VERSION_MATRIX because  multidimensional array must
> have bounds for all dimensions except the first.
>
> Signed-off-by: Philippe Mathieu-Daudé 
> Message-ID: <20240222152835.72095-3-phi...@linaro.org>
> Reviewed-by: Konstantin Kostiuk 
> Signed-off-by: Konstantin Kostiuk 
> ---
>  qga/commands-win32.c | 52 +---
>  1 file changed, 25 insertions(+), 27 deletions(-)
>
> diff --git a/qga/commands-win32.c b/qga/commands-win32.c
> index 79b5a580c9..a830f1494e 100644
> --- a/qga/commands-win32.c
> +++ b/qga/commands-win32.c
> @@ -2124,45 +2124,42 @@ typedef struct _ga_matrix_lookup_t {
>  const char *version_id;
>  } ga_matrix_lookup_t;
>
> -static const ga_matrix_lookup_t WIN_VERSION_MATRIX[2][7] = {
> -{
> -/* Desktop editions */
> -{ 5, 0, "Microsoft Windows 2000",   "2000"},
> -{ 5, 1, "Microsoft Windows XP", "xp"},
> -{ 6, 0, "Microsoft Windows Vista",  "vista"},
> -{ 6, 1, "Microsoft Windows 7"   "7"},
> -{ 6, 2, "Microsoft Windows 8",  "8"},
> -{ 6, 3, "Microsoft Windows 8.1","8.1"},
> -{ 0, 0, 0}
> -},{
> -/* Server editions */
> -{ 5, 2, "Microsoft Windows Server 2003","2003"},
> -{ 6, 0, "Microsoft Windows Server 2008","2008"},
> -{ 6, 1, "Microsoft Windows Server 2008 R2", "2008r2"},
> -{ 6, 2, "Microsoft Windows Server 2012","2012"},
> -{ 6, 3, "Microsoft Windows Server 2012 R2", "2012r2"},
> -{ 0, 0, 0},
> -{ 0, 0, 0}
> -}
> +static const ga_matrix_lookup_t WIN_CLIENT_VERSION_MATRIX[] = {
> +{ 5, 0, "Microsoft Windows 2000",   "2000"},
> +{ 5, 1, "Microsoft Windows XP", "xp"},
> +{ 6, 0, "Microsoft Windows Vista",  "vista"},
> +{ 6, 1, "Microsoft Windows 7"   "7"},
> +{ 6, 2, "Microsoft Windows 8",  "8"},
> +{ 6, 3, "Microsoft Windows 8.1","8.1"},
> +{ }
> +};
> +
> +static const ga_matrix_lookup_t WIN_SERVER_VERSION_MATRIX[] = {
> +{ 5, 2, "Microsoft Windows Server 2003","2003"},
> +{ 6, 0, "Microsoft Windows Server 2008","2008"},
> +{ 6, 1, "Microsoft Windows Server 2008 R2", "2008r2"},
> +{ 6, 2, "Microsoft Windows Server 2012","2012"},
> +{ 6, 3, "Microsoft Windows Server 2012 R2", "2012r2"},
> +{ },
>  };
>
>  typedef struct _ga_win_10_0_t {
>  int first_build;
> -const char *version;
> -const char *version_id;
> +char const *version;
> +char const *version_id;
>  } ga_win_10_0_t;
>
> -static const ga_win_10_0_t WIN_10_0_SERVER_VERSION_MATRIX[4] = {
> +static const ga_win_10_0_t WIN_10_0_SERVER_VERSION_MATRIX[] = {
>  {14393, "Microsoft Windows Server 2016","2016"},
>  {17763, "Microsoft Windows Server 2019","2019"},
>  {20344, "Microsoft Windows Server 2022","2022"},
> -{0, 0}
> +{ }
>  };
>
> -static const ga_win_10_0_t WIN_10_0_CLIENT_VERSION_MATRIX[3] = {
> +static const ga_win_10_0_t WIN_10_0_CLIENT_VERSION_MATRIX[] = {
>  {10240, "Microsoft Windows 10","10"},
>      {22000, "Microsoft Windows 11","11"},
> -{0, 0}
> +{ }
>  };
>
>  static void ga_get_win_version(RTL_OSVERSIONINFOEXW *info, Error **errp)
> @@ -2191,7 +2188,8 @@ static char *ga_get_win_name(const OSVERSIONINFOEXW 
> *os_version, bool id)
>  DWORD minor = os_version->dwMinorVersion;
>  DWORD build = os_version->dwBuildNumber;
>  int tbl_idx = (os_version->wProductType != VER_NT_WORKSTATION);
> -const ga_matrix_lookup_t *table = WIN_VERSION_MATRIX[tbl_idx];
> +const ga_matrix_lookup_t *table = tbl_idx ?
> +WIN_SERVER_VERSION_MATRIX : WIN_CLIENT_VERSION_MATRIX;
>  const ga_win_10_0_t *win_10_0_table = tbl_idx ?
>  WIN_10_0_SERVER_VERSION_MATRIX : WIN_10_0_CLIENT_VERSION_MATRIX;
>  const ga_win_10_0_t *win_10_0_version = NULL;
> --
> 2.44.0
>

Reviewed-by: Yan Vugenfirer 

Re: [PATCH 2/2] qga/win32: Use rundll for VSS installation

[Yan Vugenfirer]

Reviewed-by: Yan Vugenfirer 


On Mon, Feb 20, 2023 at 7:41 PM Konstantin Kostiuk  wrote:
>
> Add specific an entry points for rundll which is
> just a wrapper for COMRegister/COMUnregister functions.
>
> resolves: rhbz#2167436
> fixes: CVE-2023-0664
>
> Signed-off-by: Konstantin Kostiuk 
> ---
>  qga/installer/qemu-ga.wxs | 10 +-
>  qga/vss-win32/install.cpp |  9 +
>  qga/vss-win32/qga-vss.def |  2 ++
>  3 files changed, 16 insertions(+), 5 deletions(-)
>
> diff --git a/qga/installer/qemu-ga.wxs b/qga/installer/qemu-ga.wxs
> index feb629ec47..46ae9e7a13 100644
> --- a/qga/installer/qemu-ga.wxs
> +++ b/qga/installer/qemu-ga.wxs
> @@ -127,22 +127,22 @@
>
>  
>
> -
> +
>  
>
>  
>   -  ExeCommand='/c "[qemu_ga_directory]qemu-ga.exe" -s vss-install'
> +  ExeCommand='"[qemu_ga_directory]qga-vss.dll",DLLCOMRegister'
>Execute="deferred"
> -  Property="cmd"
> +  Property="rundll"
>Impersonate="no"
>Return="check"
>>
>  
>   -  ExeCommand='/c "[qemu_ga_directory]qemu-ga.exe" -s 
> vss-uninstall'
> +  ExeCommand='"[qemu_ga_directory]qga-vss.dll",DLLCOMUnregister'
>Execute="deferred"
> -  Property="cmd"
> +  Property="rundll"
>Impersonate="no"
>Return="check"
>>
> diff --git a/qga/vss-win32/install.cpp b/qga/vss-win32/install.cpp
> index b57508fbe0..68662a6dfc 100644
> --- a/qga/vss-win32/install.cpp
> +++ b/qga/vss-win32/install.cpp
> @@ -357,6 +357,15 @@ out:
>  return hr;
>  }
>
> +STDAPI_(void) CALLBACK DLLCOMRegister(HWND, HINSTANCE, LPSTR, int)
> +{
> +COMRegister();
> +}
> +
> +STDAPI_(void) CALLBACK DLLCOMUnregister(HWND, HINSTANCE, LPSTR, int)
> +{
> +COMUnregister();
> +}
>
>  static BOOL CreateRegistryKey(LPCTSTR key, LPCTSTR value, LPCTSTR data)
>  {
> diff --git a/qga/vss-win32/qga-vss.def b/qga/vss-win32/qga-vss.def
> index 927782c31b..ee97a81427 100644
> --- a/qga/vss-win32/qga-vss.def
> +++ b/qga/vss-win32/qga-vss.def
> @@ -1,6 +1,8 @@
>  LIBRARY  "QGA-PROVIDER.DLL"
>
>  EXPORTS
> +   DLLCOMRegister
> +   DLLCOMUnregister
> COMRegister PRIVATE
> COMUnregister   PRIVATE
> DllCanUnloadNow PRIVATE
> --
> 2.25.1
>

Re: [PATCH 1/2] qga/win32: Remove change action from MSI installer

[Yan Vugenfirer]

Reviewed-by: Yan Vugenfirer 

On Mon, Feb 20, 2023 at 7:41 PM Konstantin Kostiuk  wrote:
>
> resolves: rhbz#2167436
> fixes: CVE-2023-0664
>
> Signed-off-by: Konstantin Kostiuk 
> ---
>  qga/installer/qemu-ga.wxs | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/qga/installer/qemu-ga.wxs b/qga/installer/qemu-ga.wxs
> index 51340f7ecc..feb629ec47 100644
> --- a/qga/installer/qemu-ga.wxs
> +++ b/qga/installer/qemu-ga.wxs
> @@ -31,6 +31,7 @@
>/>
>   EmbedCab="yes" />
>  1
> +
>  DowngradeErrorMessage="Error: A newer version of QEMU guest agent is 
> already installed."
>/>
> --
> 2.25.1
>

Re: Porting the QEMU build architecture to Visual Studio

[Yan Vugenfirer]

Hi Andrew,

I created a Visual Studio project a long time ago for qemu-ga. It is an
ugly unsustainable hack that was done in the time before QEMU moved to
meson and I had to deal with GCC extension that MS compiler couldn't handle.
Today I would experiment with meson that should be able to create VS
projects: https://mesonbuild.com/Using-with-Visual-Studio.html and use
clang on Windows (info in the same link).

Best regards,
Yan.


On Wed, Feb 8, 2023 at 8:57 AM Philippe Mathieu-Daudé 
wrote:

> Hi Andrew,
>
> On 8/2/23 05:56, Andrew Numrich wrote:
> > Hello, I’m looking to experiment with QEMU in a Windows specific
> > environment. For that I’ll need to build QEMU’s source code in Visual
> > Studio 2017.
> >
> > I’m seeing that QEMU’s sources calls for a `config-host.h` file
> > generated by a `create_config` script. I don’t see said script anywhere
> > in the source tree.
> >
> > By googling I can see various creations of both these files in random
> > forks of QEMU around the internet, but I couldn’t be sure to use any of
> > them.
> >
> > I’m guessing these are somehow created by meson or ninja, but I don’t
> > have those easily on hand, being on Windows.
> >
> > Is there anyone that can point me in the right direction
>
> Paolo posted a patch to adapt QEMU build system to VSCode few
> years ago:
>
> https://lore.kernel.org/qemu-devel/20210512100906.621504-1-pbonz...@redhat.com/
>
> > or explain how
> > this is generated?
> >
> > Thanks
> >
> >   * Andrew Numrich
> >
> > http://github.com/toastmod
> >
>
>
>

Re: [PATCH v1 0/3] contrib/elf2dmp: Windows Server 2022 support

[Yan Vugenfirer]

Ping.



On Tue, Jan 10, 2023 at 6:10 PM Viktor Prutyanov <
viktor.prutya...@phystech.edu> wrote:

> On 11/30/22 3:03 AM, Viktor Prutyanov wrote:
> > Hi,
> >
> > For now, elf2dmp is unable to convert ELF-dump to DMP-dump made of
> > Windows Server 2022 guest. This patch series fixes it.
> >
> > v1: improve code-style fix
> >
> > Viktor Prutyanov (3):
> >contrib/elf2dmp: fix code style
> >contrib/elf2dmp: move PE dir search to pe_get_data_dir_entry
> >contrib/elf2dmp: add PE name check and Windows Server 2022 support
> >
> >   contrib/elf2dmp/addrspace.c |   1 +
> >   contrib/elf2dmp/main.c  | 103 +---
> >   contrib/elf2dmp/pe.h| 115 
> >   3 files changed, 135 insertions(+), 84 deletions(-)
> >
>
> Hi Paolo,
>
> Could you please add the series to your branch?
> I've sent it from my other email. I can add
> Signed-off-by: Viktor Prutyanov 
>
> Thanks,
> Viktor Prutyanov
>
>

Re: Guest reboot issues since QEMU 6.0 and Linux 5.11

[Yan Vugenfirer]

Hi Fabian,

Can you save the dump file with QEMU monitor using dump-guest-memory or with 
virsh dump?
Then you can use elf2dmp (compiled with QEMU and is found in “contrib” folder) 
to covert the dump file to WinDbg format and examine the stack. 


Best regards,
Yan.


> On 21 Jul 2022, at 3:49 PM, Fabian Ebner  wrote:
> 
> Hi,
> since about half a year ago, we're getting user reports about guest
> reboot issues with KVM/QEMU[0].
> 
> The most common scenario is a Windows Server VM (2012R2/2016/2019,
> UEFI/OVMF and SeaBIOS) getting stuck during the screen with the Windows
> logo and the spinning circles after a reboot was triggered from within
> the guest. Quitting the kvm process and booting with a fresh instance
> works. The issue seems to become more likely, the longer the kvm
> instance runs.
> 
> We did not get such reports while we were providing Linux 5.4 and QEMU
> 5.2.0, but we do with Linux 5.11/5.13/5.15 and QEMU 6.x.
> 
> I'm just wondering if anybody has seen this issue before or might have a
> hunch what it's about? Any tips on what to look out for when debugging
> are also greatly appreciated!
> 
> We do have debug access to a user's test VM and the VM state was saved
> before a problematic reboot, but I can't modify the host system there.
> AFAICT QEMU just executes guest code as usual, but I'm really not sure
> what to look out for.
> 
> That VM has CPU type host, and a colleague did have a similar enough CPU
> to load the VM state, but for him, the reboot went through normally. On
> the user's system, it triggers consistently after loading the VM state
> and rebooting.
> 
> So unfortunately, we didn't manage to reproduce the issue locally yet.
> With two other images provided by users, we ran into a boot loop, where
> QEMU resets the CPUs and does a few KVM_RUNs before the exit reason is
> KVM_EXIT_SHUTDOWN (which to my understanding indicates a triple fault)
> and then it repeats. It's not clear if the issues are related.
> 
> There are also a few reports about non-Windows VMs, mostly Ubuntu 20.04
> with UEFI/OVMF, but again, it's not clear if the issues are related.
> 
> [0]: https://forum.proxmox.com/threads/100744/
> (the forum thread is a bit chaotic unfortunately).
> 
> Best Regards,
> Fabi
> 
> 
> 

Re: [PATCH 2/5] util/oslib-win32: Add a helper to get the Windows version

[Yan Vugenfirer]

On Wed, Jul 27, 2022 at 1:00 PM Daniel P. Berrangé  wrote:
>
> On Wed, Jul 27, 2022 at 05:38:27PM +0800, Bin Meng wrote:
> > On Wed, Jul 27, 2022 at 4:50 PM Yan Vugenfirer  wrote:
> > >
> > > On Wed, Jul 27, 2022 at 10:43 AM Bin Meng  wrote:
> > > >
> > > > From: Bin Meng 
> > > >
> > > > This adds a helper to get the Windows version via the RtlGetVersion
> > > > call, for QEMU codes to determine the Windows version at run-time.
> > > >
> > > > Signed-off-by: Xuzhou Cheng 
> > > > Signed-off-by: Bin Meng 
> > > > ---
> > > >
> > > >  include/sysemu/os-win32.h |  2 ++
> > > >  util/oslib-win32.c| 15 +++
> > > >  2 files changed, 17 insertions(+)
> > > >
> > > > diff --git a/include/sysemu/os-win32.h b/include/sysemu/os-win32.h
> > > > index edc3b38a57..1e324026a4 100644
> > > > --- a/include/sysemu/os-win32.h
> > > > +++ b/include/sysemu/os-win32.h
> > > > @@ -204,6 +204,8 @@ ssize_t qemu_recv_wrap(int sockfd, void *buf, 
> > > > size_t len, int flags);
> > > >  ssize_t qemu_recvfrom_wrap(int sockfd, void *buf, size_t len, int 
> > > > flags,
> > > > struct sockaddr *addr, socklen_t *addrlen);
> > > >
> > > > +void os_get_win_version(RTL_OSVERSIONINFOEXW *info);
> > > > +
> > > >  #ifdef __cplusplus
> > > >  }
> > > >  #endif
> > > > diff --git a/util/oslib-win32.c b/util/oslib-win32.c
> > > > index 5723d3eb4c..6d2387b9ff 100644
> > > > --- a/util/oslib-win32.c
> > > > +++ b/util/oslib-win32.c
> > > > @@ -547,3 +547,18 @@ int qemu_msync(void *addr, size_t length, int fd)
> > > >   */
> > > >  return qemu_fdatasync(fd);
> > > >  }
> > > > +
> > > > +void os_get_win_version(RTL_OSVERSIONINFOEXW *info)
> > > > +{
> > > > +typedef LONG (WINAPI *rtl_get_version_t)(PRTL_OSVERSIONINFOEXW);
> > > > +
> > > > +/* RtlGetVersion is available starting with Windows 2000 */
> > > > +HMODULE module = GetModuleHandle("ntdll");
> > > > +PVOID fun = GetProcAddress(module, "RtlGetVersion");
> > > > +rtl_get_version_t rtl_get_version = (rtl_get_version_t)fun;
> > > > +
> > > > +info->dwOSVersionInfoSize = sizeof(RTL_OSVERSIONINFOEXW);
> > > > +rtl_get_version(info);
> > > The original function, when it was present in qemu-ga, tested that
> > > getting the function address succeeded.
> > > I think this test should be kept.
> > > See below:
> > > -PVOID fun = GetProcAddress(module, "RtlGetVersion");
> > > -if (fun == NULL) {
> > > -error_setg(errp, QERR_QGA_COMMAND_FAILED,
> > > -"Failed to get address of RtlGetVersion");
> > > -return;
> > > -}
> > >
> >
> > Please see the comment:
> >
> > /* RtlGetVersion is available starting with Windows 2000 */
> >
> > I don't think we need that check.
>
> In include/qemu/osdep.h we have
>
> /* as defined in sdkddkver.h */
> #ifndef _WIN32_WINNT
> #define _WIN32_WINNT 0x0601 /* Windows 7 API (should be in sync with glib) */
> #endif
>
> so do we even need to have the GetProcAddress calls at all ?
>
> Surely we can just  '#include ' and call
> RtlGetVersion directly at compile time ?
Yes.
https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/wdm/nf-wdm-rtlgetversion
- RtlGetVersion is available from Windows 2000.

Best regards,
Yan.

>
>
> With regards,
> Daniel
> --
> |: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
> |: https://libvirt.org -o-https://fstop138.berrange.com :|
> |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
>

Re: [PATCH 4/5] util/qemu-sockets: Enable unix socket support on Windows

[Yan Vugenfirer]

On Wed, Jul 27, 2022 at 10:46 AM Bin Meng  wrote:
>
> From: Bin Meng 
>
> Support for the unix socket has existed both in BSD and Linux for the
> longest time, but not on Windows. Since Windows 10 build 17063 [1],
> the native support for the unix socket has came to Windows. Starting
> this build, two Win32 processes can use the AF_UNIX address family
> over Winsock API to communicate with each other.
>
> Introduce a new build time config option CONFIG_AF_UNIX when the build
> host has such a capability, and a run-time check afunix_available() for
> Windows host in the QEMU sockets util codes.
>
> [1] https://devblogs.microsoft.com/commandline/af_unix-comes-to-windows/
>
> Signed-off-by: Xuzhou Cheng 
> Signed-off-by: Bin Meng 
> ---
>
>  meson.build |  6 ++
>  util/qemu-sockets.c | 48 ++---
>  2 files changed, 47 insertions(+), 7 deletions(-)
>
> diff --git a/meson.build b/meson.build
> index 75aaca8462..73e5de5957 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -2327,6 +2327,12 @@ have_afalg = get_option('crypto_afalg') \
>'''), error_message: 'AF_ALG requested but could not be 
> detected').allowed()
>  config_host_data.set('CONFIG_AF_ALG', have_afalg)
>
> +if targetos != 'windows'
> +  config_host_data.set('CONFIG_AF_UNIX', true)
> +else
> +  config_host_data.set('CONFIG_AF_UNIX', cc.has_header('afunix.h'))
> +endif
> +
>  config_host_data.set('CONFIG_AF_VSOCK', cc.has_header_symbol(
>'linux/vm_sockets.h', 'AF_VSOCK',
>prefix: '#include ',
> diff --git a/util/qemu-sockets.c b/util/qemu-sockets.c
> index 0e2298278f..d85f3ea3ee 100644
> --- a/util/qemu-sockets.c
> +++ b/util/qemu-sockets.c
> @@ -17,6 +17,15 @@
>   */
>  #include "qemu/osdep.h"
>
> +#if defined(CONFIG_WIN32) && defined(CONFIG_AF_UNIX)
> +# include 
> +/*
> + * AF_UNIX support is available since Windows 10 build 17063
> + * See https://devblogs.microsoft.com/commandline/af_unix-comes-to-windows/
> + */
> +# define WIN_BUILD_AF_UNIX 17063
> +#endif /* CONFIG_WIN32 && CONFIG_AF_UNIX */
> +
>  #ifdef CONFIG_AF_VSOCK
>  #include 
>  #endif /* CONFIG_AF_VSOCK */
> @@ -880,7 +889,7 @@ static int vsock_parse(VsockSocketAddress *addr, const 
> char *str,
>  }
>  #endif /* CONFIG_AF_VSOCK */
>
> -#ifndef _WIN32
> +#ifdef CONFIG_AF_UNIX
>
>  static bool saddr_is_abstract(UnixSocketAddress *saddr)
>  {
> @@ -900,6 +909,17 @@ static bool saddr_is_tight(UnixSocketAddress *saddr)
>  #endif
>  }
>
> +#ifdef CONFIG_WIN32
> +static bool afunix_available(void)
> +{
> +OSVERSIONINFOEXW os_version = { 0 };
> +
> +os_get_win_version(_version);
> +
> +return os_version.dwBuildNumber >= WIN_BUILD_AF_UNIX;
It can be that CONFIG_WIN32 is defined,but CONFIG_AF_UNIX is not. In
this case WIN_BUILD_AF_UNIX will be undefined.
Also, WIN_BUILD_AF_UNIX is just a build constant, why not define it
always under CONFIG_WIN32?

Best regards,
Yan.


> +}
> +#endif
> +
>  static int unix_listen_saddr(UnixSocketAddress *saddr,
>   int num,
>   Error **errp)
> @@ -912,6 +932,13 @@ static int unix_listen_saddr(UnixSocketAddress *saddr,
>  size_t pathlen;
>  size_t addrlen;
>
> +#ifdef CONFIG_WIN32
> +if (!afunix_available()) {
> +error_setg(errp, "AF_UNIX is not available on your Windows");
> +return -1;
> +}
> +#endif
> +
>  sock = qemu_socket(PF_UNIX, SOCK_STREAM, 0);
>  if (sock < 0) {
>  error_setg_errno(errp, errno, "Failed to create Unix socket");
> @@ -1004,6 +1031,13 @@ static int unix_connect_saddr(UnixSocketAddress 
> *saddr, Error **errp)
>  return -1;
>  }
>
> +#ifdef CONFIG_WIN32
> +if (!afunix_available()) {
> +error_setg(errp, "AF_UNIX is not available on your Windows");
> +return -1;
> +}
> +#endif
> +
>  sock = qemu_socket(PF_UNIX, SOCK_STREAM, 0);
>  if (sock < 0) {
>  error_setg_errno(errp, errno, "Failed to create socket");
> @@ -1060,14 +1094,14 @@ static int unix_listen_saddr(UnixSocketAddress *saddr,
>   int num,
>   Error **errp)
>  {
> -error_setg(errp, "unix sockets are not available on windows");
> +error_setg(errp, "unix sockets are not available on your host");
>  errno = ENOTSUP;
>  return -1;
>  }
>
>  static int unix_connect_saddr(UnixSocketAddress *saddr, Error **errp)
>  {
> -error_setg(errp, "unix sockets are not available on windows");
> +error_setg(errp, "unix sockets are not available on your host");
>  errno = ENOTSUP;
>  return -1;
>  }
> @@ -1335,7 +1369,7 @@ socket_sockaddr_to_address_inet(struct sockaddr_storage 
> *sa,
>  }
>
>
> -#ifndef WIN32
> +#ifdef CONFIG_AF_UNIX
>  static SocketAddress *
>  socket_sockaddr_to_address_unix(struct sockaddr_storage *sa,
>  socklen_t salen,
> @@ -1362,7 +1396,7 @@ socket_sockaddr_to_address_unix(struct sockaddr_storage 
> *sa,
>  

Re: [PATCH 2/5] util/oslib-win32: Add a helper to get the Windows version

[Yan Vugenfirer]

On Wed, Jul 27, 2022 at 10:43 AM Bin Meng  wrote:
>
> From: Bin Meng 
>
> This adds a helper to get the Windows version via the RtlGetVersion
> call, for QEMU codes to determine the Windows version at run-time.
>
> Signed-off-by: Xuzhou Cheng 
> Signed-off-by: Bin Meng 
> ---
>
>  include/sysemu/os-win32.h |  2 ++
>  util/oslib-win32.c| 15 +++
>  2 files changed, 17 insertions(+)
>
> diff --git a/include/sysemu/os-win32.h b/include/sysemu/os-win32.h
> index edc3b38a57..1e324026a4 100644
> --- a/include/sysemu/os-win32.h
> +++ b/include/sysemu/os-win32.h
> @@ -204,6 +204,8 @@ ssize_t qemu_recv_wrap(int sockfd, void *buf, size_t len, 
> int flags);
>  ssize_t qemu_recvfrom_wrap(int sockfd, void *buf, size_t len, int flags,
> struct sockaddr *addr, socklen_t *addrlen);
>
> +void os_get_win_version(RTL_OSVERSIONINFOEXW *info);
> +
>  #ifdef __cplusplus
>  }
>  #endif
> diff --git a/util/oslib-win32.c b/util/oslib-win32.c
> index 5723d3eb4c..6d2387b9ff 100644
> --- a/util/oslib-win32.c
> +++ b/util/oslib-win32.c
> @@ -547,3 +547,18 @@ int qemu_msync(void *addr, size_t length, int fd)
>   */
>  return qemu_fdatasync(fd);
>  }
> +
> +void os_get_win_version(RTL_OSVERSIONINFOEXW *info)
> +{
> +typedef LONG (WINAPI *rtl_get_version_t)(PRTL_OSVERSIONINFOEXW);
> +
> +/* RtlGetVersion is available starting with Windows 2000 */
> +HMODULE module = GetModuleHandle("ntdll");
> +PVOID fun = GetProcAddress(module, "RtlGetVersion");
> +rtl_get_version_t rtl_get_version = (rtl_get_version_t)fun;
> +
> +info->dwOSVersionInfoSize = sizeof(RTL_OSVERSIONINFOEXW);
> +rtl_get_version(info);
The original function, when it was present in qemu-ga, tested that
getting the function address succeeded.
I think this test should be kept.
See below:
-PVOID fun = GetProcAddress(module, "RtlGetVersion");
-if (fun == NULL) {
-error_setg(errp, QERR_QGA_COMMAND_FAILED,
-"Failed to get address of RtlGetVersion");
-return;
-}

Best regards,
Yan.
> +
> +return;
> +}
> --
> 2.34.1
>
>

Re: Is QEMU's vmxnet3 still being used?

[Yan Vugenfirer]

Hi All,

I know it is used to develop DPDK support on Windows right now.
Previously it was used for different nested virtualization scenarios as
well.

Best regards,
Yan.

On Thu, Aug 19, 2021 at 11:22 AM Jason Wang  wrote:

> On Wed, Aug 18, 2021 at 9:42 PM Thomas Huth  wrote:
> >
> >
> >   Hi all,
> >
> > I recently noticed that we have quite a bunch of tickets against the
> vmxnet3
> > device in our bug trackers, which indicate that this device could be
> used to
> > crash QEMU in various ways:
> >
> >
> https://gitlab.com/qemu-project/qemu/-/issues?state=opened=vmxnet3
> >
> >   https://bugs.launchpad.net/qemu?field.searchtext=vmxnet3
> >
> > Having hardly any knowledge about this device and its usage at all, I
> wonder
> > how much it is still used out there in the wild?
>
> I guess it might have been used for virt-v2v in the past.
>
> But I'm not sure what's the status now.
>
> Thanks
>
> > If there are still many
> > users of this device, is there anybody interested here in helping to get
> > these crashes fixed in the near future? Otherwise, should we maybe rather
> > mark this device as deprecated and remove it in a couple of releases?
> What
> > do you think?
> >
> >   Thomas
> >
>
>
>

Re: [RFC PATCH v3 02/10] net: Pad short frames to minimum size before send from SLiRP/TAP

[Yan Vugenfirer]

> On 9 Mar 2021, at 12:13 PM, Peter Maydell  wrote:
> 
> On Tue, 9 Mar 2021 at 09:01, Bin Meng  > wrote:
>> 
>> Hi Jason,
>> 
>> On Tue, Mar 9, 2021 at 5:00 PM Bin Meng  wrote:
>>> 
>>> Hi Jason,
>>> 
>>> On Tue, Mar 9, 2021 at 4:57 PM Jason Wang  wrote:
 
 
 On 2021/3/9 4:35 下午, Bin Meng wrote:
> Hi Jason,
> 
> On Tue, Mar 9, 2021 at 4:23 PM Jason Wang  wrote:
>> 
>> On 2021/3/8 6:22 下午, Peter Maydell wrote:
>>> I think the key thing we need to do here is make a decision
>>> and be clear about what we're doing. There are three options
>>> I can see:
>>> 
>>> (1) we say that the net API demands that backends pad
>>> packets they emit to the minimum ethernet frame length
>>> unless they specifically are intending to emit a short frame,
>>> and we fix any backends that don't comply (or equivalently,
>>> add support in the core code for a backend to mark itself
>>> as "I don't pad; please do it for me").
>>> 
>>> (2) we say that the networking subsystem doesn't support
>>> short packets, and just have the common code always enforce
>>> padding short frames to the minimum length somewhere between
>>> when it receives a packet from a backend and passes it to
>>> a NIC model.
>>> 
>>> (3) we say that it's the job of the NIC models to pad
>>> short frames as they see them coming in.
> 
>> I'm not sure how much value we can gain from (1). So (2) looks better to 
>> me.
>> 
>> Bin or Philippe, want to send a new version?
>> 
> I think this series does what (2) asks for. Or am I missing anything?
 
 
 It only did the padding for user/TAP.
>>> 
>> 
>> (hit send too soon ...)
>> 
>> Ah, so we want this:
>> 
>> if (sender->info->type != NET_CLIENT_DRIVER_NIC)
>> 
>> correct?
> 
> No, option (2) is "always pad short packets regardless of
> sender->info->type". Even if a NIC driver sends out a short
> packet, we want to pad it, because we might be feeding it to
> something that assumes it does not see short packets.

Some thought on this option - in such case with virtio-net, can we also get an 
indication from the device that the packet will be padded?
Currently we are padding short packets in Windows driver (this is MS 
certification requirement), and it will be nice not do to this in the guest if 
device will announce such capability.

Best regards,
Yan.

> 
> thanks
> -- PMM

Re: [PATCH 2/4] hw/misc/pvpanic: add PCI interface support

[Yan Vugenfirer]

> On 15 Jan 2021, at 8:34 PM, Mihai Carabas  wrote:
> 
> Add PCI interface support for PVPANIC device. Create a new file pvpanic-pci.c
> where the PCI specific routines reside and update the build system with the 
> new
> files and config structure.
> 
> Signed-off-by: Mihai Carabas 
> ---
> docs/specs/pci-ids.txt|  1 +
> hw/misc/Kconfig   |  6 +++
> hw/misc/meson.build   |  1 +
> hw/misc/pvpanic-pci.c | 94 +++
> include/hw/misc/pvpanic.h |  1 +
> include/hw/pci/pci.h  |  1 +
> 6 files changed, 104 insertions(+)
> create mode 100644 hw/misc/pvpanic-pci.c
> 
> diff --git a/docs/specs/pci-ids.txt b/docs/specs/pci-ids.txt
> index abbdbca..5e407a6 100644
> --- a/docs/specs/pci-ids.txt
> +++ b/docs/specs/pci-ids.txt
> @@ -64,6 +64,7 @@ PCI devices (other than virtio):
> 1b36:000d  PCI xhci usb host adapter
> 1b36:000f  mdpy (mdev sample device), linux/samples/vfio-mdev/mdpy.c
> 1b36:0010  PCIe NVMe device (-device nvme)
> +1b36:0011  PCI PVPanic device (-device pvpanic-pci)
> 
> All these devices are documented in docs/specs.
> 
> diff --git a/hw/misc/Kconfig b/hw/misc/Kconfig
> index 23bc978..19c216f 100644
> --- a/hw/misc/Kconfig
> +++ b/hw/misc/Kconfig
> @@ -124,6 +124,12 @@ config IOTKIT_SYSINFO
> config PVPANIC_COMMON
>bool
> 
> +config PVPANIC_PCI
> +bool
> +default y if PCI_DEVICES
> +depends on PCI
> +select PVPANIC_COMMON
> +
> config PVPANIC_ISA
>bool
>depends on ISA_BUS
> diff --git a/hw/misc/meson.build b/hw/misc/meson.build
> index 8c828ad..f686019 100644
> --- a/hw/misc/meson.build
> +++ b/hw/misc/meson.build
> @@ -99,6 +99,7 @@ softmmu_ss.add(when: 'CONFIG_ARMSSE_CPUID', if_true: 
> files('armsse-cpuid.c'))
> softmmu_ss.add(when: 'CONFIG_ARMSSE_MHU', if_true: files('armsse-mhu.c'))
> 
> softmmu_ss.add(when: 'CONFIG_PVPANIC_ISA', if_true: files('pvpanic-isa.c'))
> +softmmu_ss.add(when: 'CONFIG_PVPANIC_PCI', if_true: files('pvpanic-pci.c'))
> softmmu_ss.add(when: 'CONFIG_AUX', if_true: files('auxbus.c'))
> softmmu_ss.add(when: 'CONFIG_ASPEED_SOC', if_true: files('aspeed_scu.c', 
> 'aspeed_sdmc.c', 'aspeed_xdma.c'))
> softmmu_ss.add(when: 'CONFIG_MSF2', if_true: files('msf2-sysreg.c'))
> diff --git a/hw/misc/pvpanic-pci.c b/hw/misc/pvpanic-pci.c
> new file mode 100644
> index 000..d629639
> --- /dev/null
> +++ b/hw/misc/pvpanic-pci.c
> @@ -0,0 +1,94 @@
> +/*
> + * QEMU simulated PCI pvpanic device.
> + *
> + * Copyright (C) 2020 Oracle
> + *
> + * Authors:
> + * Mihai Carabas 
> + *
> + * 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 "qemu/osdep.h"
> +#include "qemu/log.h"
> +#include "qemu/module.h"
> +#include "sysemu/runstate.h"
> +
> +#include "hw/nvram/fw_cfg.h"
> +#include "hw/qdev-properties.h"
> +#include "migration/vmstate.h"
> +#include "hw/misc/pvpanic.h"
> +#include "qom/object.h"
> +#include "hw/pci/pci.h"
> +
> +OBJECT_DECLARE_SIMPLE_TYPE(PVPanicPCIState, PVPANIC_PCI_DEVICE)
> +
> +/*
> + * PVPanicPCIState for PCI device
> + */
> +typedef struct PVPanicPCIState {
> +PCIDevice dev;
> +PVPanicState pvpanic;
> +} PVPanicPCIState;
> +
> +static const VMStateDescription vmstate_pvpanic_pci = {
> +.name = "pvpanic-pci",
> +.version_id = 1,
> +.minimum_version_id = 1,
> +.fields = (VMStateField[]) {
> +VMSTATE_PCI_DEVICE(dev, PVPanicPCIState),
> +VMSTATE_END_OF_LIST()
> +}
> +};
> +
> +static void pvpanic_pci_realizefn(PCIDevice *dev, Error **errp)
> +{
> +PVPanicPCIState *s = PVPANIC_PCI_DEVICE(dev);
> +PVPanicState *ps = >pvpanic;
> +
> +pvpanic_setup_io(>pvpanic, DEVICE(s), 2);
> +
> +pci_register_bar(dev, 0, PCI_BASE_ADDRESS_SPACE_MEMORY, >mr);
> +}
> +
> +static Property pvpanic_pci_properties[] = {
> +DEFINE_PROP_UINT8("events", PVPanicPCIState, pvpanic.events, 
> PVPANIC_PANICKED | PVPANIC_CRASHLOADED),
> +DEFINE_PROP_END_OF_LIST(),
> +};
> +
> +static void pvpanic_pci_class_init(ObjectClass *klass, void *data)
> +{
> +DeviceClass *dc = DEVICE_CLASS(klass);
> +PCIDeviceClass *pc = PCI_DEVICE_CLASS(klass);
> +
> +device_class_set_props(dc, pvpanic_pci_properties);
> +
> +pc->realize = pvpanic_pci_realizefn;
> +pc->vendor_id = PCI_VENDOR_ID_REDHAT;
> +pc->device_id = PCI_DEVICE_ID_REDHAT_PVPANIC;

Please fill out subsystem and subsystem vendor IDs as well:
pc->subsystem_vendor_id
pc->subsystem_id 

It is needed in order to pass MS WHQL tests. Requirement name 
“Device.Connectivity.PciConnected.SubsystemIdsRequired” in "Windows Hardware 
Compatibility Specifications – Components and Peripherals” document.
https://docs.microsoft.com/en-us/windows-hardware/design/compatibility/whcp-specifications-policies

Thanks,
Yan.

> +pc->revision = 1;
> +pc->class_id = PCI_CLASS_SYSTEM_OTHER;
> +dc->vmsd = _pvpanic_pci;
> +
> +set_bit(DEVICE_CATEGORY_MISC, dc->categories);
> +}
> 

Re: simple example of pci driver with dma

[Yan Vugenfirer]

Hi Shaked,

In the prob function, before you are trying to do any DMA operations with your 
device, you should call pci_enable_device and then pci_set_master. Also you 
might need to map the resources of your device.
Check PCI driver documentation: 
https://lxr.missinglinkelectronics.com/linux/Documentation/PCI/pci.rst#L199

Best regards,
Yan.

> On 29 Oct 2020, at 10:32 PM, Shaked Matzner  wrote:
> 
> Hey Peter,
> Currently I have this test in the driver which allocates data, assign it to 
> default value config source as the BASE address of dma, dest as the physical 
> address which I got from dma_alloc_coherent, set the count and assign the 
> command to raise interrupt and read,the piece of code used is something like 
> this(this a test performed from the probe function of the driver)
> vaddr_to = 
> dma_alloc_coherent(&(dev->dev), 4, _handle_to, GFP_ATOMIC |GFP_KERNEL);
> *((volatile int*)vaddr_to) = 0xff;
> test->vaddr_to = vaddr_to;
> dev_info(&(dev->dev), 
> "vaddr_to = %px\n", vaddr_to);
> dev_info(&(dev->dev), 
> "dma_handle_to = %llx\n", (unsigned long long)dma_handle_to);
> iowrite32(DMA_BASE, mmio + 
> IO_DMA_SRC);
> iowrite32((u32)dma_handle_to, 
> mmio + IO_DMA_DST);
> iowrite32(SIZE, mmio + 
> IO_DMA_CNT);
>iowrite32(DMA_CMD | 
> DMA_FROM_DEV | DMA_IRQ, mmio + IO_DMA_CMD);
> Where and when should the pci_set_master hould be called?
> Thanks,
>  Shaked Matzner
>  
> From: Peter Maydell  
> Sent: Thursday, October 29, 2020 5:46 PM
> To: Shaked Matzner 
> Cc: qemu-devel@nongnu.org
> Subject: Re: simple example of pci driver with dma
>  
> 
> IRONSCALES couldn't recognize this email as this is the first time you 
> received an email from this sender peter.mayd...@linaro.org
>  
> [EXTERNAL]
> 
> On Thu, 29 Oct 2020 at 14:59, Shaked Matzner wrote:
> > however the value I get is still 255(0xff) and not 18(0x12) probably I've 
> > missed something but when the interrupt is called the transfer to the RAM 
> > address should be completed, however it seems like the dma_write_buffer 
> > function from the device does not perform any transfer. What Am I missing?
> 
> The usual mistake is forgetting in the guest code to program the
> PCI device to enable bus mastering by setting the Bus Master bit
> in the Command register in the PCI config space registers for
> the device. Unless you do that then all DMA attempts will fail
> (same as on real h/w). In the Linux kernel the function for this
> is pci_set_master(), I think.
> 
> thanks
> -- PMM 
> 
> The contents of this email message and any attachments are intended solely 
> for the addressee(s) and may contain confidential and/or privileged 
> information and may be legally protected from disclosure. If you are not the 
> intended recipient of this message or their agent, or if this message has 
> been addressed to you in error, please immediately alert the sender by reply 
> email and then delete this message and any attachments. If you are not the 
> intended recipient, you are hereby notified that any use, dissemination, 
> copying, or storage of this message or its attachments is strictly 
> prohibited. 
> 



--
Daynix Computing LTD
Yan Vugenfirer, CEO
Email: y...@daynix.com
Phone (Israel): +972-54-4758084
Phone (USA): +1-7204776716
Phone (UK): +44-2070482938
Web: www.daynix.com

Re: [PATCH v3 2/2] hw/virtio-pci Added AER capability.

[Yan Vugenfirer]

Hi Michael,



> On 5 Oct 2020, at 8:46 PM, Michael S. Tsirkin  wrote:
> 
> On Mon, Oct 05, 2020 at 02:56:01PM +0300, and...@daynix.com wrote:
>> From: Andrew 
>> 
>> Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1878465
> 
> That's a private bug - what information can you share about
> the motivation for the patch?

We need AER feature in order to pass MS WHQL tests for the future Windows 
Server versions.
According to Microsoft driver\device certification requirements for next 
version of Window Server, PCIe devices must support AER.
The exact quote from Microsoft certification requirements:
"Windows Server PCI Express devices are required to support Advanced Error 
Reporting [AER] as defined in PCI Express Base Specification version 2.1.”


> 
>> Added AER capability for virtio-pci devices.
>> Also added property for devices, by default AER is disabled.
>> 
>> Signed-off-by: Andrew Melnychenko 
>> ---
>> hw/virtio/virtio-pci.c | 16 
>> hw/virtio/virtio-pci.h |  4 
>> 2 files changed, 20 insertions(+)
>> 
>> diff --git a/hw/virtio/virtio-pci.c b/hw/virtio/virtio-pci.c
>> index ae60c1e249..e0a7936f9c 100644
>> --- a/hw/virtio/virtio-pci.c
>> +++ b/hw/virtio/virtio-pci.c
>> @@ -1807,6 +1807,12 @@ static void virtio_pci_realize(PCIDevice *pci_dev, 
>> Error **errp)
>>  */
>> pci_set_word(pci_dev->config + pos + PCI_PM_PMC, 0x3);
>> 
>> +if (proxy->flags & VIRTIO_PCI_FLAG_AER) {
>> +pcie_aer_init(pci_dev, PCI_ERR_VER, last_pcie_cap_offset,
>> +  PCI_ERR_SIZEOF, NULL);
>> +last_pcie_cap_offset += PCI_ERR_SIZEOF;
>> +}
>> +
>> if (proxy->flags & VIRTIO_PCI_FLAG_INIT_DEVERR) {
>> /* Init error enabling flags */
>> pcie_cap_deverr_init(pci_dev);
>> @@ -1848,7 +1854,15 @@ static void virtio_pci_realize(PCIDevice *pci_dev, 
>> Error **errp)
>> 
>> static void virtio_pci_exit(PCIDevice *pci_dev)
>> {
>> +VirtIOPCIProxy *proxy = VIRTIO_PCI(pci_dev);
>> +bool pcie_port = pci_bus_is_express(pci_get_bus(pci_dev)) &&
>> + !pci_bus_is_root(pci_get_bus(pci_dev));
>> +
>> msix_uninit_exclusive_bar(pci_dev);
>> +if (proxy->flags & VIRTIO_PCI_FLAG_AER && pcie_port &&
>> +pci_is_express(pci_dev)) {
>> +pcie_aer_exit(pci_dev);
>> +}
>> }
>> 
>> static void virtio_pci_reset(DeviceState *qdev)
>> @@ -1901,6 +1915,8 @@ static Property virtio_pci_properties[] = {
>> VIRTIO_PCI_FLAG_INIT_PM_BIT, true),
>> DEFINE_PROP_BIT("x-pcie-flr-init", VirtIOPCIProxy, flags,
>> VIRTIO_PCI_FLAG_INIT_FLR_BIT, true),
>> +DEFINE_PROP_BIT("aer", VirtIOPCIProxy, flags,
>> +VIRTIO_PCI_FLAG_AER_BIT, false),
>> DEFINE_PROP_END_OF_LIST(),
>> };
>> 
> 
> Does management need ability to enable this capability?
> If yes let's cc them. If no let's rename to x-aer so we don't
> commit to a stable interface ...

QE is using libvirt in order to spawn test setups. So I think it should be used 
by management as well.
Whom should Andrew CC?

Best regards,
Yan.
> 
> 
>> diff --git a/hw/virtio/virtio-pci.h b/hw/virtio/virtio-pci.h
>> index 91096f0291..3986b4f0e3 100644
>> --- a/hw/virtio/virtio-pci.h
>> +++ b/hw/virtio/virtio-pci.h
>> @@ -45,6 +45,7 @@ enum {
>> VIRTIO_PCI_FLAG_INIT_LNKCTL_BIT,
>> VIRTIO_PCI_FLAG_INIT_PM_BIT,
>> VIRTIO_PCI_FLAG_INIT_FLR_BIT,
>> +VIRTIO_PCI_FLAG_AER_BIT,
>> };
>> 
>> /* Need to activate work-arounds for buggy guests at vmstate load. */
>> @@ -84,6 +85,9 @@ enum {
>> /* Init Function Level Reset capability */
>> #define VIRTIO_PCI_FLAG_INIT_FLR (1 << VIRTIO_PCI_FLAG_INIT_FLR_BIT)
>> 
>> +/* Advanced Error Reporting capability */
>> +#define VIRTIO_PCI_FLAG_AER (1 << VIRTIO_PCI_FLAG_AER_BIT)
>> +
>> typedef struct {
>> MSIMessage msg;
>> int virq;
>> -- 
>> 2.28.0

Re: [PATCH 2/2] hw/virtio-pci Added AER capability.

[Yan Vugenfirer]

Ping.

> On 13 Aug 2020, at 10:19 AM, and...@daynix.com wrote:
> 
> From: Andrew 
> 
> Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1857668
> Added AER capability for virtio-pci devices.
> Also added property for devices, by default AER is enabled.
> 
> Signed-off-by: Andrew Melnychenko 
> ---
> hw/virtio/virtio-pci.c | 16 
> hw/virtio/virtio-pci.h |  4 
> 2 files changed, 20 insertions(+)
> 
> diff --git a/hw/virtio/virtio-pci.c b/hw/virtio/virtio-pci.c
> index 8e02709605..646dfb8a0d 100644
> --- a/hw/virtio/virtio-pci.c
> +++ b/hw/virtio/virtio-pci.c
> @@ -1806,6 +1806,12 @@ static void virtio_pci_realize(PCIDevice *pci_dev, 
> Error **errp)
>  */
> pci_set_word(pci_dev->config + pos + PCI_PM_PMC, 0x3);
> 
> +if (proxy->flags & VIRTIO_PCI_FLAG_AER) {
> +pcie_aer_init(pci_dev, PCI_ERR_VER, last_pcie_cap_offset,
> +  PCI_ERR_SIZEOF, NULL);
> +last_pcie_cap_offset += PCI_ERR_SIZEOF;
> +}
> +
> if (proxy->flags & VIRTIO_PCI_FLAG_INIT_DEVERR) {
> /* Init error enabling flags */
> pcie_cap_deverr_init(pci_dev);
> @@ -1847,7 +1853,15 @@ static void virtio_pci_realize(PCIDevice *pci_dev, 
> Error **errp)
> 
> static void virtio_pci_exit(PCIDevice *pci_dev)
> {
> +VirtIOPCIProxy *proxy = VIRTIO_PCI(pci_dev);
> +bool pcie_port = pci_bus_is_express(pci_get_bus(pci_dev)) &&
> + !pci_bus_is_root(pci_get_bus(pci_dev));
> +
> msix_uninit_exclusive_bar(pci_dev);
> +if (proxy->flags & VIRTIO_PCI_FLAG_AER && pcie_port &&
> +pci_is_express(pci_dev)) {
> +pcie_aer_exit(pci_dev);
> +}
> }
> 
> static void virtio_pci_reset(DeviceState *qdev)
> @@ -1900,6 +1914,8 @@ static Property virtio_pci_properties[] = {
> VIRTIO_PCI_FLAG_INIT_PM_BIT, true),
> DEFINE_PROP_BIT("x-pcie-flr-init", VirtIOPCIProxy, flags,
> VIRTIO_PCI_FLAG_INIT_FLR_BIT, true),
> +DEFINE_PROP_BIT("aer", VirtIOPCIProxy, flags,
> +VIRTIO_PCI_FLAG_AER_BIT, true),
> DEFINE_PROP_END_OF_LIST(),
> };
> 
> diff --git a/hw/virtio/virtio-pci.h b/hw/virtio/virtio-pci.h
> index e2eaaa9182..4b2491ff15 100644
> --- a/hw/virtio/virtio-pci.h
> +++ b/hw/virtio/virtio-pci.h
> @@ -45,6 +45,7 @@ enum {
> VIRTIO_PCI_FLAG_INIT_LNKCTL_BIT,
> VIRTIO_PCI_FLAG_INIT_PM_BIT,
> VIRTIO_PCI_FLAG_INIT_FLR_BIT,
> +VIRTIO_PCI_FLAG_AER_BIT,
> };
> 
> /* Need to activate work-arounds for buggy guests at vmstate load. */
> @@ -84,6 +85,9 @@ enum {
> /* Init Function Level Reset capability */
> #define VIRTIO_PCI_FLAG_INIT_FLR (1 << VIRTIO_PCI_FLAG_INIT_FLR_BIT)
> 
> +/* Advanced Error Reporting capability */
> +#define VIRTIO_PCI_FLAG_AER (1 << VIRTIO_PCI_FLAG_AER_BIT)
> +
> typedef struct {
> MSIMessage msg;
> int virq;
> -- 
> 2.27.0
> 
> 

Re: [Bug 1889943] Improper TCP/IP packet splitting on e1000e/vmxnet3

[Yan Vugenfirer]

Hello Patrick,

If you are using  QEMU version 4.2, then it is missing recent patches fixing 
IPv6 and TSO behaviour:
https://www.mail-archive.com/qemu-devel@nongnu.org/msg723411.html
https://www.mail-archive.com/qemu-devel@nongnu.org/msg723412.html

Can you check that the above patches solve your issues?


Best regards,
Yan.

> On 2 Aug 2020, at 6:59 PM, Patrick Magauran <1889...@bugs.launchpad.net> 
> wrote:
> 
> Some more clarifications:
> It appears the QEMU does turn on the vnet_hdr flag of the tap interface in 
> most cases, not just host-only networks. My previous assumption was due to 
> the way the libvirt manages it, only setting it if the virtio interface is 
> used.
> 
> Still, for software fragmentation implementations, ip fragmentation
> should be a last resort.
> 
> I have also confirmed a suspicion that the current implementation of sw
> fragmentation will not work with IPV6. It creates malformed packets as
> ipv6 requires a different setup of headers to fragment. Thanks to the
> many redundancies in the network stack, the packets eventually arrive at
> the host server correctly formed, but we should not rely on this fact.
> 
> ** Description changed:
> 
> + Update: The sw implementation of fragmentation also creates malformed
> + IPv6 packets when their size is above the MTU. See comment #3
> + 
>  Problem Description:
> - When using a tap interface and the guest sends a TCP packet that would need 
> to be segmented, it is fragmented using IP fragmentation. The host does not 
> reassemble the IP fragments and forwards them to the next hop. This causes 
> issues on certain ISPs, which seemingly reject IP fragments(Verizon Fios). 
> - This issue occurs on the e1000e and vmxnet3 NIC models, and possibly 
> others. It does not occur on the virtio(which passes the entire packet 
> through to the host w/o fragmentation or segmentation) or the e1000 model(). 
> + When using a tap interface and the guest sends a TCP packet that would need 
> to be segmented, it is fragmented using IP fragmentation. The host does not 
> reassemble the IP fragments and forwards them to the next hop. This causes 
> issues on certain ISPs, which seemingly reject IP fragments(Verizon Fios).
> + This issue occurs on the e1000e and vmxnet3 NIC models, and possibly 
> others. It does not occur on the virtio(which passes the entire packet 
> through to the host w/o fragmentation or segmentation) or the e1000 model().
> 
>  Test scenario:
>  Setup a tap and network bridge using the directions here: 
> https://gist.github.com/extremecoders-re/e8fd8a67a515fee0c873dcafc81d811c
>  Boot the machine into any modern guest(a Fedora 31 live iso was used for 
> testing)
>  Begin a wireshark capture on the host machine
>  On the host(or another machine on the network) run: npx http-echo-server(See 
> https://github.com/watson/http-echo-server)
>  On the guest run
>  Curl -d “Lorem ipsum dolor sit amet, consectetur adipiscing elit. Maecenas 
> venenatis viverra ipsum, ac tincidunt est rhoncus eu. Suspendisse vehicula 
> congue ante, non rhoncus elit tempus vitae. Duis ac leo massa. Donec rutrum 
> condimentum turpis nec ultricies. Duis laoreet elit eu arcu pulvinar, vitae 
> congue neque mattis. Mauris sed ante nunc. Vestibulum vitae urna a tellus 
> maximus sagittis. Vivamus luctus pellentesque neque, vel tempor purus porta 
> ut. Phasellus at quam bibendum, fermentum libero sit amet, ullamcorper 
> mauris. In rutrum sit amet dui id maximus. Ut lectus ligula, hendrerit nec 
> aliquam non, finibus a turpis. Proin scelerisque convallis ante, et pharetra 
> elit. Donec nunc nisl, viverra vitae dui at, posuere rhoncus nibh. Mauris in 
> massa quis neque posuere placerat quis quis massa. Donec quis lacus ligula. 
> Donec mollis vel nisi eget elementum. Nam id magna porta nunc consectetur 
> efficitur ac quis lorem. Cras faucibus vel ex porttitor mattis. Praesent in 
> mattis tortor. In venenatis convallis quam, in posuere nibh. Proin non 
> dignissim massa. Cras at mi ut lorem tristique fringilla. Nulla ac quam 
> condimentum metus tincidunt vulputate ut at leo. Nunc pellentesque, nunc vel 
> rhoncus condimentum, arcu sem molestie augue, in suscipit mauris odio mollis 
> odio. Integer hendrerit lectus a leo facilisis, in accumsan urna maximus. Nam 
> nec odio volutpat, varius est id, tempus libero. Vestibulum lobortis tortor 
> quam, ac scelerisque urna rhoncus in. Etiam tempor, est sit amet vulputate 
> molestie, urna neque sodales leo, sit amet blandit risus felis sed est. Nulla 
> eu eros nec tortor dapibus maximus faucibus ut erat. Ut pharetra tempor massa 
> in bibendum. Interdum et malesuada fames ac ante ipsum primis in faucibus. 
> Etiam mattis molestie felis eu efficitur. Morbi tincidunt consectetur diam 
> tincidunt feugiat. Morbi euismod ut lorem finibus pellentesque. Aliquam eu 
> porta ex. Aliquam cursus, orci sit amet volutpat egestas, est est pulvinar 
> erat, sed luctus nisl ligula eget justo vestibulum.” 
> 
>  2000 bytes 

Re: [Qemu-devel] Virtual IOMMU + Virtio-net devices in a Windows VM doesn't work

[Yan Vugenfirer]

> On 26 Jul 2018, at 05:53, Jintack Lim  wrote:
> 
> Hi Peter,
> 
> On Tue, Jul 24, 2018 at 1:55 AM Peter Xu  wrote:
>> 
>> On Mon, Jul 23, 2018 at 04:13:18PM -0400, Jintack Lim wrote:
>>> Hi,
>>> 
>>> I'm running a Windows VM on top of KVM on x86, and one of virtio-net
Hi,

What Windows OS are you using? Keep in mind that IOMMU support in Windows 
drivers will work in Windows 10 and Windows Server 2016.
What’s the version of the virtio-win drivers are you using (should be build 150 
and up, or to include the following commit: 
https://github.com/virtio-win/kvm-guest-drivers-windows/commit/eac3270d10924903ff38a08fcdaa252604d2e4a9)?

Best regards,
Yan.

>>> device in the Windows VM doesn't seem to work. I provided virtual
>>> IOMMU and two virtio-net devices to the VM: one bypassing the virtual
>>> IOMMU and the other one behind the virtual IOMMU[1]. It turned out
>>> that the virtio-net device behind virtual IOMMU didn't work while the
>>> one bypassing the virtual IOMMU worked well. In a linux VM with the
>>> same configuration, both of virtio-net device worked well.
>>> 
>>> I found that there is a subtle difference between virtio-net devices
>>> bypassing and behind virtual IOMMU in a Linux VM. The lscpu command in
>>> the Linux VM shows different device names for them; the first line is
>>> for the bypassing one, and the second line is for the one behind the
>>> virtual IOMMU
>>> 
>>> 00:03.0 Ethernet controller: Red Hat, Inc Virtio network device
>>> 01:00.0 Ethernet controller: Red Hat, Inc Device 1041 (rev 01)
>>> 
>>> I wonder if this difference somehow caused the problem in the Windows
>>> VM. I've installed the latest virtio drivers (0.1.149) from the fedora
>>> project [2]
>>> 
>>> Any thoughts?
>>> 
>>> I'm using v4.15 Linux kernel as a host, and QEMU 2.11.0.
>> 
>> Have you tried the latest QEMU?
>> 
> 
> I just tried the latest QEMU, but observed the same symptom.
> 
>> Also CC Jason and Michael.
> 
> Thanks!
> 
>> 
>>> 
>>> Thanks,
>>> Jintack
>>> 
>>> [1] https://wiki.qemu.org/Features/VT-d
>>> [2] 
>>> https://docs.fedoraproject.org/quick-docs/en-US/creating-windows-virtual-machines-using-virtio-drivers.html
>>> 
>>> 
>> 
>> Regards,
>> 
>> --
>> Peter Xu
>> 
> 
> 

Re: [Qemu-devel] [virtio-dev] [PATCH 4/4] virtio-net: add linkspeed and duplex settings to virtio-net

[Yan Vugenfirer]

> On 6 Mar 2018, at 20:13, Michael S. Tsirkin <m...@redhat.com> wrote:
> 
> On Tue, Mar 06, 2018 at 01:02:06PM -0500, Jason Baron wrote:
>> 
>> 
>> On 03/04/2018 08:05 AM, Yan Vugenfirer wrote:
>>> 
>>> 
>>>> On 2 Mar 2018, at 22:19, Michael S. Tsirkin <m...@redhat.com
>>>> <mailto:m...@redhat.com>> wrote:
>>>> 
>>>> On Fri, Mar 02, 2018 at 03:14:01PM +0800, Jason Wang wrote:
>>>>> 
>>>>> 
>>>>> On 2018年03月02日 11:46, Jason Baron wrote:
>>>>>> Although linkspeed and duplex can be set in a linux guest via
>>>>>> 'ethtool -s',
>>>>>> this requires custom ethtool commands for virtio-net by default.
>>>>>> 
>>>>>> Introduce a new feature flag, VIRTIO_NET_F_SPEED_DUPLEX, which allows
>>>>>> the hypervisor to export a linkspeed and duplex setting. The user can
>>>>>> subsequently overwrite it later if desired via: 'ethtool -s'.
>>>>>> 
>>>>>> Linkspeed and duplex settings can be set as:
>>>>>> '-device virtio-net,speed=1,duplex=full'
>>>>> 
>>>>> I was thinking whether or not it's better to decide the duplex by the
>>>>> type
>>>>> of backends.
>>>>> 
>>>>> E.g userspace and vhost-kernel implement a in fact half duplex. But dpdk
>>>>> implement a full duplex.
>>>>> 
>>>>> Thanks
>>>> 
>>>> OTOH it's a priority for some people to be able to support migration
>>>> between different backend types. Breaking that won't be nice.
>>> 
>>> I think that in this case we need a way to update the settings of link
>>> speed and link duplex (maybe add QMP command). Migration between
>>> different backend types should cause link down\link up events. And this
>>> is a time for a driver to re-read the settings and update the OS.
>>> 
>>> Best regards,
>>> Yan.
>>> 
>> 
>> So the virtio_net driver in linux will re-read these settings on link up
>> events. So I could add a qmp command to set these (in addition to the
>> command-line) interface, if desired. Is there a consensus that we need
>> to add a qmp command here? Or can that be treated as a future item, if
>> somebody wants it?
>> 
>> Thanks,
>> 
>> -Jason
> 
> We already have ability to take link down and up.
> I'd say it's a future item.
I agree.

Yan.
> 
> -- 
> MST

Re: [Qemu-devel] [virtio-dev] [PATCH 4/4] virtio-net: add linkspeed and duplex settings to virtio-net

[Yan Vugenfirer]

> On 2 Mar 2018, at 22:19, Michael S. Tsirkin  wrote:
> 
> On Fri, Mar 02, 2018 at 03:14:01PM +0800, Jason Wang wrote:
>> 
>> 
>> On 2018年03月02日 11:46, Jason Baron wrote:
>>> Although linkspeed and duplex can be set in a linux guest via 'ethtool -s',
>>> this requires custom ethtool commands for virtio-net by default.
>>> 
>>> Introduce a new feature flag, VIRTIO_NET_F_SPEED_DUPLEX, which allows
>>> the hypervisor to export a linkspeed and duplex setting. The user can
>>> subsequently overwrite it later if desired via: 'ethtool -s'.
>>> 
>>> Linkspeed and duplex settings can be set as:
>>> '-device virtio-net,speed=1,duplex=full'
>> 
>> I was thinking whether or not it's better to decide the duplex by the type
>> of backends.
>> 
>> E.g userspace and vhost-kernel implement a in fact half duplex. But dpdk
>> implement a full duplex.
>> 
>> Thanks
> 
> OTOH it's a priority for some people to be able to support migration
> between different backend types. Breaking that won't be nice.

I think that in this case we need a way to update the settings of link speed 
and link duplex (maybe add QMP command). Migration between different backend 
types should cause link down\link up events. And this is a time for a driver to 
re-read the settings and update the OS.

Best regards,
Yan.

> 
>>> 
>>> where speed is [0...INT_MAX], and duplex is ["half"|"full"].
>>> 
>>> Signed-off-by: Jason Baron
>>> Cc: "Michael S. Tsirkin"
>>> Cc: Jason Wang
>>> Cc:virtio-...@lists.oasis-open.org
>>> ---
> 
> -
> To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org
> For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org

Re: [Qemu-devel] Windows vioinput guest driver tablet input bug

[Yan Vugenfirer]

Hello Justin,

Thanks a lot for the patch proposal.
I opened the issue on virtio-win GitHub page to track the issue: 
https://github.com/virtio-win/kvm-guest-drivers-windows/issues/249

Best regards,
Yan.

> On 25 Feb 2018, at 13:41, Justin Gatzen  wrote:
> 
> The last email's diff got mangled due to long lines. The original
> source has long lines still but it shouldnt get cut off his time.
> 
> Justin,
> 
> 
> diff --git a/vioinput/sys/HidMouse.c b/vioinput/sys/HidMouse.c
> index 69dac235..528bd3d6 100644
> --- a/vioinput/sys/HidMouse.c
> +++ b/vioinput/sys/HidMouse.c
> @@ -325,7 +325,12 @@ HIDMouseProbe(
> DynamicArrayReserve(, AXIS_MAP_INITIAL_LENGTH * 2 * 
> sizeof(ULONG));
> 
> // Windows won't drive a mouse without at least the X and Y relative axes
> -if (InputCfgDataHasBit(pRelAxes, REL_X) && InputCfgDataHasBit(pRelAxes, 
> REL_Y))
> +if (InputCfgDataHasBit(pRelAxes, REL_X) && InputCfgDataHasBit(pRelAxes, 
> REL_Y)
> +#ifdef EXPOSE_ABS_AXES_WITH_BUTTONS_AS_MOUSE
> +|| (pMouseDesc->uNumOfButtons > 0 && InputCfgDataHasBit(pAbsAxes, 
> ABS_X)
> +&& InputCfgDataHasBit(pAbsAxes, ABS_Y))
> +#endif // EXPOSE_ABS_AXES_WITH_BUTTONS_AS_MOUSE
> +)
> {
> for (i = 0; i < pRelAxes->size; i++)
> {
> @@ -391,7 +396,8 @@ HIDMouseProbe(
> }
> 
> #ifdef EXPOSE_ABS_AXES_WITH_BUTTONS_AS_MOUSE
> -if (uNumOfRelAxes == 0 &&
> +if ((!InputCfgDataHasBit(pRelAxes, REL_X) ||
> + !InputCfgDataHasBit(pRelAxes, REL_Y)) &&
> pMouseDesc->uNumOfButtons > 0 &&
> InputCfgDataHasBit(pAbsAxes, ABS_X) && InputCfgDataHasBit(pAbsAxes, 
> ABS_Y))
> {
> 
> 
> On Sun, Feb 25, 2018 at 05:21:29AM -0500, Justin Gatzen wrote:
>> Hi,
>> 
>> The vioinput Windows guest driver does not seem to work with mouse wheel or
>> side buttons for virtio-tablet-pci devices, while virtio-mouse-pci works as
>> expected. Linux guest drivers are unaffected. Tablets are being categorized 
>> as
>> mice due to the EXPOSE_ABS_AXES_WITH_BUTTONS_AS_MOUSE compile flag. But when
>> there are no relative REL_X or REL_Y input axes the driver ignores all other
>> relative axis entries. Mouse wheel is one such relative axis. I've attached a
>> proof of concept fix for the guest driver that seems to fix both the mouse
>> wheel and side buttons but I believe this needs a more robust fix and deeper
>> look at the HIDMouseProbe function.
>> 
>> Thanks,
>> Justin
>> 
>> 
>> diff --git a/vioinput/sys/HidMouse.c b/vioinput/sys/HidMouse.c
>> index 69dac235..ea188991 100644
>> --- a/vioinput/sys/HidMouse.c
>> +++ b/vioinput/sys/HidMouse.c
>> @@ -325,7 +325,11 @@ HIDMouseProbe(
>> DynamicArrayReserve(, AXIS_MAP_INITIAL_LENGTH * 2 * 
>> sizeof(ULONG));
>> 
>> // Windows won't drive a mouse without at least the X and Y relative axes
>> -if (InputCfgDataHasBit(pRelAxes, REL_X) &&
>> InputCfgDataHasBit(pRelAxes, REL_Y))
>> +if (InputCfgDataHasBit(pRelAxes, REL_X) &&
>> InputCfgDataHasBit(pRelAxes, REL_Y)
>> +#ifdef EXPOSE_ABS_AXES_WITH_BUTTONS_AS_MOUSE
>> +|| (pMouseDesc->uNumOfButtons > 0 &&
>> InputCfgDataHasBit(pAbsAxes, ABS_X) && InputCfgDataHasBit(pAbsAxes,
>> ABS_Y))
>> +#endif // EXPOSE_ABS_AXES_WITH_BUTTONS_AS_MOUSE
>> +)
>> {
>> for (i = 0; i < pRelAxes->size; i++)
>> {
>> @@ -391,7 +395,7 @@ HIDMouseProbe(
>> }
>> 
>> #ifdef EXPOSE_ABS_AXES_WITH_BUTTONS_AS_MOUSE
>> -if (uNumOfRelAxes == 0 &&
>> +if ((!InputCfgDataHasBit(pRelAxes, REL_X) ||
>> !InputCfgDataHasBit(pRelAxes, REL_Y)) &&
>> pMouseDesc->uNumOfButtons > 0 &&
>> InputCfgDataHasBit(pAbsAxes, ABS_X) &&
>> InputCfgDataHasBit(pAbsAxes, ABS_Y))
>> {
> 

[Qemu-devel] [Bug 1734810] Re: Windows guest virtual PC running abnormally slow

[Yan Vugenfirer]

I am constantly running Windows 10 and Windows Server 2016 and I don't
experience specific slowdowns.

QEMU command line is needed to understand the specific setup that might
be problematic.

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1734810

Title:
  Windows guest virtual PC running abnormally slow

Status in Boxes:
  New
Status in KVM:
  New
Status in libvirt:
  New
Status in QEMU:
  Incomplete
Status in spice related packages:
  Confirmed
Status in gnome-boxes package in Ubuntu:
  Confirmed

Bug description:
  Guest systems running Windows 10 in a virtualized environment run
  unacceptably slow, with no option in Boxes to offer the virtual
  machine more (or less) cores from my physical CPU.

  ProblemType: Bug
  DistroRelease: Ubuntu 17.10
  Package: gnome-boxes 3.26.1-1
  ProcVersionSignature: Ubuntu 4.13.0-17.20-lowlatency 4.13.8
  Uname: Linux 4.13.0-17-lowlatency x86_64
  ApportVersion: 2.20.7-0ubuntu3.5
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Tue Nov 28 00:37:11 2017
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: gnome-boxes
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/gnome-boxes/+bug/1734810/+subscriptions

Re: [Qemu-devel] [PATCH 2/2] qemu: add linkspeed and duplex setting to virtio-net

[Yan Vugenfirer]

> On 20 Dec 2017, at 16:31, Michael S. Tsirkin <m...@redhat.com> wrote:
> 
> On Tue, Dec 19, 2017 at 11:52:39AM -0500, Jason Baron wrote:
>> 
>> 
>> On 12/19/2017 04:19 AM, Yan Vugenfirer wrote:
>>> 
>>>> On 18 Dec 2017, at 18:04, Jason Baron via Qemu-devel
>>>> <qemu-devel@nongnu.org <mailto:qemu-devel@nongnu.org>> wrote:
>>>> 
>>>> 
>>>> 
>>>> On 12/18/2017 06:34 AM, Yan Vugenfirer wrote:
>>>>> 
>>>>>> On 14 Dec 2017, at 21:33, Jason Baron via Qemu-devel
>>>>>> <qemu-devel@nongnu.org <mailto:qemu-devel@nongnu.org>> wrote:
>>>>>> 
>>>>>> Although they can be currently set in linux via 'ethtool -s', this
>>>>>> requires
>>>>>> guest changes, and thus it would be nice to extend this
>>>>>> functionality such
>>>>>> that it can be configured automatically from the host (as other network
>>>>>> do).
>>>>>> 
>>>>>> Linkspeed and duplex settings can be set as:
>>>>>> '-device virtio-net,speed=1,duplex=full'
>>>>>> 
>>>>>> where speed is [-1...INT_MAX], and duplex is ["half"|"full"].
>>>>>> 
>>>>>> Signed-off-by: Jason Baron <jba...@akamai.com
>>>>>> <mailto:jba...@akamai.com>>
>>>>>> Cc: "Michael S. Tsirkin" <m...@redhat.com <mailto:m...@redhat.com>>
>>>>>> Cc: Jason Wang <jasow...@redhat.com <mailto:jasow...@redhat.com>>
>>>>>> ---
>>>>>> hw/net/virtio-net.c | 29
>>>>>> +
>>>>>> include/hw/virtio/virtio-net.h  |  3 +++
>>>>>> include/standard-headers/linux/virtio_net.h |  4 
>>>>>> 3 files changed, 36 insertions(+)
>>>>>> 
>>>>>> diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
>>>>>> index 38674b0..d63e790 100644
>>>>>> --- a/hw/net/virtio-net.c
>>>>>> +++ b/hw/net/virtio-net.c
>>>>>> @@ -40,6 +40,12 @@
>>>>>> #define VIRTIO_NET_RX_QUEUE_MIN_SIZE VIRTIO_NET_RX_QUEUE_DEFAULT_SIZE
>>>>>> #define VIRTIO_NET_TX_QUEUE_MIN_SIZE VIRTIO_NET_TX_QUEUE_DEFAULT_SIZE
>>>>>> 
>>>>>> +/* duplex and speed defines */
>>>>>> +#define DUPLEX_UNKNOWN  0xff
>>>>>> +#define DUPLEX_HALF 0x00
>>>>>> +#define DUPLEX_FULL 0x01
>>>>>> +#define SPEED_UNKNOWN   -1
>>>>>> +
>>>>>> /*
>>>>>> * Calculate the number of bytes up to and including the given 'field' of
>>>>>> * 'container'.
>>>>>> @@ -61,6 +67,8 @@ static VirtIOFeature feature_sizes[] = {
>>>>>> .end = endof(struct virtio_net_config, max_virtqueue_pairs)},
>>>>>>{.flags = 1 << VIRTIO_NET_F_MTU,
>>>>>> .end = endof(struct virtio_net_config, mtu)},
>>>>>> +{.flags = 1 << VIRTIO_NET_F_SPEED_DUPLEX,
>>>>>> + .end = endof(struct virtio_net_config, duplex)},
>>>>>>{}
>>>>>> };
>>>>>> 
>>>>>> @@ -88,6 +96,8 @@ static void virtio_net_get_config(VirtIODevice
>>>>>> *vdev, uint8_t *config)
>>>>>>virtio_stw_p(vdev, , n->status);
>>>>>>virtio_stw_p(vdev, _virtqueue_pairs, n->max_queues);
>>>>>>virtio_stw_p(vdev, , n->net_conf.mtu);
>>>>>> +virtio_stl_p(vdev, , n->net_conf.speed);
>>>>>> +netcfg.duplex = n->net_conf.duplex;
>>>>>>memcpy(netcfg.mac, n->mac, ETH_ALEN);
>>>>>>memcpy(config, , n->config_size);
>>>>>> }
>>>>>> @@ -1941,6 +1951,23 @@ static void
>>>>>> virtio_net_device_realize(DeviceState *dev, Error **errp)
>>>>>>n->host_features |= (0x1 << VIRTIO_NET_F_MTU);
>>>>>>}
>>>>>> 
>>>>>> +n->host_features |= (0x1 << VIRTIO_NET_F_SPEED_DUPLEX);
>>>>>> +if (n->net_conf.duplex_str) {
>>>>>> +if (strncmp(n->net_conf.duplex_str, "half", 5) == 0) {
>>>>>> + 

Re: [Qemu-devel] [PATCH 2/2] qemu: add linkspeed and duplex setting to virtio-net

[Yan Vugenfirer]

> On 20 Dec 2017, at 16:31, Michael S. Tsirkin <m...@redhat.com> wrote:
> 
> On Tue, Dec 19, 2017 at 11:52:39AM -0500, Jason Baron wrote:
>> 
>> 
>> On 12/19/2017 04:19 AM, Yan Vugenfirer wrote:
>>> 
>>>> On 18 Dec 2017, at 18:04, Jason Baron via Qemu-devel
>>>> <qemu-devel@nongnu.org <mailto:qemu-devel@nongnu.org>> wrote:
>>>> 
>>>> 
>>>> 
>>>> On 12/18/2017 06:34 AM, Yan Vugenfirer wrote:
>>>>> 
>>>>>> On 14 Dec 2017, at 21:33, Jason Baron via Qemu-devel
>>>>>> <qemu-devel@nongnu.org <mailto:qemu-devel@nongnu.org>> wrote:
>>>>>> 
>>>>>> Although they can be currently set in linux via 'ethtool -s', this
>>>>>> requires
>>>>>> guest changes, and thus it would be nice to extend this
>>>>>> functionality such
>>>>>> that it can be configured automatically from the host (as other network
>>>>>> do).
>>>>>> 
>>>>>> Linkspeed and duplex settings can be set as:
>>>>>> '-device virtio-net,speed=1,duplex=full'
>>>>>> 
>>>>>> where speed is [-1...INT_MAX], and duplex is ["half"|"full"].
>>>>>> 
>>>>>> Signed-off-by: Jason Baron <jba...@akamai.com
>>>>>> <mailto:jba...@akamai.com>>
>>>>>> Cc: "Michael S. Tsirkin" <m...@redhat.com <mailto:m...@redhat.com>>
>>>>>> Cc: Jason Wang <jasow...@redhat.com <mailto:jasow...@redhat.com>>
>>>>>> ---
>>>>>> hw/net/virtio-net.c | 29
>>>>>> +
>>>>>> include/hw/virtio/virtio-net.h  |  3 +++
>>>>>> include/standard-headers/linux/virtio_net.h |  4 
>>>>>> 3 files changed, 36 insertions(+)
>>>>>> 
>>>>>> diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
>>>>>> index 38674b0..d63e790 100644
>>>>>> --- a/hw/net/virtio-net.c
>>>>>> +++ b/hw/net/virtio-net.c
>>>>>> @@ -40,6 +40,12 @@
>>>>>> #define VIRTIO_NET_RX_QUEUE_MIN_SIZE VIRTIO_NET_RX_QUEUE_DEFAULT_SIZE
>>>>>> #define VIRTIO_NET_TX_QUEUE_MIN_SIZE VIRTIO_NET_TX_QUEUE_DEFAULT_SIZE
>>>>>> 
>>>>>> +/* duplex and speed defines */
>>>>>> +#define DUPLEX_UNKNOWN  0xff
>>>>>> +#define DUPLEX_HALF 0x00
>>>>>> +#define DUPLEX_FULL 0x01
>>>>>> +#define SPEED_UNKNOWN   -1
>>>>>> +
>>>>>> /*
>>>>>> * Calculate the number of bytes up to and including the given 'field' of
>>>>>> * 'container'.
>>>>>> @@ -61,6 +67,8 @@ static VirtIOFeature feature_sizes[] = {
>>>>>> .end = endof(struct virtio_net_config, max_virtqueue_pairs)},
>>>>>>{.flags = 1 << VIRTIO_NET_F_MTU,
>>>>>> .end = endof(struct virtio_net_config, mtu)},
>>>>>> +{.flags = 1 << VIRTIO_NET_F_SPEED_DUPLEX,
>>>>>> + .end = endof(struct virtio_net_config, duplex)},
>>>>>>{}
>>>>>> };
>>>>>> 
>>>>>> @@ -88,6 +96,8 @@ static void virtio_net_get_config(VirtIODevice
>>>>>> *vdev, uint8_t *config)
>>>>>>virtio_stw_p(vdev, , n->status);
>>>>>>virtio_stw_p(vdev, _virtqueue_pairs, n->max_queues);
>>>>>>virtio_stw_p(vdev, , n->net_conf.mtu);
>>>>>> +virtio_stl_p(vdev, , n->net_conf.speed);
>>>>>> +netcfg.duplex = n->net_conf.duplex;
>>>>>>memcpy(netcfg.mac, n->mac, ETH_ALEN);
>>>>>>memcpy(config, , n->config_size);
>>>>>> }
>>>>>> @@ -1941,6 +1951,23 @@ static void
>>>>>> virtio_net_device_realize(DeviceState *dev, Error **errp)
>>>>>>n->host_features |= (0x1 << VIRTIO_NET_F_MTU);
>>>>>>}
>>>>>> 
>>>>>> +n->host_features |= (0x1 << VIRTIO_NET_F_SPEED_DUPLEX);
>>>>>> +if (n->net_conf.duplex_str) {
>>>>>> +if (strncmp(n->net_conf.duplex_str, "half", 5) == 0) {
>>>>>> + 

Re: [Qemu-devel] [PATCH 2/2] qemu: add linkspeed and duplex setting to virtio-net

[Yan Vugenfirer]

> On 18 Dec 2017, at 18:04, Jason Baron via Qemu-devel <qemu-devel@nongnu.org> 
> wrote:
> 
> 
> 
> On 12/18/2017 06:34 AM, Yan Vugenfirer wrote:
>> 
>>> On 14 Dec 2017, at 21:33, Jason Baron via Qemu-devel 
>>> <qemu-devel@nongnu.org> wrote:
>>> 
>>> Although they can be currently set in linux via 'ethtool -s', this requires
>>> guest changes, and thus it would be nice to extend this functionality such
>>> that it can be configured automatically from the host (as other network
>>> do).
>>> 
>>> Linkspeed and duplex settings can be set as:
>>> '-device virtio-net,speed=1,duplex=full'
>>> 
>>> where speed is [-1...INT_MAX], and duplex is ["half"|"full"].
>>> 
>>> Signed-off-by: Jason Baron <jba...@akamai.com>
>>> Cc: "Michael S. Tsirkin" <m...@redhat.com>
>>> Cc: Jason Wang <jasow...@redhat.com>
>>> ---
>>> hw/net/virtio-net.c | 29 
>>> +
>>> include/hw/virtio/virtio-net.h  |  3 +++
>>> include/standard-headers/linux/virtio_net.h |  4 
>>> 3 files changed, 36 insertions(+)
>>> 
>>> diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
>>> index 38674b0..d63e790 100644
>>> --- a/hw/net/virtio-net.c
>>> +++ b/hw/net/virtio-net.c
>>> @@ -40,6 +40,12 @@
>>> #define VIRTIO_NET_RX_QUEUE_MIN_SIZE VIRTIO_NET_RX_QUEUE_DEFAULT_SIZE
>>> #define VIRTIO_NET_TX_QUEUE_MIN_SIZE VIRTIO_NET_TX_QUEUE_DEFAULT_SIZE
>>> 
>>> +/* duplex and speed defines */
>>> +#define DUPLEX_UNKNOWN  0xff
>>> +#define DUPLEX_HALF 0x00
>>> +#define DUPLEX_FULL 0x01
>>> +#define SPEED_UNKNOWN   -1
>>> +
>>> /*
>>> * Calculate the number of bytes up to and including the given 'field' of
>>> * 'container'.
>>> @@ -61,6 +67,8 @@ static VirtIOFeature feature_sizes[] = {
>>> .end = endof(struct virtio_net_config, max_virtqueue_pairs)},
>>>{.flags = 1 << VIRTIO_NET_F_MTU,
>>> .end = endof(struct virtio_net_config, mtu)},
>>> +{.flags = 1 << VIRTIO_NET_F_SPEED_DUPLEX,
>>> + .end = endof(struct virtio_net_config, duplex)},
>>>{}
>>> };
>>> 
>>> @@ -88,6 +96,8 @@ static void virtio_net_get_config(VirtIODevice *vdev, 
>>> uint8_t *config)
>>>virtio_stw_p(vdev, , n->status);
>>>virtio_stw_p(vdev, _virtqueue_pairs, n->max_queues);
>>>virtio_stw_p(vdev, , n->net_conf.mtu);
>>> +virtio_stl_p(vdev, , n->net_conf.speed);
>>> +netcfg.duplex = n->net_conf.duplex;
>>>memcpy(netcfg.mac, n->mac, ETH_ALEN);
>>>memcpy(config, , n->config_size);
>>> }
>>> @@ -1941,6 +1951,23 @@ static void virtio_net_device_realize(DeviceState 
>>> *dev, Error **errp)
>>>n->host_features |= (0x1 << VIRTIO_NET_F_MTU);
>>>}
>>> 
>>> +n->host_features |= (0x1 << VIRTIO_NET_F_SPEED_DUPLEX);
>>> +if (n->net_conf.duplex_str) {
>>> +if (strncmp(n->net_conf.duplex_str, "half", 5) == 0) {
>>> +n->net_conf.duplex = DUPLEX_HALF;
>>> +} else if (strncmp(n->net_conf.duplex_str, "full", 5) == 0) {
>>> +n->net_conf.duplex = DUPLEX_FULL;
>>> +} else {
>>> +error_setg(errp, "'duplex' must be 'half' or 'full'");
>>> +}
>>> +} else {
>>> +n->net_conf.duplex = DUPLEX_UNKNOWN;
>>> +}
>>> +if (n->net_conf.speed < SPEED_UNKNOWN) {
>>> +error_setg(errp, "'speed' must be between -1 (SPEED_UNKOWN) 
>>> and "
>>> +   "INT_MAX");
>>> +}
>>> +
>>>virtio_net_set_config_size(n, n->host_features);
>>>virtio_init(vdev, "virtio-net", VIRTIO_ID_NET, n->config_size);
>>> 
>>> @@ -2160,6 +2187,8 @@ static Property virtio_net_properties[] = {
>>>DEFINE_PROP_UINT16("host_mtu", VirtIONet, net_conf.mtu, 0),
>>>DEFINE_PROP_BOOL("x-mtu-bypass-backend", VirtIONet, mtu_bypass_backend,
>>> true),
>>> +DEFINE_PROP_INT32("speed", VirtIONet, net_conf.speed, SPEED_UNKNOWN),
>> 
>> From Windows guest perspective I prefer to have

Re: [Qemu-devel] [PATCH 2/2] qemu: add linkspeed and duplex setting to virtio-net

[Yan Vugenfirer]

> On 14 Dec 2017, at 21:33, Jason Baron via Qemu-devel  
> wrote:
> 
> Although they can be currently set in linux via 'ethtool -s', this requires
> guest changes, and thus it would be nice to extend this functionality such
> that it can be configured automatically from the host (as other network
> do).
> 
> Linkspeed and duplex settings can be set as:
> '-device virtio-net,speed=1,duplex=full'
> 
> where speed is [-1...INT_MAX], and duplex is ["half"|"full"].
> 
> Signed-off-by: Jason Baron 
> Cc: "Michael S. Tsirkin" 
> Cc: Jason Wang 
> ---
> hw/net/virtio-net.c | 29 +
> include/hw/virtio/virtio-net.h  |  3 +++
> include/standard-headers/linux/virtio_net.h |  4 
> 3 files changed, 36 insertions(+)
> 
> diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
> index 38674b0..d63e790 100644
> --- a/hw/net/virtio-net.c
> +++ b/hw/net/virtio-net.c
> @@ -40,6 +40,12 @@
> #define VIRTIO_NET_RX_QUEUE_MIN_SIZE VIRTIO_NET_RX_QUEUE_DEFAULT_SIZE
> #define VIRTIO_NET_TX_QUEUE_MIN_SIZE VIRTIO_NET_TX_QUEUE_DEFAULT_SIZE
> 
> +/* duplex and speed defines */
> +#define DUPLEX_UNKNOWN  0xff
> +#define DUPLEX_HALF 0x00
> +#define DUPLEX_FULL 0x01
> +#define SPEED_UNKNOWN   -1
> +
> /*
>  * Calculate the number of bytes up to and including the given 'field' of
>  * 'container'.
> @@ -61,6 +67,8 @@ static VirtIOFeature feature_sizes[] = {
>  .end = endof(struct virtio_net_config, max_virtqueue_pairs)},
> {.flags = 1 << VIRTIO_NET_F_MTU,
>  .end = endof(struct virtio_net_config, mtu)},
> +{.flags = 1 << VIRTIO_NET_F_SPEED_DUPLEX,
> + .end = endof(struct virtio_net_config, duplex)},
> {}
> };
> 
> @@ -88,6 +96,8 @@ static void virtio_net_get_config(VirtIODevice *vdev, 
> uint8_t *config)
> virtio_stw_p(vdev, , n->status);
> virtio_stw_p(vdev, _virtqueue_pairs, n->max_queues);
> virtio_stw_p(vdev, , n->net_conf.mtu);
> +virtio_stl_p(vdev, , n->net_conf.speed);
> +netcfg.duplex = n->net_conf.duplex;
> memcpy(netcfg.mac, n->mac, ETH_ALEN);
> memcpy(config, , n->config_size);
> }
> @@ -1941,6 +1951,23 @@ static void virtio_net_device_realize(DeviceState 
> *dev, Error **errp)
> n->host_features |= (0x1 << VIRTIO_NET_F_MTU);
> }
> 
> +n->host_features |= (0x1 << VIRTIO_NET_F_SPEED_DUPLEX);
> +if (n->net_conf.duplex_str) {
> +if (strncmp(n->net_conf.duplex_str, "half", 5) == 0) {
> +n->net_conf.duplex = DUPLEX_HALF;
> +} else if (strncmp(n->net_conf.duplex_str, "full", 5) == 0) {
> +n->net_conf.duplex = DUPLEX_FULL;
> +} else {
> +error_setg(errp, "'duplex' must be 'half' or 'full'");
> +}
> +} else {
> +n->net_conf.duplex = DUPLEX_UNKNOWN;
> +}
> +if (n->net_conf.speed < SPEED_UNKNOWN) {
> +error_setg(errp, "'speed' must be between -1 (SPEED_UNKOWN) and "
> +   "INT_MAX");
> +}
> +
> virtio_net_set_config_size(n, n->host_features);
> virtio_init(vdev, "virtio-net", VIRTIO_ID_NET, n->config_size);
> 
> @@ -2160,6 +2187,8 @@ static Property virtio_net_properties[] = {
> DEFINE_PROP_UINT16("host_mtu", VirtIONet, net_conf.mtu, 0),
> DEFINE_PROP_BOOL("x-mtu-bypass-backend", VirtIONet, mtu_bypass_backend,
>  true),
> +DEFINE_PROP_INT32("speed", VirtIONet, net_conf.speed, SPEED_UNKNOWN),

From Windows guest perspective I prefer to have some reasonable default (10G 
for example). 

Thanks,
Yan.

> +DEFINE_PROP_STRING("duplex", VirtIONet, net_conf.duplex_str),
> DEFINE_PROP_END_OF_LIST(),
> };
> 
> diff --git a/include/hw/virtio/virtio-net.h b/include/hw/virtio/virtio-net.h
> index b81b6a4..af74a94 100644
> --- a/include/hw/virtio/virtio-net.h
> +++ b/include/hw/virtio/virtio-net.h
> @@ -38,6 +38,9 @@ typedef struct virtio_net_conf
> uint16_t rx_queue_size;
> uint16_t tx_queue_size;
> uint16_t mtu;
> +int32_t speed;
> +char *duplex_str;
> +uint8_t duplex;
> } virtio_net_conf;
> 
> /* Maximum packet size we can receive from tap device: header + 64k */
> diff --git a/include/standard-headers/linux/virtio_net.h 
> b/include/standard-headers/linux/virtio_net.h
> index 30ff249..0ff1447 100644
> --- a/include/standard-headers/linux/virtio_net.h
> +++ b/include/standard-headers/linux/virtio_net.h
> @@ -36,6 +36,7 @@
> #define VIRTIO_NET_F_GUEST_CSUM   1   /* Guest handles pkts w/ 
> partial csum */
> #define VIRTIO_NET_F_CTRL_GUEST_OFFLOADS 2 /* Dynamic offload configuration. 
> */
> #define VIRTIO_NET_F_MTU  3   /* Initial MTU advice */
> +#define VIRTIO_NET_F_SPEED_DUPLEX 4  /* Host set linkspeed and duplex */
> #define VIRTIO_NET_F_MAC  5   /* Host has given MAC address. */
> #define VIRTIO_NET_F_GUEST_TSO4   7   /* Guest can handle TSOv4 in. */
> #define 

[Qemu-devel] [Bug 1318474] Re: QEMU update causes Windows reactivation

[Yan Vugenfirer]

When updating QEMU use specific machine type and this will keep "old"
HW.

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1318474

Title:
  QEMU update causes Windows reactivation

Status in QEMU:
  Expired

Bug description:
  After updating QEMU the guest OS's detect new hardware. As a result
  any Windows OS sees it as a significant change in hardware and require
  a reactivation.

  Host OS: Ubuntu 14.04 64-bit

  Guest OS's:
  Windows Server 2003 R2 Enterprise
  Windows Server 2008 R2 Enterprise
  Windows Server 2008 R2 Web
  Windows Server 2008 R2 Data Center

  QEMU version: 2.0.0

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1318474/+subscriptions

Re: [Qemu-devel] [virtio-dev] [PATCH 1/1] virtio-balloon: include buffers and chached memory statistics

[Yan Vugenfirer]

Hello All,

Michael asked me to comment regarding the possibility to get this statistics on 
Windows.
By using Win32_OperatingSystem WMI class we can calculate the amount of cached 
memory (https://msdn.microsoft.com/en-us/library/aa394239(v=vs.85).aspx 
 
http://brandonlive.com/2010/02/21/measuring-memory-usage-in-windows-7/ 
), but 
Windows doesn’t let to distinguish between “cached and buffers” as far as I 
see. 

Best regards,
Yan.

> On 20 Sep 2017, at 19:05, Tomáš Golembiovský  wrote:
> 
> Signed-off-by: Tomáš Golembiovský 
> ---
> hw/virtio/virtio-balloon.c  | 2 ++
> include/standard-headers/linux/virtio_balloon.h | 4 +++-
> 2 files changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/hw/virtio/virtio-balloon.c b/hw/virtio/virtio-balloon.c
> index a705e0ec55..0434784c14 100644
> --- a/hw/virtio/virtio-balloon.c
> +++ b/hw/virtio/virtio-balloon.c
> @@ -49,6 +49,8 @@ static const char *balloon_stat_names[] = {
>[VIRTIO_BALLOON_S_MEMFREE] = "stat-free-memory",
>[VIRTIO_BALLOON_S_MEMTOT] = "stat-total-memory",
>[VIRTIO_BALLOON_S_AVAIL] = "stat-available-memory",
> +   [VIRTIO_BALLOON_S_BUFFERS] = "stat-linux-buffers",
> +   [VIRTIO_BALLOON_S_CACHED] = "stat-linux-cached",
>[VIRTIO_BALLOON_S_NR] = NULL
> };
> 
> diff --git a/include/standard-headers/linux/virtio_balloon.h 
> b/include/standard-headers/linux/virtio_balloon.h
> index 9d06ccd066..d61efbfcee 100644
> --- a/include/standard-headers/linux/virtio_balloon.h
> +++ b/include/standard-headers/linux/virtio_balloon.h
> @@ -52,7 +52,9 @@ struct virtio_balloon_config {
> #define VIRTIO_BALLOON_S_MEMFREE  4   /* Total amount of free memory */
> #define VIRTIO_BALLOON_S_MEMTOT   5   /* Total amount of memory */
> #define VIRTIO_BALLOON_S_AVAIL6   /* Available memory as in /proc */
> -#define VIRTIO_BALLOON_S_NR   7
> +#define VIRTIO_BALLOON_S_BUFFERS  7   /* Buffers memory as in /proc */
> +#define VIRTIO_BALLOON_S_CACHED   8   /* Cached memory as in /proc */
> +#define VIRTIO_BALLOON_S_NR   9
> 
> /*
>  * Memory statistics structure.
> -- 
> 2.14.1
> 
> 
> -
> To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org
> For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
> 

Re: [Qemu-devel] [Question] why need to start all queues in vhost_net_start

[Yan Vugenfirer]

Hi Jason,

Windows driver will initialise only the amount of queue based on the amount of 
available vCPUs. So if there will be more queues in the device than we have 
vCPUs on the guest, the driver will not initialise “excessive” queues. This is 
tied to the way RSS on Windows should be implemented.
Exactly as in described scenario (7 queues, but only 4 vCPUs).

Best regards,
Yan.

> On 16 Nov 2017, at 07:53, Longpeng (Mike)  wrote:
> 
> Hi Jason & Michael,
> 
> Do you have any idea about this problem ?
> 
> -- 
> Regards,
> Longpeng(Mike)
> 
> On 2017/11/15 23:54, Longpeng(Mike) wrote:
> 
>> 2017-11-15 23:05 GMT+08:00 Jason Wang :
>>> 
>>> 
>>> On 2017年11月15日 22:55, Longpeng(Mike) wrote:
 
 Hi guys,
 
 We got a BUG report from our testers yesterday, the testing scenario was
 migrating a VM (Windows guest, *4 vcpus*, 4GB, vhost-user net: *7
 queues*).
 
 We found the cause reason, and we'll report the BUG or send a fix patch
 to upstream if necessary( we haven't test the upstream yet, sorry... ).
>>> 
>>> 
>>> Could you explain this a little bit more?
>>> 
 
 We want to know why the vhost_net_start() must start *total queues* ( in
 our
 VM there're 7 queues ) but not *the queues that current used* ( in our VM,
 guest
 only uses the first 4 queues because it's limited by the number of vcpus)
 ?
 
 Looking forward to your help, thx :)
>>> 
>>> 
>>> Since the codes have been there for years and works well for kernel
>>> datapath. You should really explain what's wrong.
>>> 
>> 
>> OK. :)
>> 
>> In our scenario,  the Windows's virtio-net driver only use the first 4
>> queues and it
>> *only set desc/avail/used table for the first 4 queues*, so in QEMU
>> the desc/avail/
>> used of the last 3 queues are ZERO,  but unfortunately...
>> '''
>> vhost_net_start
>>  for (i = 0; i < total_queues; i++)
>>vhost_net_start_one
>>  vhost_dev_start
>>vhost_virtqueue_start
>> '''
>> In vhost_virtqueue_start(), it will calculate the HVA of
>> desc/avail/used table, so for last
>> 3 queues, it will use ZERO as the GPA to calculate the HVA, and then
>> send the results
>> to the user-mode backend ( we use *vhost-user* ) by 
>> vhost_virtqueue_set_addr().
>> 
>> When the EVS get these address, it will update a *idx* which will be
>> treated as  vq's
>> last_avail_idx when virtio-net stop ( pls see vhost_virtqueue_stop() ).
>> 
>> So we get the following result after virtio-net stop:
>>  the desc/avail/used of the last 3 queues's vqs are all ZERO, but these vqs's
>>  last_avail_idx is NOT ZERO.
>> 
>> At last, virtio_load() reports an error:
>> '''
>>  if (!vdev->vq[i].vring.desc && vdev->vq[i].last_avail_idx) { // <--
>> will be TRUE
>>  error_report("VQ %d address 0x0 "
>> "inconsistent with Host index 0x%x",
>> i, vdev->vq[i].last_avail_idx);
>>return -1;
>>   }
>> '''
>> 
>> BTW, the problem won't appear if use Linux guest, because the Linux 
>> virtio-net
>> driver will set all 7 queues's desc/avail/used tables. And the problem
>> won't appear
>> if the VM use vhost-net, because vhost-net won't update *idx* in SET_ADDR 
>> ioctl.
>> 
>> Sorry for my pool English, Maybe I could describe the problem in Chinese for 
>> you
>> in private if necessary.
>> 
>> 
>>> Thanks
>> 
>> 
> 
> 
> -- 
> Regards,
> Longpeng(Mike)

Re: [Qemu-devel] virtio multiqueue RX frame classification

[Yan Vugenfirer]

Hi Alin,

Unfortunately it is not possible today. It would be very helpful for optimising 
RSS on Windows guest as well.

Best regards,
Yan.


> On 27 Oct 2017, at 19:12, Alin Rauta  wrote:
> 
> Hi,
> I have a question regarding receive pkts classification in QEMU.
> The virtIO spec states that the receive flow classification is implicit when 
> enabling multiqueue support, but are there any ways to control the actual RX 
> classification from inside the guest system or know how it is done?  As 
> example, let's say the guest system wants to get the pkts with a specific 
> ethernet type or UDP port on a virtIO queue or set of queues.
> Thanks,
> Alin

Re: [Qemu-devel] ivshmem Windows Driver

[Yan Vugenfirer]

> On 15 Oct 2017, at 15:21, ge...@hostfission.com wrote:
> 
> Hi Yan,
> 
> Thank you for the information. I am rather new to Windows Driver development 
> and learning as I go, so this may take some time, but since the driver only 
> needs to perform very basic functions I do not see this as being too much of 
> a challenge.

I think you can look into Windows virtio-balloon implementation as an example 
of simple driver: 
https://github.com/virtio-win/kvm-guest-drivers-windows/tree/master/Balloon

It relies on virtio library 
(https://github.com/virtio-win/kvm-guest-drivers-windows/tree/master/VirtIO) 
and it is WDF driver (MS framework that simplifies the drivers development) 
that makes it very simple.

> 
> -Geoff
> 
> On 2017-10-15 22:14, Yan Vugenfirer wrote:
>> He Geoff,
>> The official virtio-win drivers upstream repository is here:
>> https://github.com/virtio-win/kvm-guest-drivers-windows
>> 1. There is no ivshmem Windows Driver for now as far as I know
>> 2. We are signing the drivers for community usage
>> https://fedoraproject.org/wiki/Windows_Virtio_Drivers from the same
>> repository.
>> The process will be: submit the code for review with pull request
>> (better use existing virtio library for virtio communication between
>> the guest and the host), pass internal tests and at the least being
>> able to pass MS HCK\HLK tests, later on the driver will be pulled into
>> official build and release with rest of the drivers for community
>> usage.
>> 3. We are happy to cooperate on adding new functionality to current
>> package of virtio drivers for Windows
>> 4. As already mentioned: 
>> https://github.com/virtio-win/kvm-guest-drivers-windows
>> Thanks a lot!
>> If you have more questions, please don’t hesitate to talk to me, Ladi
>> or anyone else from Red Hat involved with virtio-win development.
>> Best regards,
>> Yan.
>>> On 15 Oct 2017, at 12:32, geoff--- via Qemu-devel <qemu-devel@nongnu.org> 
>>> wrote:
>>> Hi All,
>>> I am writing some code that needs to share a block of ram between a Windows 
>>> guest and Linux host. For this I am using the ivshmem device and I have 
>>> written a very primitive driver for windows that allows a single 
>>> application to request to memory map the pci bar (shared memory) into the 
>>> program's context using DeviceIoControl.
>>> This is all working fine, but the next problem is I need the driver to be 
>>> signed. In it's current state I would not even suggest it be signed as it 
>>> was just hacked together to test my concept, but now I know it's viable I 
>>> would be willing to invest whatever time is required to write a driver that 
>>> would be acceptable for signing.
>>> The ideal driver would be general purpose and could be leveraged for any 
>>> user mode application use, not just my specific case. It would need to 
>>> implement the IRQ/even features of ivshmem and possibly even some kind of 
>>> security to prevent unauthorized use by rogue applications (shared secret 
>>> configured on the chardev?).
>>> I have several qustions:
>>> 1) Has someone done this? I can't find any reference to a windows driver 
>>> for this device anywhere.
>>> 2) If I was to pursue writing this driver, how would be the best way to go 
>>> about it so as to ensure that it is in a state that it could be signed with 
>>> the RedHat vendor key?
>>> 3) What is the likelihood of having such a driver signed?
>>> 4) Is there a preferred git host for such a driver?
>>> Kind Regards
>>> -Geoff
> 

Re: [Qemu-devel] ivshmem Windows Driver

[Yan Vugenfirer]

He Geoff,

The official virtio-win drivers upstream repository is here: 
https://github.com/virtio-win/kvm-guest-drivers-windows

1. There is no ivshmem Windows Driver for now as far as I know

2. We are signing the drivers for community usage 
https://fedoraproject.org/wiki/Windows_Virtio_Drivers from the same repository. 
The process will be: submit the code for review with pull request (better use 
existing virtio library for virtio communication between the guest and the 
host), pass internal tests and at the least being able to pass MS HCK\HLK 
tests, later on the driver will be pulled into official build and release with 
rest of the drivers for community usage.
3. We are happy to cooperate on adding new functionality to current package of 
virtio drivers for Windows
4. As already mentioned: https://github.com/virtio-win/kvm-guest-drivers-windows

Thanks a lot!

If you have more questions, please don’t hesitate to talk to me, Ladi or anyone 
else from Red Hat involved with virtio-win development.

Best regards,
Yan.

> On 15 Oct 2017, at 12:32, geoff--- via Qemu-devel  
> wrote:
> 
> Hi All,
> 
> I am writing some code that needs to share a block of ram between a Windows 
> guest and Linux host. For this I am using the ivshmem device and I have 
> written a very primitive driver for windows that allows a single application 
> to request to memory map the pci bar (shared memory) into the program's 
> context using DeviceIoControl.
> 
> This is all working fine, but the next problem is I need the driver to be 
> signed. In it's current state I would not even suggest it be signed as it was 
> just hacked together to test my concept, but now I know it's viable I would 
> be willing to invest whatever time is required to write a driver that would 
> be acceptable for signing.
> 
> The ideal driver would be general purpose and could be leveraged for any user 
> mode application use, not just my specific case. It would need to implement 
> the IRQ/even features of ivshmem and possibly even some kind of security to 
> prevent unauthorized use by rogue applications (shared secret configured on 
> the chardev?).
> 
> I have several qustions:
> 
>  1) Has someone done this? I can't find any reference to a windows driver for 
> this device anywhere.
>  2) If I was to pursue writing this driver, how would be the best way to go 
> about it so as to ensure that it is in a state that it could be signed with 
> the RedHat vendor key?
>  3) What is the likelihood of having such a driver signed?
>  4) Is there a preferred git host for such a driver?
> 
> Kind Regards
> -Geoff
> 

Re: [Qemu-devel] [virtio-dev] virtio-net: configurable TX queue size

[Yan Vugenfirer]

> On 5 May 2017, at 12:20, Jason Wang  wrote:
> 
> 
> 
> On 2017年05月05日 13:53, Wei Wang wrote:
>> On 05/05/2017 10:27 AM, Jason Wang wrote:
>>> 
>>> 
>>> On 2017年05月04日 18:58, Wang, Wei W wrote:
 Hi,
 
 I want to re-open the discussion left long time ago:
 https://lists.gnu.org/archive/html/qemu-devel/2015-11/msg06194.html
 , and discuss the possibility of changing the hardcoded (256) TX  queue
 size to be configurable between 256 and 1024.
>>> 
>>> Yes, I think we probably need this.
>> 
>> That's great, thanks.
>> 
>>> 
 
 The reason to propose this request is that a severe issue of packet drops 
 in
 TX direction was observed with the existing hardcoded 256 queue size,
 which causes performance issues for packet drop sensitive guest
 applications that cannot use indirect descriptor tables. The issue goes 
 away
 with 1K queue size.
>>> 
>>> Do we need even more, what if we find 1K is even not sufficient in the 
>>> future? Modern nics has size up to ~8192.
>> 
>> Yes. Probably, we can also set the RX queue size to 8192 (currently it's 1K) 
>> as well.
>> 
>>> 
 
 The concern mentioned in the previous discussion (please check the link
 above) is that the number of chained descriptors would exceed
 UIO_MAXIOV (1024) supported by the Linux.
>>> 
>>> We could try to address this limitation but probably need a new feature bit 
>>> to allow more than UIO_MAXIOV sgs.
>> 
>> I think we should first discuss whether it would be an issue below.
>> 
>>> 
 
 From the code,  I think the number of the chained descriptors is limited to
 MAX_SKB_FRAGS + 2 (~18), which is much less than UIO_MAXIOV.
>>> 
>>> This is the limitation of #page frags for skb, not the iov limitation.
>> 
>> I think the number of page frags are filled into the same number of 
>> descriptors
>> in the virtio-net driver (e.g. use 10 descriptors for 10 page frags). On the 
>> other
>> side, the virtio-net backend uses the same number of iov for the descriptors.
>> 
>> Since the number of page frags is limited to 18, I think there wouldn't be 
>> more
>> than 18 iovs to be passed to writev, right?
> 
This limitation assumption is incorrect for Windows. We saw cases (and 
strangely enough with small packets) when Windows returns scatter gather list 
with 32 descriptors or more.

Best regards,
Yan.

> Looks not, see skb_copy_datagram_from_iter().

> 
> Thanks
> 
>> 
>> Best,
>> Wei
>> 
>> -
>> To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org 
>> 
>> For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org 
>> 
>> 
> 
> 
> -
> To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org 
> 
> For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org 
> 

Re: [Qemu-devel] VirtIO Windows Driver repository

[Yan Vugenfirer]

> On 14 Feb 2017, at 16:08, Laszlo Ersek <ler...@redhat.com> wrote:
> 
> On 02/14/17 13:40, Yan Vugenfirer wrote:
>> Hello All,
>> 
>> The official upstream repository moved from
>> https://github.com/YanVugenfirer/kvm-guest-drivers-windows to
>> https://github.com/virtio-win/kvm-guest-drivers-windows
>> 
>> Best regards, Yan Vugenfirer.
> 
> Thanks! I've updated the corresponding reference under
> <https://fedoraproject.org/wiki/Windows_Virtio_Drivers#Links>.

Thanks!

Do you know who can make a change on 
http://www.linux-kvm.org/page/WindowsGuestDrivers/Repository ?

Best regards,
Yan.

> 
> Cheers
> Laszlo
> 

[Qemu-devel] VirtIO Windows Driver repository

[Yan Vugenfirer]

Hello All,

The official upstream repository moved from 
https://github.com/YanVugenfirer/kvm-guest-drivers-windows to 
https://github.com/virtio-win/kvm-guest-drivers-windows

Best regards,
Yan Vugenfirer.

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

[Yan Vugenfirer]

Hi,

First off all to use more than 64 CPUs on Windows you should use CPU grouping. 
Each group can contain maximum 64 CPUs. Here is a good article explaining 
possible configurations:
https://msdn.microsoft.com/en-us/windows/hardware/drivers/devtest/boot-parameters-to-test-drivers-for-multiple-processor-group-support
 

 and another one on the grouping subject: 
https://blogs.technet.microsoft.com/mlucas/2012/03/15/windows-server-and-processor-cores/
 


Regarding the boot failure - it is quite possible that Windows cannot handle 
more that 64 logical CPUs on one physical CPU. 

Best regards,
Yan.
> On 9 Feb 2017, at 08:18, hangaohuai  wrote:
> 
> Dear all:
> I try to boot windows2012R2 (more than 64 cores)on kvm platform with hyper-v 
> on**.
> the guest halts on the starting time.
> Also tested in these cases:
>   - boot sucess
>   - boot sucess
>   - boot sucess
>   - boot failed
>   - boot sucess(in Guest we can 
> found 64)
>   - boot failed
> 
> Environment:
> GUEST:
>  windows2012R2
> HOST:
>kernel version:4.10.0-rc4
>QEMU version:QEMU emulator version 2.8.50 (v2.8.0-664-gd1c82f7-dirty)
> part of GuestXML:
>  68
>  
>/machine
>  
>  
>hvm
>
>  
>  
>
>
>
>
>  
>
>  
>  
>
>  
> 
> //
> debug info:
> virsh qemu-monitor-command win2012 --hmp "info cpus"
>  CPU #61: pc=0xf8031296a21c thread_id=21410
>  CPU #62: pc=0xf8031296a21c thread_id=21411
>  CPU #63: pc=0xf8031296a21c thread_id=21414
>  CPU #64: pc=0x000fd31c (halted) thread_id=21415
>  CPU #65: pc=0x000fd31c (halted) thread_id=21416
>  CPU #66: pc=0x000fd31c (halted) thread_id=21417
>  CPU #67: pc=0x000fd31c (halted) thread_id=21418
> 
> 
> Any suggestions?
> 
> Thanks a lot.
> 
> Gaohuai Han
> 
> 

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

[Yan Vugenfirer]

 On Jun 8, 2015, at 11:12 AM, Peter Lieven p...@kamp.de wrote:
 
 Am 28.05.2015 um 16:24 schrieb 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.
 
 Hi Yan,
 
 have you had a chance to look at this or a hint where to start?
 

Sorry Peter, somehow I missed the email and saw it only now.

* When you experience the issues is it between VMs on the same host? 

* Can you describe your host network configuration? 

* Can provide the output for ethtool -k” for every NIC (including tap devices) 
in the host that is involved with the VM that has a problem?

 * What are the host kernel version, QEMU version and guest driver version you 
are using?

Thanks,
Yan.

 Thanks,
 Peter
 
 

Re: [Qemu-devel] [Patch V2 0/4] [Patch V2 0/4] Windows MSI installation package

[Yan Vugenfirer]

 On May 6, 2015, at 5:14 PM, Paolo Bonzini pbonz...@redhat.com wrote:
 
 
 
 On 06/05/2015 13:57, Yossi Hindin wrote:
 The second version of commits's set take into account Paolo Bonzini remarks.
 
 Typo in WXS file fixed, QEMU GA-related CLI options renamed, 
 '--enable-guest-agent-msi'/
 '--disable-guest-agent-msi' processing logic changed so that MSI build is 
 configured
 by default, unless some prerequisite is missing and MinGW DLL path variable 
 is computed
 together with all QEMU GA MSI variables. 
 
 Also, I've slightly changed Makefile structure so that if MSI build was not 
 configured,
 Makefile prints suitable message.
 
 
 Yossi Hindin (4):
  qemu-ga: adding vss-[un]install options
  qemu-ga: debug printouts to help troubleshoot installation
  qemu-ga: Introduce Windows MSI script
  qemu-ga: Building Windows MSI installation with configure/Makefile
 
 Makefile  |  24 +++-
 configure |  66 +
 qga/channel-win32.c   |   2 +-
 qga/commands-win32.c  |   1 +
 qga/installer/qemu-ga.wxs | 145 
 ++
 qga/main.c|  10 +++-
 6 files changed, 245 insertions(+), 3 deletions(-)
 create mode 100644 qga/installer/qemu-ga.wxs
 
 
 Reviewed-by: Paolo Bonzini pbonz...@redhat.com
 
 

Ping.

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

[Yan Vugenfirer]

Adding Vadim to the thread.

 On May 29, 2015, at 5:43 PM, Philipp Hahn h...@univention.de 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.
 
 
 We use
 https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/archive-virtio/virtio-win-0.1.104-1/virtio-win-0.1.104.iso
 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 
http://bugzilla.redhat.com/ for virtio-win component or report an issue here: 
https://github.com/YanVugenfirer/kvm-guest-drivers-windows/issues 
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] [PATCH V14 0/3] Virtual Machine Generation ID

[Yan Vugenfirer]

- Original Message -
 From: Michael S. Tsirkin m...@redhat.com
 To: Igor Mammedov imamm...@redhat.com
 Cc: gham...@redhat.com, Yan Vugenfirer yvuge...@redhat.com, 
 qemu-devel@nongnu.org
 Sent: Sunday, April 19, 2015 10:52:37 AM
 Subject: Re: [Qemu-devel] [PATCH V14 0/3] Virtual Machine Generation ID
 
 On Wed, Apr 15, 2015 at 03:59:09PM +0200, Igor Mammedov wrote:
  On Wed, 15 Apr 2015 12:38:57 +0200
  Michael S. Tsirkin m...@redhat.com wrote:
  
   On Tue, Mar 03, 2015 at 05:18:12PM +0100, Igor Mammedov wrote:
Changes since v13:
 * fix comment style to /*... */ in testcase
 * make BAR TARGET_PAGE_SIZE as required by spec
 * make BAR prefetchable, spec also says that it shouldn't be
   marked as non cached
 * ACPI part
* merge separate VGID device with PCI device description
* mark device as not shown in UI,
  it hides VM Generation ID device from device manager
  and leaves only PCI Standard RAM Controller device there
   
   In an offline chat, Yan (Cc) mentioned that with windows guests,
   PCI rebalancing can move BAR values around.
   Yan, could you comment on-list please?
   Is there a way to force this, for testing?
   

Yes. It is part of HCK test kit:
https://msdn.microsoft.com/en-us/library/windows/hardware/jj673015(v=vs.85).aspx#About_rebalance_tests


   ACPI spec mentions this:
   If a platform uses a PCI BAR Target operation region, an ACPI OS will
   not load a native device driver for the associated PCI function. For
   example, if any of the BARs in a PCI function are associated with a PCI
   BAR Target operation region, then the OS will assume that the PCI
   function is to be entirely under the control of the ACPI BIOS. No driver
   will be loaded. Thus, a PCI function can be used as a platform
   controller for some task (hot-plug PCI, and so on) that the ACPI BIOS
   performs.
  It seems that WS2012R2 doesn't honor this part of spec,
  it still tries to find matching driver and load it.
 
 Interesting. Looking at msdn:
 https://msdn.microsoft.com/en-us/library/windows/hardware/ff563877(v=vs.85).aspx
 Looks like what windows does to rebalance is query device for
 rebalancing support, stop driver, rebalance, and restart driver.
 
 If device has no driver, it seems likely windows will assume
 it's safe to rebalance the resources.
 
 There's also a very old document:
 http://www.microsoft.com/whdc/connect/pci/PCI-rsc.mspx
 which says it's possible to implement _DSM method to deny rebalance
 requests.
 Alternatively, we could put this device behind a pci extender, e.g. as
 implemented by Marcel. The resources would then be limited by the _CRS
 or the root.
 
   
   This might also avoid driver prompt from windows?
  it isn't.
 
 

Re: [Qemu-devel] [RFC PATCH 0/2] qga: add guest-get-os-version for windows

[Yan Vugenfirer]

Hi,

My suggestion is to handle the case when the newer OS will be installed in the 
guest as well.

Please look at version helper API - 
http://msdn.microsoft.com/en-us/library/windows/desktop/dn424972(v=vs.85).aspx 
http://msdn.microsoft.com/en-us/library/windows/desktop/dn424972(v=vs.85).aspx
 
and keep in mind that the usual GetVersion and GetVersionEx (that returned 
major, minor versions and build number) will be deprecated or changed after 
Windows 8.1.

Thanks,
Yan.



 On Dec 16, 2014, at 9:30 AM, zhanghailiang zhang.zhanghaili...@huawei.com 
 wrote:
 
 Hi,
 
 This patch series add a new guest command 'guest-get-os-version'.
 It is now only available for windows guest.
 
 It will return guest's OS version name and type, like bellow:
 '{return:{name:Microsoft Windows Server 2012 R2,type:64}}'
 
 Sometimes we need to know guest's OS version info.
 (Actually, we need this info when we update guest's applications and drivers 
 in our project.)
 
 This patch is only RFC, it is another try to add more commands for qemu-ga.
 Though qemu-ga has supported some commands now, but it is not enough and some
 of them only support for linux ...
 
 I would like to enrich it, if someone think it is acceptable.
 
 So, any comments will be welcome! Thanks ;)
 
 zhanghailiang (2):
  qga: Introduce guest-get-os-version command with stubs
  qga: implement qmp_guest_get_os_version for windows
 
 qga/commands-posix.c |   7 +++
 qga/commands-win32.c | 125 +++
 qga/qapi-schema.json |  26 +++
 3 files changed, 158 insertions(+)
 
 -- 
 1.7.12.4
 
 
 

Re: [Qemu-devel] [RFC PATCH 2/2] qga: implement qmp_guest_get_os_version for windows

[Yan Vugenfirer]

 On Dec 16, 2014, at 9:30 AM, zhanghailiang zhang.zhanghaili...@huawei.com 
 wrote:
 
 We can get guest's OS version info by using 'guest-get-os-version',
 The return value contains version name and type (32-bit or 64-bit).
 For example:
 {return:{name:Microsoft Windows Server 2012 R2,type:64}}
 
 Signed-off-by: zhanghailiang zhang.zhanghaili...@huawei.com
 ---
 qga/commands-win32.c | 123 ++-
 1 file changed, 121 insertions(+), 2 deletions(-)
 
 diff --git a/qga/commands-win32.c b/qga/commands-win32.c
 index d133082..7743e1a 100644
 --- a/qga/commands-win32.c
 +++ b/qga/commands-win32.c
 @@ -446,10 +446,129 @@ int64_t qmp_guest_set_vcpus(GuestLogicalProcessorList 
 *vcpus, Error **errp)
 return -1;
 }
 
 +static int get_system_type(Error **errp)
 +{
 +SYSTEM_INFO si;
 +
 +typedef void (WINAPI * LPFN_GetNativeSystemInfo)(LPSYSTEM_INFO 
 systemInfo);
 +LPFN_GetNativeSystemInfo ga_GetNativeSystemInfo =
 + (LPFN_GetNativeSystemInfo)GetProcAddress(
 +  GetModuleHandle(kernel32),
 +  GetNativeSystemInfo);
 +if (ga_GetNativeSystemInfo) {
 +ga_GetNativeSystemInfo(si);
 +} else {
 +GetSystemInfo(si);
 +}
 +
 +if (si.wProcessorArchitecture == PROCESSOR_ARCHITECTURE_AMD64 ||
 +si.wProcessorArchitecture == PROCESSOR_ARCHITECTURE_IA64) {

If one of the motivations is to update drivers on the guest - those should be 
treated as deferent architectures.
Why not return string as well (x64, x86, IA64, ARM)? 

 +return 64;
 +} else {
 +return 32;
 +}
 +}
 +
 +static BOOL compare_windows_version(DWORD dwMajorVersion,
 +DWORD dwMinorVersion)
 +{
 +OSVERSIONINFOEX osvi;
 +DWORDLONG dwlConditionMask = 0;
 +
 +ZeroMemory(osvi, sizeof(OSVERSIONINFOEX));
 +osvi.dwOSVersionInfoSize = sizeof(OSVERSIONINFOEX);
 +osvi.dwMajorVersion = dwMajorVersion;
 +osvi.dwMinorVersion = dwMinorVersion;
 +
 +VER_SET_CONDITION(dwlConditionMask, VER_MAJORVERSION, VER_EQUAL);
 +VER_SET_CONDITION(dwlConditionMask, VER_MINORVERSION, VER_EQUAL);
 +
 +return VerifyVersionInfo(osvi, VER_MAJORVERSION | VER_MINORVERSION,
 + dwlConditionMask);
 +}
 +
 +/*
 +* We get the version by using version information, you can find more info
 +* about operating systems and identical version numbers from bellow links:
 +* http://msdn.microsoft.com/en-us/library/ms724834(v=vs.85).aspx
 +* http://msdn.microsoft.com/en-us/library/ms724832(v=vs.85).aspx
 +*/
 struct GuestOSVersion *qmp_guest_get_os_version(Error **errp)
 {
 -error_set(errp, QERR_UNSUPPORTED);
 -return NULL;
 +OSVERSIONINFOEX osvi;
 +GuestOSVersion *osv = g_malloc0(sizeof(GuestOSVersion));
 +
 +ZeroMemory(osvi, sizeof(OSVERSIONINFOEX));
 +osvi.dwOSVersionInfoSize = sizeof(OSVERSIONINFOEX);
 +if (!(GetVersionEx((OSVERSIONINFO *)osvi))) {
 +error_setg(errp, GetVersionEx failed\n);
 +return NULL;
 +}
 +osv-type = get_system_type(NULL);
 +
 +switch (osvi.dwMajorVersion) {
 +case 5:
 +switch (osvi.dwMinorVersion) {
 +case 0:
 +osv-name = g_strdup(Microsoft Windows 2000);
 +break;
 +case 1:
 +osv-name = g_strdup(Microsoft Windows XP);
 +break;
 +case 2:
 +if (GetSystemMetrics(SM_SERVERR2) == 0) {
 +osv-name = g_strdup(Microsoft Windows Server 2003);
 +} else {
 +osv-name = g_strdup(Microsoft Windows Server 2003 R2);
 +}
 +break;
 + }
 + break; /* case 5*/
 +case 6:
 +switch (osvi.dwMinorVersion) {
 +case 0:
 +if (osvi.wProductType == VER_NT_WORKSTATION) {
 +osv-name = g_strdup(Microsoft Windows Vista);
 +} else {
 +osv-name = g_strdup(Microsoft Windows Server 2008);
 +}
 +break;
 +case 1:
 +if (osvi.wProductType == VER_NT_WORKSTATION) {
 +osv-name = g_strdup(Microsoft Windows 7);
 +} else {
 +osv-name = g_strdup(Microsoft Windows Server 2008 R2);
 +}
 +break;
 +case 2:
 +/*
 +* GetVersionEx APIs have been deprecated.
 +* if we do not specifically target Windows 8.1 Preview,
 +* we will get Windows 8 version. So here we use
 +* VerifyVersionInfo to verify the correct version number.
 +* More info can be found at:
 +* http://msdn.microsoft.com/en-us/library/ms724834(v=vs.85).aspx
 +*/
 +if (compare_windows_version(6, 3)) {
 +if (osvi.wProductType == VER_NT_WORKSTATION) {
 +osv-name = g_strdup(Microsoft Windows 8.1);
 +} else {
 +  

Re: [Qemu-devel] [PATCH] NetKVM: fix for indirectc mode when vring is full

[Yan Vugenfirer]

Thanks!

The fix is correct, but I am not sure this patch is needed.
This is a frozen part of the code with XP and Windows 2003 support for NetKVM 
only.

The library that is used for newer OSes and other drivers has this fix: 
https://github.com/YanVugenfirer/kvm-guest-drivers-windows/commit/264f1b6c86f5eeca5e2c9fbd24e3de8dbd0bee1d

In the NetKVM driver code itself we are testing for those conditions before 
calling to add_buf (check ParaNdis_DoSubmitPacket function in 
https://github.com/YanVugenfirer/kvm-guest-drivers-windows/blob/stable/NetKVM/NDIS5/Common/ParaNdis-Common.c#L1528).

Best regads,
Yan.

 On Dec 10, 2014, at 9:28 AM, Ting Wang kathy.wangt...@huawei.com wrote:
 
 In function vring_add_indirect, there is no limiti
 about free entry in vring. If vring is full,
 vq-num_free will be less than zero, and
 the address of vq-vring.desc becomes illegal.
 
 Signed-off-by: Ting Wang kathy.wangt...@huawei.com
 ---
 NetKVM/NDIS5/VirtIO/VirtIORing.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/NetKVM/NDIS5/VirtIO/VirtIORing.c 
 b/NetKVM/NDIS5/VirtIO/VirtIORing.c
 index 90ace4c..0f3783c 100644
 --- a/NetKVM/NDIS5/VirtIO/VirtIORing.c
 +++ b/NetKVM/NDIS5/VirtIO/VirtIORing.c
 @@ -150,7 +150,7 @@ static int vring_add_buf(struct virtqueue *_vq,
 return -1;
 }
 
 -if (va_indirect)
 +if (va_indirect  (out + in)  1  vq-num_free)
 {
 int ret = vring_add_indirect(_vq, sg, out, in, va_indirect, 
 phys_indirect);
 if (ret = 0)
 -- 
 1.8.5
 
 

Re: [Qemu-devel] [Bug 1308341] Re: Multiple CPUs causes blue screen on Windows guest (14.04 regression)

[Yan Vugenfirer]

Please upload zipped kernel dump or mini dump so it can be examined.

Thanks,
Yan.


On May 26, 2014, at 12:41 PM, Gordon Kaltofen kalto...@dresearch-fe.de wrote:

 Hallo to all, this is my first post here.
 
 I have exactly the same problem occurred after Distribution Update
 Ubuntu Server x64 from 12.04.4 to 14.04.
 
 1. I have Windows 7 32/64-Bit and Windows 2008 Server 64-Bit VMs, all
 show the same error with two dedicated cores (no pinning). In
 combination with the other statements I would say it is a general
 Windows problem - not specific.
 
 2. I have an AMD Opteron 6272 (fam: 15, model: 01, stepping: 02, 16
 cores) system. Therefore, this problem does not seem to be Intel/AMD
 architecture-specific.
 
 3. I configured a couple of VMs ONE core and let it run over the
 weekend. They didn't crashing, but they reacted only very slowly an
 choppy. It seems that there is a fundamental error, which is responsible
 for the multi-core errors. After restarting the VM, the error is
 initially gone, even though the VM is still slow due to only one core.
 
 4. I have the latest virtio drivers are installed in the Windows guest
 systems and use the devices Red Hat VirtIO SCSI and Ethernet (vers.
 61.65.104.7400) drivers. Are these drivers installed in your VMs or do
 you use the IDE/SATA and RTL/Intel-NIC standard driver?
 
 5. The VM images (qcow2) are located on a mdadm Raid1 volume of two
 SSDs. Since Linux kernel 3.7 ATA TRIM is possible with Linux software
 RAID, so I use the mount option 'discard'. I do not want to completely
 exclude the possibility that the error has to do with it.
 
 Is there now an indication of the cause of the failure and possibly even
 a workaround?
 
 -- 
 You received this bug notification because you are a member of qemu-
 devel-ml, which is subscribed to QEMU.
 https://bugs.launchpad.net/bugs/1308341
 
 Title:
  Multiple CPUs causes blue screen on Windows guest (14.04 regression)
 
 Status in QEMU:
  New
 Status in “qemu” package in Ubuntu:
  Confirmed
 Status in “virt-manager” package in Ubuntu:
  Confirmed
 
 Bug description:
  Configuring a Windows 7 guest using more than one CPU cases the guest to 
 fail. This happens after a few hours after guest boot. This is the error on 
 the blue screen:
  A clock interrupt was not received on a secondary processor within the 
 allocated time interval
 
  After resetting, the guest will never boot and a new bluescreen with
  the error STOP: 0x005c appears. Shutting down the guest
  completely and restarting it will allow it to boot and run for a few
  hours again.
 
  The guest was created using virt-manager. The error happens with or
  without virtio devices and with both 32-bit and 64-bit Windows 7
  guests.
 
  I am using Ubuntu 14.04 release candidate.
 
  qemu-kvm version 2.0.0~rc1+dfsg-0ubuntu3
 
 To manage notifications about this bug go to:
 https://bugs.launchpad.net/qemu/+bug/1308341/+subscriptions
 

Re: [Qemu-devel] [PATCH] qga: Fix handle fd leak in acquire_privilege()

[Yan Vugenfirer]

On May 20, 2014, at 10:46 PM, Michael Roth mdr...@linux.vnet.ibm.com wrote:

 Quoting Luiz Capitulino (2014-05-20 14:17:42)
 On Mon, 19 May 2014 15:26:03 +0800
 arei.gong...@huawei.com wrote:
 
 From: Gonglei arei.gong...@huawei.com
 
 token should be closed in all conditions.
 So move CloseHandle(token) to out branch.
 
 Looks good to me. Michael, are you going to pick this one?
 
 Sure I'll queue it. Though i'm a bit surprised OpenProcessToken() will still
 return an open handle on failure. Is there any confirmation a handle is
 actually getting leaked here, as opposed to just returning a handle that's
 already been closed?

It won’t return a handle if it failed (I actually was going to reject the patch 
because of it) - but if you look closely at the code you will see error cases 
after OpenProcessToken was successful where we jump out of the if scope and 
then CloseHandle won’t be called.

Best regards,
Yan.

 
 If it's the latter case we might end up closing it twice after the change,
 so just want to confirm.
 
 
 
 Signed-off-by: Wang Rui moon.wang...@huawei.com
 Signed-off-by: Gonglei arei.gong...@huawei.com
 ---
 qga/commands-win32.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)
 
 diff --git a/qga/commands-win32.c b/qga/commands-win32.c
 index d793dd0..e769396 100644
 --- a/qga/commands-win32.c
 +++ b/qga/commands-win32.c
 @@ -31,7 +31,7 @@
 
 static void acquire_privilege(const char *name, Error **errp)
 {
 -HANDLE token;
 +HANDLE token = NULL;
 TOKEN_PRIVILEGES priv;
 Error *local_err = NULL;
 
 @@ -53,13 +53,15 @@ static void acquire_privilege(const char *name, Error 
 **errp)
 goto out;
 }
 
 -CloseHandle(token);
 } else {
 error_set(local_err, QERR_QGA_COMMAND_FAILED,
   failed to open privilege token);
 }
 
 out:
 +if (token) {
 +CloseHandle(token);
 +}
 if (local_err) {
 error_propagate(errp, local_err);
 }
 
 

Re: [Qemu-devel] [PATCH] qga: Fix handle fd leak in acquire_privilege()

[Yan Vugenfirer]

On May 19, 2014, at 10:26 AM, arei.gong...@huawei.com wrote:

 From: Gonglei arei.gong...@huawei.com
 
 token should be closed in all conditions.
 So move CloseHandle(token) to out branch.
 
 Signed-off-by: Wang Rui moon.wang...@huawei.com
 Signed-off-by: Gonglei arei.gong...@huawei.com
 ---
 qga/commands-win32.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)
 
 diff --git a/qga/commands-win32.c b/qga/commands-win32.c
 index d793dd0..e769396 100644
 --- a/qga/commands-win32.c
 +++ b/qga/commands-win32.c
 @@ -31,7 +31,7 @@
 
 static void acquire_privilege(const char *name, Error **errp)
 {
 -HANDLE token;
 +HANDLE token = NULL;
 TOKEN_PRIVILEGES priv;
 Error *local_err = NULL;
 
 @@ -53,13 +53,15 @@ static void acquire_privilege(const char *name, Error 
 **errp)
 goto out;
 }
 
 -CloseHandle(token);
 } else {
 error_set(local_err, QERR_QGA_COMMAND_FAILED,
   failed to open privilege token);
 }
 
 out:
 +if (token) {
 +CloseHandle(token);
 +}
 if (local_err) {
 error_propagate(errp, local_err);
 }
 -- 
 1.7.12.4
 

Reviewed-by: Yan Vugenfirer y...@daynix.com

Re: [Qemu-devel] [PATCH] net: Update netdev peer on link change

[Yan Vugenfirer]

On Apr 2, 2014, at 11:51 AM, Michael S. Tsirkin m...@redhat.com wrote:

 On Thu, Nov 21, 2013 at 09:05:51PM -0500, Vlad Yasevich wrote:
 When a link change occurs on a backend (like tap), we currently do
 not propage such change to the nic.  As a result, when someone turns
 off a link on a tap device, for instance, then a guest doesn't see
 that change and continues to try to send traffic or run DHCP even
 though the lower-layer is disconnected.  This is OK when the network
 is set up as a HUB since the the guest may be connected to other HUB
 ports too, but when it's set up as a netdev, it makes thinkgs worse.
 
 The patch addresses this by setting the peers link down only when the
 peer is not a HUBPORT device.  With this patch, in the following config
  -netdev tap,id=net0 -device e1000,mac=X,netdev=net0
 when net0 link is turned off, the guest e1000 shows lower-layer link
 down. This allows guests to boot much faster in such configurations.
 With windows guest, it also allows the network to recover properly
 since windows will not configure the link-local IPv4 address, and
 when the link is turned on, the proper address address is configured.
 
 Signed-off-by: Vlad Yasevich vyase...@redhat.com
 ---
 net/net.c | 26 +-
 1 file changed, 17 insertions(+), 9 deletions(-)
 
 diff --git a/net/net.c b/net/net.c
 index 0a88e68..8a084bf 100644
 --- a/net/net.c
 +++ b/net/net.c
 @@ -1065,15 +1065,23 @@ void qmp_set_link(const char *name, bool up, Error 
 **errp)
 nc-info-link_status_changed(nc);
 }
 
 -/* Notify peer. Don't update peer link status: this makes it possible to
 - * disconnect from host network without notifying the guest.
 - * FIXME: is disconnected link status change operation useful?
 - *
 - * Current behaviour is compatible with qemu vlans where there could be
 - * multiple clients that can still communicate with each other in
 - * disconnected mode. For now maintain this compatibility. */
 
 Hmm this went in without much discussion.
 
 But before this change went in, it was possible to control link state on NIC
 and on link separately, without guest noticing.
 
 Why did we decide to drop this functionality?

Not sure there was a real need for the patch.

On other hand Windows guest will not receive IP address from DHCP server if you 
start VM with tap link down and then set it to up without toggling link state 
of the guest device as well.

Yan. 

 
 
 
 -if (nc-peer  nc-peer-info-link_status_changed) {
 -nc-peer-info-link_status_changed(nc-peer);
 +if (nc-peer) {
 +/* Change peer link only if the peer is NIC and then notify peer.
 + * If the peer is a HUBPORT or a backend, we do not change the
 + * link status.
 + *
 + * This behavior is compatible with qemu vlans where there could be
 + * multiple clients that can still communicate with each other in
 + * disconnected mode. For now maintain this compatibility.
 + */
 +if (nc-peer-info-type == NET_CLIENT_OPTIONS_KIND_NIC) {
 +for (i = 0; i  queues; i++) {
 +ncs[i]-peer-link_down = !up;
 +}
 +}
 +if (nc-peer-info-link_status_changed) {
 +nc-peer-info-link_status_changed(nc-peer);
 +}
 }
 }
 
 -- 
 1.8.4.2
 
 

Re: [Qemu-devel] virtio device error reporting best practice?

[Yan Vugenfirer]

On Mar 20, 2014, at 8:51 AM, Michael S. Tsirkin m...@redhat.com wrote:

 On Wed, Mar 19, 2014 at 11:04:19AM +1030, Rusty Russell wrote:
 Dave Airlie airl...@gmail.com writes:
 So I'm looking at how best to do virtio gpu device error reporting,
 and how to deal with illegal stuff,
 
 I've two levels of errors I want to support,
 
 a) unrecoverable or bad guest kernel programming errors,
 
 The QEMU standard approach is to exit at this point.  No, really.
 
 It's easy on the hypervisor but often not very friendly for driver writers
 who might not be qemu experts.
 QEMU's moving away from exiting on errors and it would be nice
 to have a robust way to report driver bugs.
 How about setting VIRTIO_CONFIG_S_DEVICE_FAILED ?
 
 Another idea that windows driver implemented is reporting
 failure reason hint. They wrote it out to ISR, specifically
 they notified host about watchdog timer expiration for net device
 in this way.

I removed it for now and really would like to have an official way to bring it 
back.

Also going back to the original question - Windows can handle graphic cards HW 
errors by reloading the driver and reseting the device (stating from Vista).

 
 b) per 3D context errors from the renderer backend,
 
 (b) I can easily report in an event queue and the guest kernel can in
 theory blow away the offenders, this is how GL works with some
 extensions,
 
 That's probably sanest.
 
 If it's possible to identify the offenders, I agree
 a VQ is better than config space for that.
 Need to make sure the queue is big enough to avoid
 underrun of that queue though. Is that always possible?
 
 GPU control queue, the response should always be no error, but in some
 cases it will be because the guest hit some host resource error, or
 asked for something insane, (guest kernel drivers would be broken in
 most of these cases).
 
 Alternately I can use the separate event queue to send async errors
 when the guest does something bad,
 
 I'm also considering adding some sort of flag in config space saying
 the device needs a reset before it will continue doing anything,
 
 I generally dislike error codes which Never Happen; it's like making
 every void function return int just in case: the caller has no idea what
 to do if it fails.
 
 The litmus test: does *your* guest handle failures other than by giving
 up on the device?  If so, sure, you need to have a sane error-reporting
 strategy.
 
 Right but driver development is also a valid need.
 
 The main reason I'm considering this stuff is for security reasons if
 the guest asks for something really illegal or crazy what should the
 expected behaviour of the host be? (at least secure I know that).
 
 If the guest userspace can do it, don't exit.  If the kernel only, and
 it's should have known better, abort is OK.
 
 I second that, at least for now.
 Maybe we will add more capabilities in virtio 1.0, or
 after that.
 
 Sure that doesn't help much!
 Rusty.

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

[Yan Vugenfirer]

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 n...@linux-iscsi.org 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..?
 
 TIA!
 
 --nab
 
 

[Qemu-devel] [Bug 1130095] Re: Windows Signed Drivers

[Yan Vugenfirer]

The driver in virtio-win-0.1-74.iso are already signed with Red Hat
certificate.

You get the warning because they are not signed with MS WHQL signature.
Signing with ReactIOS certificate will not help.


Best regards,
Yan.

** Changed in: qemu
   Status: New = Invalid

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1130095

Title:
  Windows Signed Drivers

Status in QEMU:
  Invalid

Bug description:
  ReactOS has a general offer (subject to certain conditions, which may
  or may not be reasonable for the qemu virtual-IO drivers) to sign Open
  Source components with their certificate.

  http://www.reactos.org/wiki/Driver_Signing

  The files in virtio-win-0.1-74.iso appear not to be signed, hence
  trigger a warning on Windows 2008 R2.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1130095/+subscriptions

Re: [Qemu-devel] [PATCH 3/3] qga: vss-win32: Fix interference with snapshot deletion by other VSS request

[Yan Vugenfirer]

On Jan 13, 2014, at 7:25 PM, Tomoki Sekiyama tomoki.sekiy...@hds.com wrote:

 When a VSS requester such as vshadow.exe or diskshadow.exe requests to
 delete snapshots, qemu-ga VSS provider's DeleteSnapshots() is also called
 and returns E_NOTIMPL, that makes the deletion fail.
 To avoid this issue, return S_OK and set values that represent no snapshots
 are deleted by qemu-ga VSS provider.
 
 Signed-off-by: Tomoki Sekiyama tomoki.sekiy...@hds.com
 ---
 qga/vss-win32/provider.cpp |4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)
 
 diff --git a/qga/vss-win32/provider.cpp b/qga/vss-win32/provider.cpp
 index b233646..d5129f8 100644
 --- a/qga/vss-win32/provider.cpp
 +++ b/qga/vss-win32/provider.cpp
 @@ -278,7 +278,9 @@ STDMETHODIMP CQGAVssProvider::DeleteSnapshots(
 VSS_ID SourceObjectId, VSS_OBJECT_TYPE eSourceObjectType,
 BOOL bForceDelete, LONG *plDeletedSnapshots, VSS_ID 
 *pNondeletedSnapshotID)
 {
 -return E_NOTIMPL;
 +*plDeletedSnapshots = 0;
 +*pNondeletedSnapshotID = SourceObjectId;
 +return S_OK;
 }
 
 STDMETHODIMP CQGAVssProvider::BeginPrepareSnapshot(
 
 

Reviewed-by: Yan Vugenfirer yvuge...@redhat.com

Re: [Qemu-devel] [PATCH 2/3] qga: vss-win32: Fix interference with snapshot creation by other VSS requesters

[Yan Vugenfirer]

On Jan 13, 2014, at 7:25 PM, Tomoki Sekiyama tomoki.sekiy...@hds.com wrote:

 When a VSS requester such as vshadow.exe or diskshadow.exe requests to
 create disk snapshots, Windows may choose qemu-ga VSS provider if it is
 only provider registered on the system. However, because it provides only a
 function to freeze the filesystem, the snapshotting fails.
 
 This patch adds a check into CQGAVssProvider::IsVolumeSupported() to reject
 the request from other VSS requesters, so that the other provider is chosen.
 
 The check of requester is done by confirming event channels between
 qemu-ga's requester and provider established. To ensure that the events are
 initialized when CQGAVssProvider::IsVolumeSupported() is called, it moves
 the initialization earlier.
 
 Signed-off-by: Tomoki Sekiyama tomoki.sekiy...@hds.com
 ---
 qga/vss-win32/provider.cpp  |   11 -
 qga/vss-win32/requester.cpp |   52 ++-
 2 files changed, 36 insertions(+), 27 deletions(-)
 
 diff --git a/qga/vss-win32/provider.cpp b/qga/vss-win32/provider.cpp
 index c3030d8..b233646 100644
 --- a/qga/vss-win32/provider.cpp
 +++ b/qga/vss-win32/provider.cpp
 @@ -291,8 +291,17 @@ STDMETHODIMP CQGAVssProvider::BeginPrepareSnapshot(
 STDMETHODIMP CQGAVssProvider::IsVolumeSupported(
 VSS_PWSZ pwszVolumeName, BOOL *pbSupportedByThisProvider)
 {
 -*pbSupportedByThisProvider = TRUE;
 +HANDLE hEventFrozen;
 +
 +/* Check if a requester is qemu-ga by whether an event is created */
 +hEventFrozen = OpenEvent(EVENT_ALL_ACCESS, FALSE, EVENT_NAME_FROZEN);
 +if (!hEventFrozen) {
 +*pbSupportedByThisProvider = FALSE;
 +return S_OK;
 +}
 +CloseHandle(hEventFrozen);
 
 +*pbSupportedByThisProvider = TRUE;
 return S_OK;
 }
 
 diff --git a/qga/vss-win32/requester.cpp b/qga/vss-win32/requester.cpp
 index 0a55447..922e74d 100644
 --- a/qga/vss-win32/requester.cpp
 +++ b/qga/vss-win32/requester.cpp
 @@ -252,6 +252,32 @@ void requester_freeze(int *num_vols, ErrorSet *errset)
 
 CoInitialize(NULL);
 
 +/* Allow unrestricted access to events */
 +InitializeSecurityDescriptor(sd, SECURITY_DESCRIPTOR_REVISION);
 +SetSecurityDescriptorDacl(sd, TRUE, NULL, FALSE);
 +sa.nLength = sizeof(sa);
 +sa.lpSecurityDescriptor = sd;
 +sa.bInheritHandle = FALSE;
 +
 +vss_ctx.hEventFrozen = CreateEvent(sa, TRUE, FALSE, EVENT_NAME_FROZEN);
 +if (!vss_ctx.hEventFrozen) {
 +err_set(errset, GetLastError(), failed to create event %s,
 +EVENT_NAME_FROZEN);
 +goto out;
 +}
 +vss_ctx.hEventThaw = CreateEvent(sa, TRUE, FALSE, EVENT_NAME_THAW);
 +if (!vss_ctx.hEventThaw) {
 +err_set(errset, GetLastError(), failed to create event %s,
 +EVENT_NAME_THAW);
 +goto out;
 +}
 +vss_ctx.hEventTimeout = CreateEvent(sa, TRUE, FALSE, 
 EVENT_NAME_TIMEOUT);
 +if (!vss_ctx.hEventTimeout) {
 +err_set(errset, GetLastError(), failed to create event %s,
 +EVENT_NAME_TIMEOUT);
 +goto out;
 +}
 +
 assert(pCreateVssBackupComponents != NULL);
 hr = pCreateVssBackupComponents(vss_ctx.pVssbc);
 if (FAILED(hr)) {
 @@ -362,32 +388,6 @@ void requester_freeze(int *num_vols, ErrorSet *errset)
 goto out;
 }
 
 -/* Allow unrestricted access to events */
 -InitializeSecurityDescriptor(sd, SECURITY_DESCRIPTOR_REVISION);
 -SetSecurityDescriptorDacl(sd, TRUE, NULL, FALSE);
 -sa.nLength = sizeof(sa);
 -sa.lpSecurityDescriptor = sd;
 -sa.bInheritHandle = FALSE;
 -
 -vss_ctx.hEventFrozen = CreateEvent(sa, TRUE, FALSE, EVENT_NAME_FROZEN);
 -if (!vss_ctx.hEventFrozen) {
 -err_set(errset, GetLastError(), failed to create event %s,
 -EVENT_NAME_FROZEN);
 -goto out;
 -}
 -vss_ctx.hEventThaw = CreateEvent(sa, TRUE, FALSE, EVENT_NAME_THAW);
 -if (!vss_ctx.hEventThaw) {
 -err_set(errset, GetLastError(), failed to create event %s,
 -EVENT_NAME_THAW);
 -goto out;
 -}
 -vss_ctx.hEventTimeout = CreateEvent(sa, TRUE, FALSE, 
 EVENT_NAME_TIMEOUT);
 -if (!vss_ctx.hEventTimeout) {
 -err_set(errset, GetLastError(), failed to create event %s,
 -EVENT_NAME_TIMEOUT);
 -goto out;
 -}
 -
 /*
  * Start VSS quiescing operations.
  * CQGAVssProvider::CommitSnapshots will kick vss_ctx.hEventFrozen
 
 

Reviewed-by: Yan Vugenfirer yvuge...@redhat.com

Re: [Qemu-devel] [PATCH 1/3] qga: vss-win32: Use NULL as an invalid pointer for OpenEvent and CreateEvent

[Yan Vugenfirer]

On Jan 13, 2014, at 7:25 PM, Tomoki Sekiyama tomoki.sekiy...@hds.com wrote:

 OpenEvent and CreateEvent WinAPI return NULL when failed to open/create
 events handles, instead of INVALID_HANDLE_VALUE (although their return
 types are HANDLE).
 This replaces INVALID_HANDLE_VALUE related to event handles with NULL.
 
 Signed-off-by: Tomoki Sekiyama tomoki.sekiy...@hds.com
 ---
 qga/vss-win32/provider.cpp  |6 +++---
 qga/vss-win32/requester.cpp |   24 ++--
 2 files changed, 13 insertions(+), 17 deletions(-)
 
 diff --git a/qga/vss-win32/provider.cpp b/qga/vss-win32/provider.cpp
 index bf42b5e..c3030d8 100644
 --- a/qga/vss-win32/provider.cpp
 +++ b/qga/vss-win32/provider.cpp
 @@ -342,18 +342,18 @@ STDMETHODIMP CQGAVssProvider::CommitSnapshots(VSS_ID 
 SnapshotSetId)
 HANDLE hEventFrozen, hEventThaw, hEventTimeout;
 
 hEventFrozen = OpenEvent(EVENT_ALL_ACCESS, FALSE, EVENT_NAME_FROZEN);
 -if (hEventFrozen == INVALID_HANDLE_VALUE) {
 +if (!hEventFrozen) {
 return E_FAIL;
 }
 
 hEventThaw = OpenEvent(EVENT_ALL_ACCESS, FALSE, EVENT_NAME_THAW);
 -if (hEventThaw == INVALID_HANDLE_VALUE) {
 +if (!hEventThaw) {
 CloseHandle(hEventFrozen);
 return E_FAIL;
 }
 
 hEventTimeout = OpenEvent(EVENT_ALL_ACCESS, FALSE, EVENT_NAME_TIMEOUT);
 -if (hEventTimeout == INVALID_HANDLE_VALUE) {
 +if (!hEventTimeout) {
 CloseHandle(hEventFrozen);
 CloseHandle(hEventThaw);
 return E_FAIL;
 diff --git a/qga/vss-win32/requester.cpp b/qga/vss-win32/requester.cpp
 index 1e8dd3d..0a55447 100644
 --- a/qga/vss-win32/requester.cpp
 +++ b/qga/vss-win32/requester.cpp
 @@ -50,10 +50,6 @@ static struct QGAVSSContext {
 
 STDAPI requester_init(void)
 {
 -vss_ctx.hEventFrozen =  INVALID_HANDLE_VALUE;
 -vss_ctx.hEventThaw = INVALID_HANDLE_VALUE;
 -vss_ctx.hEventTimeout = INVALID_HANDLE_VALUE;
 -
 COMInitializer initializer; /* to call CoInitializeSecurity */
 HRESULT hr = CoInitializeSecurity(
 NULL, -1, NULL, NULL, RPC_C_AUTHN_LEVEL_PKT_PRIVACY,
 @@ -94,17 +90,17 @@ STDAPI requester_init(void)
 
 static void requester_cleanup(void)
 {
 -if (vss_ctx.hEventFrozen != INVALID_HANDLE_VALUE) {
 +if (vss_ctx.hEventFrozen) {
 CloseHandle(vss_ctx.hEventFrozen);
 -vss_ctx.hEventFrozen = INVALID_HANDLE_VALUE;
 +vss_ctx.hEventFrozen = NULL;
 }
 -if (vss_ctx.hEventThaw != INVALID_HANDLE_VALUE) {
 +if (vss_ctx.hEventThaw) {
 CloseHandle(vss_ctx.hEventThaw);
 -vss_ctx.hEventThaw = INVALID_HANDLE_VALUE;
 +vss_ctx.hEventThaw = NULL;
 }
 -if (vss_ctx.hEventTimeout != INVALID_HANDLE_VALUE) {
 +if (vss_ctx.hEventTimeout) {
 CloseHandle(vss_ctx.hEventTimeout);
 -vss_ctx.hEventTimeout = INVALID_HANDLE_VALUE;
 +vss_ctx.hEventTimeout = NULL;
 }
 if (vss_ctx.pAsyncSnapshot) {
 vss_ctx.pAsyncSnapshot-Release();
 @@ -374,19 +370,19 @@ void requester_freeze(int *num_vols, ErrorSet *errset)
 sa.bInheritHandle = FALSE;
 
 vss_ctx.hEventFrozen = CreateEvent(sa, TRUE, FALSE, EVENT_NAME_FROZEN);
 -if (vss_ctx.hEventFrozen == INVALID_HANDLE_VALUE) {
 +if (!vss_ctx.hEventFrozen) {
 err_set(errset, GetLastError(), failed to create event %s,
 EVENT_NAME_FROZEN);
 goto out;
 }
 vss_ctx.hEventThaw = CreateEvent(sa, TRUE, FALSE, EVENT_NAME_THAW);
 -if (vss_ctx.hEventThaw == INVALID_HANDLE_VALUE) {
 +if (!vss_ctx.hEventThaw) {
 err_set(errset, GetLastError(), failed to create event %s,
 EVENT_NAME_THAW);
 goto out;
 }
 vss_ctx.hEventTimeout = CreateEvent(sa, TRUE, FALSE, EVENT_NAME_TIMEOUT);
 -if (vss_ctx.hEventTimeout == INVALID_HANDLE_VALUE) {
 +if (!vss_ctx.hEventTimeout) {
 err_set(errset, GetLastError(), failed to create event %s,
 EVENT_NAME_TIMEOUT);
 goto out;
 @@ -443,7 +439,7 @@ void requester_thaw(int *num_vols, ErrorSet *errset)
 {
 COMPointerIVssAsync pAsync;
 
 -if (vss_ctx.hEventThaw == INVALID_HANDLE_VALUE) {
 +if (!vss_ctx.hEventThaw) {
 /*
  * In this case, DoSnapshotSet is aborted or not started,
  * and no volumes must be frozen. We return without an error.
 
 

Reviewed-by: Yan Vugenfirer yvuge...@redhat.com

Re: [Qemu-devel] [PATCH] Docs: Introduce multiport serial support in qemupciserial.inf

[Yan Vugenfirer]

On Jan 7, 2014, at 4:45 PM, Paolo Bonzini pbonz...@redhat.com wrote:

 Il 05/01/2014 16:04, Miki Mishael ha scritto:
 Support for pci-serial-2x and pci-serial-4x added to inf file.
 Standard Windows driver mf.sys used to split single function
 device into per-port nodes.
 
 Signed-off-by: Miki Mishael mmish...@redhat.com
 Signed-off-by: Dmitry Fleytman dfley...@redhat.com
 ---
 docs/qemupciserial.inf | 227 
 ++---
 1 file changed, 140 insertions(+), 87 deletions(-)
 
 diff --git a/docs/qemupciserial.inf b/docs/qemupciserial.inf
 index 3474310..c6988b9 100644
 --- a/docs/qemupciserial.inf
 +++ b/docs/qemupciserial.inf
 @@ -11,99 +11,152 @@
 ; (Com+Lpt) from the list.  Click Have a disk.  Select this file.
 ; Procedure may vary a bit depending on the windows version.
 
 -; FIXME: This file covers the single port version only.
 +; This file covers all options: pci-serial, pci-serial-2x, pci-serial-4x
 +; for both 32 and 64 bit platforms.
 
 [Version]
 -Signature=$CHICAGO$
 -Class=Ports
 -ClassGuid={4D36E978-E325-11CE-BFC1-08002BE10318}
 +Signature=$Windows NT$
 +Class=MultiFunction
 +ClassGUID={4d36e971-e325-11ce-bfc1-08002be10318}
 Provider=%QEMU%
 -DriverVer=09/24/2012,1.3.0
 -
 -[SourceDisksNames]
 -3426=windows cd
 -
 -[SourceDisksFiles]
 -serial.sys  = 3426
 -serenum.sys = 3426
 -
 -[DestinationDirs]
 -DefaultDestDir  = 11;LDID_SYS
 -ComPort.NT.Copy = 12;DIRID_DRIVERS
 -SerialEnumerator.NT.Copy=12 ;DIRID_DRIVERS
 -
 -; Drivers
 -;--
 +DriverVer=12/29/2013,1.3.0
 +[ControlFlags]
 +ExcludeFromSelect=*
 [Manufacturer]
 -%QEMU%=QEMU,NTx86
 +%QEMU%=QEMU,NTx86,NTAMD64
 
 [QEMU.NTx86]
 -%QEMU-PCI_SERIAL.DeviceDesc% = ComPort, PCI\VEN_1b36DEV_0002CC_0700
 +%QEMU-PCI_SERIAL_1_PORT%=ComPort_inst1, 
 PCI\VEN_1B36DEV_0002SUBSYS_11001AF4REV_01
 +%QEMU-PCI_SERIAL_2_PORT%=ComPort_inst2, 
 PCI\VEN_1B36DEV_0003SUBSYS_11001AF4REV_01
 +%QEMU-PCI_SERIAL_4_PORT%=ComPort_inst4, 
 PCI\VEN_1B36DEV_0004SUBSYS_11001AF4REV_01
 
 I think checking the subsystem is not necessary (and I think downstreams
 could legitimately change it).  Can you check CC and REV but not SUBSYS?

PNP ID can be reduced to vendor and device ID only, for example: 
PCI\VEN_1B36DEV_0002 . But in this case we cannot check revision.

Yan.

 
 Otherwise I cannot pretend I know what's going on, but it makes sense. :)
 
 Paolo

Re: [Qemu-devel] virtio-net: network stops responding in Win2k3 server

[Yan Vugenfirer]

Hi Mario,

Can you check the offload settings of the tap device that is connected to guest?

Run “ethtool -k tap-solaripub”.

On the guest. Raise the log verbosity by going to device manager - NetKVM 
device - Advanced tab - Logging.Level and changing it to 4. Use DebugView to 
record the driver tracing (enable kernel trace): 
http://technet.microsoft.com/en-us/sysinternals/bb896647.aspx


Best regards,
Yan.


On Nov 22, 2013, at 7:28 PM, Mario De Chenno c...@dechenno.eu wrote:

 Hi all.
 We are facing some network issues on some Windows Server 2003 machines.
 In short, network seems to lock up and stops responding even to ping 
 requests. From TCPdump on the tap interface on the server I only see arp 
 request to the gateway, without replies. Increased tx overruns on the some 
 interface too. No errors at all on windows side. Most of the time we can 
 disable the interface from within windows and re-enable it to make things 
 work again. Rarely we have to shut down the virtual machine (Windows reboot 
 does not solve the problem).
 The issue appears randomly without apparent relation with server activity. 
 One server makes a lot of small outbond connections and locks up about every 
 12-24 hours. It has two nic defined and only one is affected (the heaviest 
 loaded). Other servers have just one nic and lock less often.
 We run Qemu-kvm 1.4.0 and latest virtio-win drivers. On the same host we did 
 run a Linux web server with no issue in months of activity, with traffic 
 peaks up to 80Mb/s.
 
 Here's is the startup command:
 
 qemu-system-x86_64 -enable-kvm -machine type=pc,accel=kvm -cpu kvm64 -pidfile 
 /vmstore/vm_pids/solari.pid -rtc base=localtime -drive 
 file=/vmstore/vm_disks/solari.img,if=virtio -netdev 
 tap,id=nic01,ifname=tap-solaripub,script=pub102-ifup -device 
 virtio-net-pci,netdev=nic01,mac=CE:DA:01:00:17:16 -netdev 
 tap,id=nic02,ifname=tap-solariconsip,script=consip-ifup -device 
 virtio-net-pci,netdev=nic02,mac=CE:DA:01:00:16:16 -vnc :16 -m 4096 -boot c -k 
 it -usbdevice tablet -name solari -daemonize
 
 We tried also the following options without result
 ,vhost=off,vnet_hdr=on
 ,ioeventfd=on,event_idx=off
 
 
 How can we troubleshoot the issue?
 Thanks
 

Re: [Qemu-devel] Ping [PATCH] qemu-ga: vss-win32: Install VSS provider COM+ application service

[Yan Vugenfirer]

On Nov 15, 2013, at 7:39 PM, Tomoki Sekiyama tomoki.sekiy...@hds.com wrote:

 On 11/3/13 3:59 , Gal Hammer gham...@redhat.com wrote:
 Reviewed-by: Gal Hammer gham...@redhat.com
 
 On 01/11/2013 23:47, Tomoki Sekiyama wrote:
 Currently, qemu-ga for Windows fails to execute guset-fsfreeze-freeze
 when
 no user is logging in to Windows, with an error message:
   {error:{class:GenericError,
 desc:failed to add C:\\ to snapshotset:  (error:
 8004230f)}}
 
 To enable guest-fsfreeze-freeze/thaw without logging in users, this
 installs
 a service to execute qemu-ga VSS provider COM+ application that has full
 access privileges to the local system. The service will automatically be
 removed when the COM+ application is deregistered.
 
 This patch replaces ICOMAdminCatalog interface with ICOMAdminCatalog2
 interface that contains CreateServiceForApplication() method in
 addition.
 
 Signed-off-by: Tomoki Sekiyama tomoki.sekiy...@hds.com
 ---
  qga/vss-win32/install.cpp |   16 ++--
  1 file changed, 10 insertions(+), 6 deletions(-)
 
 diff --git a/qga/vss-win32/install.cpp b/qga/vss-win32/install.cpp
 index 37731a7..b791a6c 100644
 --- a/qga/vss-win32/install.cpp
 +++ b/qga/vss-win32/install.cpp
 @@ -25,8 +25,8 @@ extern HINSTANCE g_hinstDll;
 
  const GUID CLSID_COMAdminCatalog = { 0xF618C514, 0xDFB8, 0x11d1,
  {0xA2, 0xCF, 0x00, 0x80, 0x5F, 0xC7, 0x92, 0x35} };
 -const GUID IID_ICOMAdminCatalog = { 0xDD662187, 0xDFC2, 0x11d1,
 -{0xA2, 0xCF, 0x00, 0x80, 0x5F, 0xC7, 0x92, 0x35} };
 +const GUID IID_ICOMAdminCatalog2 = { 0x790C6E0B, 0x9194, 0x4cc9,
 +{0x94, 0x26, 0xA4, 0x8A, 0x63, 0x18, 0x56, 0x96} };
  const GUID CLSID_WbemLocator = { 0x4590f811, 0x1d3a, 0x11d0,
  {0x89, 0x1f, 0x00, 0xaa, 0x00, 0x4b, 0x2e, 0x24} };
  const GUID IID_IWbemLocator = { 0xdc12a687, 0x737f, 0x11cf,
 @@ -141,7 +141,7 @@ static HRESULT QGAProviderFind(
  HRESULT hr;
  COMInitializer initializer;
  COMPointerIUnknown pUnknown;
 -COMPointerICOMAdminCatalog pCatalog;
 +COMPointerICOMAdminCatalog2 pCatalog;
  COMPointerICatalogCollection pColl;
  COMPointerICatalogObject pObj;
  _variant_t var;
 @@ -149,7 +149,7 @@ static HRESULT QGAProviderFind(
 
  chk(CoCreateInstance(CLSID_COMAdminCatalog, NULL,
 CLSCTX_INPROC_SERVER,
   IID_IUnknown, (void **)pUnknown.replace()));
 -chk(pUnknown-QueryInterface(IID_ICOMAdminCatalog,
 +chk(pUnknown-QueryInterface(IID_ICOMAdminCatalog2,
   (void **)pCatalog.replace()));
  chk(pCatalog-GetCollection(_bstr_t(LApplications),
  (IDispatch **)pColl.replace()));
 @@ -206,7 +206,7 @@ STDAPI COMRegister(void)
  HRESULT hr;
  COMInitializer initializer;
  COMPointerIUnknown pUnknown;
 -COMPointerICOMAdminCatalog pCatalog;
 +COMPointerICOMAdminCatalog2 pCatalog;
  COMPointerICatalogCollection pApps, pRoles, pUsersInRole;
  COMPointerICatalogObject pObj;
  long n;
 @@ -229,7 +229,7 @@ STDAPI COMRegister(void)
 
  chk(CoCreateInstance(CLSID_COMAdminCatalog, NULL,
 CLSCTX_INPROC_SERVER,
   IID_IUnknown, (void **)pUnknown.replace()));
 -chk(pUnknown-QueryInterface(IID_ICOMAdminCatalog,
 +chk(pUnknown-QueryInterface(IID_ICOMAdminCatalog2,
   (void **)pCatalog.replace()));
 
  /* Install COM+ Component */
 @@ -273,6 +273,10 @@ STDAPI COMRegister(void)
  goto out;
  }
 
 +chk(pCatalog-CreateServiceForApplication(
 +_bstr_t(QGA_PROVIDER_LNAME), _bstr_t(QGA_PROVIDER_LNAME),
 +_bstr_t(LSERVICE_AUTO_START),
 _bstr_t(LSERVICE_ERROR_NORMAL),
 +_bstr_t(L), _bstr_t(L.\\localsystem), _bstr_t(L),
 FALSE));
  chk(pCatalog-InstallComponent(_bstr_t(QGA_PROVIDER_LNAME),
 _bstr_t(dllPath), _bstr_t(tlbPath),
 _bstr_t()));
 
 
 Ping?

Reviewed and tested. Please apply.

Best regards,
Yan Vugenfirer.

 -- 
 Tomoki Sekiyama
 
 

[Qemu-devel] [PATCH] qemu-qa: fix build with mingw

[Yan Vugenfirer]

Fixing broken stand alone build of qemu-ga using mingw.
The problem was introduced by commit e8ef31a35.

Signed-off-by: Yan Vugenfirer y...@daynix.com
---
 configure | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configure b/configure
index 0a55c20..20becfa 100755
--- a/configure
+++ b/configure
@@ -3477,7 +3477,7 @@ if test $softmmu = yes ; then
   fi
 fi
 if [ $guest_agent != no ]; then
-  if [ $linux = yes -o $bsd = yes -o $solaris = yes ] ; then
+  if [ $linux = yes -o $bsd = yes -o $solaris = yes -o $mingw32 
= yes ] ; then
   tools=qemu-ga\$(EXESUF) $tools
   guest_agent=yes
   elif [ $guest_agent != yes ]; then
-- 
1.8.3.1

Re: [Qemu-devel] KVM VM(windows xp) reseted when running geekbench for about 2 days

[Yan Vugenfirer]

On Apr 18, 2013, at 3:55 PM, Gleb Natapov wrote:

 On Thu, Apr 18, 2013 at 12:00:49PM +, Zhanghaoyu (A) wrote:
 I start 10 VMs(windows xp), then running geekbench tool on them, about 2 
 days, one of them was reset,
 I found the reset operation is done by
 int kvm_cpu_exec(CPUArchState *env)
 {
...
   switch (run-exit_reason)
   ...
case KVM_EXIT_SHUTDOWN:
DPRINTF(shutdown\n);
qemu_system_reset_request();
ret = EXCP_INTERRUPT;
break;
...
 }
 
 KVM_EXIT_SHUTDOWN exit reason was set previously in triple fault handle 
 handle_triple_fault().
 
 How do you know that reset was done here? This is not the only place
 where qemu_system_reset_request() is called.

Make sure XP is not set to auto-reset in case of BSOD. 

Best regards,
Yan.

 
 What causes the triple fault?
 
 Are you asking what is triple fault or why it happened in your case?
 For the former see here: http://en.wikipedia.org/wiki/Triple_fault
 For the later it is to late to tell after VM reset. You can run QEMU with
 -no-reboot -no-shutdown. VM will pause instead of rebooting and then you
 can examine what is going on.
 
 --
   Gleb.
 --
 To unsubscribe from this list: send the line unsubscribe kvm in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Qemu-devel] Virtualbox svga card in KVM

[Yan Vugenfirer]

On Apr 6, 2013, at 2:52 AM, Sriram Murthy wrote:

 For starters, virtual box has better SVGA WDDM drivers that allows for a much 
 richer display when the VM display is local.
Does it support S3 and S4 with Windows 8?

Yan.

 I am yet to completely understand both the KVM and the virtualbox SVGA card 
 (actually, the virtualbox SVGA card is based off of the KVM VGA card), so I 
 may not be the authority here.
 -Sriram
 
 
 
 - Original Message -
 From: Stefan Hajnoczi stefa...@gmail.com
 To: Sriram Murthy srira...@yahoo.com
 Cc: k...@vger.kernel.org; qemu list qemu-devel@nongnu.org
 Sent: Friday, April 5, 2013 12:06 AM
 Subject: Re: Virtualbox svga card in KVM
 
 On Thu, Mar 21, 2013 at 10:53:21AM -0400, Alon Levy wrote:
  I am planning on bringing in the virtualbox svga card into kvm
  as a new svga card type (vbox probably?) so that we can load
  the VirtualBox SVGA card drivers in the guest.
 
 I'm curious if the vbox SVGA card has features that existing QEMU
 graphics cards do not provide?
 
 Stefan
 
 --
 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] [Bug 1119281] [NEW] The virtio network device breaks UuidCreateSequential()

[Yan Vugenfirer]

On Mon, Feb 11, 2013 at 11:13 AM, Stefan Hajnoczi stefa...@gmail.comwrote:

 On Fri, Feb 08, 2013 at 10:45:03AM -, Francois Gouget wrote:
  Public bug reported:
 
  UuidCreateSequential() usually creates version 1 UUIDs (1) which means
  they contain the main network card's MAC address. However when using a
  virtio network card and driver the UUIDs contain random data instead of
  the guest's MAC address. Changing the network card to either the default
  rtl8139 one or the e1000 one fixes the issue.

 CCing Yan and Vadim, who work on the virtio-win drivers.

 
  Here is the software I have tested this with:
   * qemu 1.1.2+dfsg-5 and 1.4.0~rc0+dfsg-1exp (from Debian Testing and
 Experimental respectively)
   * The 0.1-49 and 0.1-52 Windows virtio drivers from
 https://alt.fedoraproject.org/pub/alt/virtio-win/latest/images/bin/
   * Both a 32-bit Windows XP guest and a 64-bit Windows 7 one.
 
 
  Here is how to test for this issue:
  * Set up a Windows guest with a single network card(2), a virtio one and
 install the corresponding driver.
 
  * Boot the guest and copy the uuidtest.exe file (see attachement) to it
 
  * On the command line, type 'ipconfig /all'. Give you the correct
  network card's MAC address on a line like the one below:
 
  Physical Address. . . . . . . . . : 52-54-00-C7-0E-97
 
  * Run uuidtest.exe. It will show the VM returning a UUID with the wrong
  MAC address, and quite possibly even a multicast MAC address! (3). In
  the example below 'f75292c62787' should have been the MAC address. Note
  that on Windows XP UuidCreateSequential() returns RPC_S_UUID_LOCAL_ONLY
  for virtio cards but that on Windows 7 it returns 0.
 
  UuidCreateSequential() returned 0
  uuid={56e1ffe4-71d8-11e2-b1cc-f75292c62787}
  Got a version 1 UUID
  The UUID does not contain a non-multicast MAC address
 
  * Reboot and notice uuidtest.exe now reports a different value where the
  MAC address should be.
 
  * Shut down the VM and switch the network card to rtl8139, install the
  drivers, run uuidtest.exe and notice that the last group of digits
  finally contains the correct MAC address.
 
 
  (1) https://en.wikipedia.org/wiki/Globally_unique_identifier#Algorithm
  (2) Best do it with a single card to avoid confusion over which is the
 primary one.
  (3) If the first byte of the address is odd then this is a multicast
 address.
  https://en.wikipedia.org/wiki/MAC_address#Address_details
 
  ** Affects: qemu
   Importance: Undecided
   Status: New
 
  ** Attachment added: Test executable and source
 
 https://bugs.launchpad.net/bugs/1119281/+attachment/3520477/+files/uuidtest.tar.bz2



I did a quick check for this issue. First off all
while UuidCreateSequential should use mac address, there is no indication
that it must do it. And as we don't have source code for Rpcrt4.lib it is
hard to estimated what should be the exact behavior of this function (I can
use reactos source code - but we cannot count on it).
What I see from our debug trace that there are no OID calls to NIC while
using this function to get our current or permanent MAC address. And we
know that those OIDs work well: a. because you see correct MAC using
ipconfig of getmac (also is verified by Red Hat QE during manual functional
tests). b. We pass WHQL tests that set valid and invalid mac addresses
automatically and tests for correct behavior. So UuidCreateSequential
either takes this value from somewhere in registry or generates it by some
other mean.

I can try and assume how it should work using ReactOS code.
From reactos UuidCreateSequential:
http://doxygen.reactos.org/df/def/rpcdce_8h_a884acec185f2f0a999a8375cd04f61c9.html
It will use GetAdaptersInfo. I ran the code in the MS documentation
http://msdn.microsoft.com/en-us/library/windows/desktop/aa365917(v=vs.85).aspx-
and once again the mac address of virtio adapter is correct.


Might be related:
http://support.microsoft.com/kb/981080?wa=wsignin1.0
http://support.microsoft.com/kb/2569646


Best regards,
Yan.

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

[Yan Vugenfirer]

On Feb 7, 2013, at 1:46 PM, Vadim Rozenfeld wrote:

 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 vroze...@redhat.com 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_1AF4DEV_1000SUBSYS_00011AF4
 NetKVM/wxp/netkvm.inf:%kvmnet5.DeviceDesc%= kvmnet5.ndi, 
 PCI\VEN_1AF4DEV_1000SUBSYS_00011AF4
 NetKVM/wxp/netkvm2k.inf:%kvmnet5.DeviceDesc%= kvmnet5.ndi, 
 PCI\VEN_1AF4DEV_1000SUBSYS_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;
}
 

We can add it from next release. Provided that everyone understand the 
consequences especially for boot devices (virtio-block and virtio-scsi).


 
 
 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

[Yan Vugenfirer]

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 m...@tls.msk.ru 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.

 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

[Yan Vugenfirer]

On Feb 3, 2013, at 1:07 AM, Anthony Liguori wrote:

 Vadim Rozenfeld vroze...@redhat.com writes:
 
 On Sat, 2013-02-02 at 20:42 +0800, Jason Wang wrote:
 
 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.
 
 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.
 
 Regards,
 
 Anthony Liguori

That's exactly the problem.

Best regards,
Yan.


 
 Thank you,
 Vadim.
 
 Regards,
 
 Anthony Liguori
 
 commit fed699f9ca6ae8a0fb62803334cf46fa64d1eb91
 Author: Jason Wang jasow...@redhat.com
 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 jasow...@redhat.com
  Signed-off-by: Anthony Liguori aligu...@us.ibm.com
 
 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 v8] kvm: notify host when the guest is panicked

[Yan Vugenfirer]

On Aug 14, 2012, at 10:35 PM, Anthony Liguori wrote:

 Marcelo Tosatti mtosa...@redhat.com writes:
 
 On Tue, Aug 14, 2012 at 01:53:01PM -0500, Anthony Liguori wrote:
 Marcelo Tosatti mtosa...@redhat.com writes:
 
 On Tue, Aug 14, 2012 at 05:55:54PM +0300, Yan Vugenfirer wrote:
 
 On Aug 14, 2012, at 1:42 PM, Jan Kiszka wrote:
 
 On 2012-08-14 10:56, Daniel P. Berrange wrote:
 On Mon, Aug 13, 2012 at 03:21:32PM -0300, Marcelo Tosatti wrote:
 On Wed, Aug 08, 2012 at 10:43:01AM +0800, Wen Congyang wrote:
 We can know the guest is panicked when the guest runs on xen.
 But we do not have such feature on kvm.
 
 Another purpose of this feature is: management app(for example:
 libvirt) can do auto dump when the guest is panicked. If management
 app does not do auto dump, the guest's user can do dump by hand if
 he sees the guest is panicked.
 
 We have three solutions to implement this feature:
 1. use vmcall
 2. use I/O port
 3. use virtio-serial.
 
 We have decided to avoid touching hypervisor. The reason why I choose
 choose the I/O port is:
 1. it is easier to implememt
 2. it does not depend any virtual device
 3. it can work when starting the kernel
 
 How about searching for the Kernel panic - not syncing string 
 in the guests serial output? Say libvirtd could take an action upon
 that?
 
 No, this is not satisfactory. It depends on the guest OS being
 configured to use the serial port for console output which we
 cannot mandate, since it may well be required for other purposes.
 
 Please don't forget Windows guests, there is no console and no Kernel 
 Panic string ;)
 
 What I used for debugging purposes on Windows guest is to register a 
 bugcheck callback in virtio-net driver and write 1 to VIRTIO_PCI_ISR 
 register.
 
 Yan. 
 
 Considering whether a panic-device should cover other OSes is also \
 
 something to consider. Even for Linux, is panic the only case which
 should be reported via the mechanism? What about oopses without panic? 
 
 Is the mechanism general enough for supporting new events, etc.
 
 Hi,
 
 I think this discussion is gone of the deep end.
 
 Forget about !x86 platforms.  They have their own way to do this sort of
 thing.  
 
 The panic function in kernel/panic.c has the following options, which
 appear to be arch independent, on panic:
 
 - reboot 
 - blink
 
 Not sure the semantics of blink but that might be a good place for a
 pvops hook.
 
 
 None are paravirtual interfaces however.
 
 Think of this feature like a status LED on a motherboard.  These
 are very common and usually controlled by IO ports.
 
 We're simply reserving a status LED for the guest to indicate that it
 has paniced.  Let's not over engineer this.
 
 My concern is that you end up with state that is dependant on x86.
 
 Subject: [PATCH v8 3/6] add a new runstate: RUN_STATE_GUEST_PANICKED
 
 Having the ability to stop/restart the guest (and even introducing a 
 new VM runstate) is more than a status LED analogy.
 
 I must admit, I don't know why a new runstate is necessary/useful.  The
 kernel shouldn't have to care about the difference between a halted guest
 and a panicked guest.  That level of information belongs in userspace IMHO.
 
 Can this new infrastructure be used by other architectures?
 
 I guess I don't understand why the kernel side of this isn't anything
 more than a paravirt op hook that does a single outb() with the
 remaining logic handled 100% in QEMU.
 
 Do you consider allowing support for Windows as overengineering?
 
 I don't think there is a way to hook BSOD on Windows so attempting to
 engineer something that works with Windows seems odd, no?
 

Actually there is a way 
(http://msdn.microsoft.com/en-us/library/windows/hardware/ff553105(v=vs.85).aspx).
 That's what I just mentioned already done in Windows virtio-net driver. 


Best regards,
Yan.

 Regards,
 
 Anthony Liguori
 
 
 Regards,
 
 Anthony Liguori
 
 
 
 Well, we have more than a single serial port, even when leaving
 virtio-serial aside...
 
 Jan
 
 -- 
 Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
 Corporate Competence Center Embedded Linux
 --
 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
 --
 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] [PATCH v8] kvm: notify host when the guest is panicked

[Yan Vugenfirer]

On Aug 15, 2012, at 12:56 PM, Gleb Natapov wrote:

 On Tue, Aug 14, 2012 at 02:35:34PM -0500, Anthony Liguori wrote:
 Do you consider allowing support for Windows as overengineering?
 
 I don't think there is a way to hook BSOD on Windows so attempting to
 engineer something that works with Windows seems odd, no?
 
 Yan says in other email that is is possible to register a bugcheck callback.
 

Here you go - 
http://msdn.microsoft.com/en-us/library/windows/hardware/ff553105(v=vs.85).aspx
Already done in virtio-net for two reasons: 1. we could configure virtio-net to 
notify QEMU in a hacky way (write 1 to VIRTIO_PCI_ISR register) that there was 
a bugckeck .It was very useful debugging complex WHQL issues that involved host 
networking. 2. Store additional information (for example time stamps of last 
receive packet, last interrupt and etc) in crash dump.

Yan.

 --
   Gleb.
 --
 To unsubscribe from this list: send the line unsubscribe kvm in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Qemu-devel] [PATCH v8] kvm: notify host when the guest is panicked

[Yan Vugenfirer]

On Aug 14, 2012, at 1:42 PM, Jan Kiszka wrote:

 On 2012-08-14 10:56, Daniel P. Berrange wrote:
 On Mon, Aug 13, 2012 at 03:21:32PM -0300, Marcelo Tosatti wrote:
 On Wed, Aug 08, 2012 at 10:43:01AM +0800, Wen Congyang wrote:
 We can know the guest is panicked when the guest runs on xen.
 But we do not have such feature on kvm.
 
 Another purpose of this feature is: management app(for example:
 libvirt) can do auto dump when the guest is panicked. If management
 app does not do auto dump, the guest's user can do dump by hand if
 he sees the guest is panicked.
 
 We have three solutions to implement this feature:
 1. use vmcall
 2. use I/O port
 3. use virtio-serial.
 
 We have decided to avoid touching hypervisor. The reason why I choose
 choose the I/O port is:
 1. it is easier to implememt
 2. it does not depend any virtual device
 3. it can work when starting the kernel
 
 How about searching for the Kernel panic - not syncing string 
 in the guests serial output? Say libvirtd could take an action upon
 that?
 
 No, this is not satisfactory. It depends on the guest OS being
 configured to use the serial port for console output which we
 cannot mandate, since it may well be required for other purposes.
 
Please don't forget Windows guests, there is no console and no Kernel Panic 
string ;)

What I used for debugging purposes on Windows guest is to register a bugcheck 
callback in virtio-net driver and write 1 to VIRTIO_PCI_ISR register.

Yan. 


 Well, we have more than a single serial port, even when leaving
 virtio-serial aside...
 
 Jan
 
 -- 
 Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
 Corporate Competence Center Embedded Linux
 --
 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] [Bug 990364] [NEW] virtio_ioport_write: unexpected address 0x13 value 0x1

[Yan Vugenfirer]

You had a BSOD on a guest.

NetKVM driver will write 1 to VIRTIO_PCI_ISR register in case of BSOD (we had 
BSOD callback in the driver). The callback will be called on any BSOD, so it 
doens't mean that the BSOD was due to virtio-net.

Check the guest and check if there is memory dump available.

Best regards,
Yan.


On May 3, 2012, at 3:16 PM, Vadim Rozenfeld wrote:

 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 wor...@gmail.com 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] [PATCH 7/7 v5] VMXNET3 paravirtualized device implementation Interface type vmxnet3 added.

[Yan Vugenfirer]

On Wed, Apr 11, 2012 at 10:10 PM, Anthony Liguori anth...@codemonkey.ws wrote:
 On 04/11/2012 02:08 PM, Paolo Bonzini wrote:

 Il 11/04/2012 19:25, Anthony Liguori ha scritto:


 Off the top of my head: issues with v5:
 polluting global namespace, must scope names
 appropriately with vmxnet_ VMXNET_ unless they have file scope.
 Don't use names with _ followed by an upper case letter
 or that star with two underscores. Don't mix underscores and mixed case.
 Don't stick any new types in net.c/pci.c - new devices should use
 -device
 not -net. Global stuff like ethernet header size
 should move to central place instead of copy paste.


 I'd like to see qtest test cases for this too.


 I think as things stand it is a bit too much to request this.  You're
 basically asking to write a libos.


 The only functionality you need is PCI device enumeration which is pretty
 much dead simple.

 What other functions would you need a libos for?

 Regards,

 Anthony Liguori


 Paolo




Regarding the testing - we ran WHQL networking tests on the device. If
we provide the logs will it be sufficient? I believe the test coverage
is much more comprehensive than anything that we will do with qtest.

Best regards,
Yan.

Re: [Qemu-devel] [PATCH 7/7 v5] VMXNET3 paravirtualized device implementation Interface type vmxnet3 added.

[Yan Vugenfirer]

On Tue, Apr 10, 2012 at 6:47 PM, Stefan Hajnoczi stefa...@gmail.com wrote:

 On Wed, Apr 4, 2012 at 12:44 PM, Izik Eidus
 izik.ei...@ravellosystems.com wrote:
  What about this patch?, everything that was asked from Dmitry was
  accomplished...
  What prevent us from progressing with merging this patch?

 Hang on, I asked what the point of the VMware paravirt device models
 is.  I don't think that was ever answered fully.

 I know it makes migration of existing VMware guests easy, but now we
 have the burden of maintaining these device models, whose feature set
 and performance will never be equivalent to virtio.  The reason is
 because we cannot extend the device spec without breaking guests (we
 don't control the device specification and therefore cannot add new
 features) and we now have twice as much performance optimization work
 if we want the same level of performance as virtio devices.

 For these reasons, I think that VMware device models can only ever be
 2nd class device models in QEMU.  And I wonder if the effort isn't
 better invested in good v2v migration tooling instead of adding this
 to QEMU.

 I'm not strongly against VMware device models in QEMU, I do see the
 benefit too, but please explain what the plan here is.

 Stefan

In my opinion there is a great opportunity to create painless
migration method from VMWare to QEMU\KVM. You just copy image and run,
no image conversions and no issues with V2V which are painful to debug
to regular person. After VM is already running on top of QEMU -
changing the devices is much easier.
Considering that VMWare rule the world more or less - enabling more
people to switch easily or at least to get a taste of QEMU\KVM is a
huge advantage.

Regarding optimization - adding vhost support to VMXNET3 doesn't look
like a huge effort anyway and if you look at the patch you will see
that we are using virtio-net mechanisms in VMXNET3 device (for example
using virtio headers for offloading).

Best regards,
Yan Vugenfirer.

Re: [Qemu-devel] [PATCH 7/7 v5] VMXNET3 paravirtualized device implementation Interface type vmxnet3 added.

[Yan Vugenfirer]

On Thu, Apr 5, 2012 at 8:25 AM, Gerhard Wiesinger li...@wiesinger.com wrote:

 On Wed, 4 Apr 2012, Izik Eidus wrote:

 What about this patch?, everything that was asked from Dmitry was 
 accomplished...
 What prevent us from progressing with merging this patch?


 As already discussed on the list patch v5 doesn't work at least for me. 
 Previous patches worked better but were not stable under load.

 I'm also appreciating a working version and integrating the patch fast.

 Ciao,
 Gerhard

 --
 http://www.wiesinger.com/

Hello Gerhard,

1. I understand that you send your exact command line to Dmitry and
your test scripts, but we cannot reproduce the issues. Can you send us
host network configuration?

2. Is it possible for you to run tcpdump on the guest and on the host
and send us the files for review?

Best regards,
Yan.

Re: [Qemu-devel] Windows Virtio Issue

[Yan Vugenfirer]

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] [PATCH] VMXNET3 paravirtual NIC device implementation

[Yan Vugenfirer]

Adding Izik from Ravello.

Best regards,
Yan.

On Tue, Feb 28, 2012 at 6:43 PM, malc av1...@comtv.ru wrote:
 On Tue, 28 Feb 2012, Yan Vugenfirer wrote:

 From: Dmitry Fleytman dmi...@daynix.com

 Implementation of VMWare VMXNET3 paravirtual NIC device.
 Supports of all the device features including offload capabilties,
 VLANs and etc.
 The device is tested on different OSes:
 [..snip..]

 @@ -0,0 +1,146 @@
 +/*
 + * QEMU VMWARE paravirtual devices - auxiliary code
 + *
 + * Copyright (c) 2012 Ravello Systems LTD (http://ravellosystems.com)
 + * All Rights Reserved

 Not quite sure, i'm follwing this, here it says that all rights are
 reserved.

 + *
 + * Developed by Daynix Computing LTD (http://www.daynix.com)
 + *
 + * Authors:
 + * Dmitry Fleytman dmi...@daynix.com
 + * Yan Vugenfirer y...@daynix.com
 + *
 + * This program is free software; you can redistribute it and/or modify it
 + * under the terms of the GNU General Public License as published by the
 + * Free Software Foundation; version 2 of the License and no later version.
 + *
 + * This program is distributed in the hope that it will be useful, but
 + * WITHOUT ANY WARRANTY; without even the implied warranty of
 + * MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE, GOOD TITLE or
 + * NON INFRINGEMENT.  See the GNU General Public License for more
 + * details.
 + *
 + * You should have received a copy of the GNU General Public License
 + * along with this program; if not, write to the Free Software
 + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
 + *
 + * The full GNU General Public License is included in this distribution in
 + * the file called COPYING.
 + *
 + */

 And here that most of them are really not.

 Not a lawyer though.

 [..snip..]

 --
 mailto:av1...@comtv.ru