Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 1556868

Summary: Make sure all drivers have WPP integrated and enabled
Product: Red Hat Enterprise Linux 7 Reporter: Sameeh Jubran <sjubran>
Component: virtio-winAssignee: Amnon Ilan <ailan>
virtio-win sub component: virtio-win-prewhql QA Contact: Virtualization Bugs <virt-bugs>
Status: CLOSED ERRATA Docs Contact:
Severity: medium    
Priority: medium CC: jherrman, lijin, michen, mtessun, phou, sjubran, virt-bugs, vrozenfe, wyu, xiagao
Version: 7.6Keywords: FutureFeature
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Enhancement
Doc Text:
The Windows software trace preprocessor (WPP) feature is now supported by the virtio-win drivers. As a result, on virtual machines using Windows 7 and later, it is now possible to use WPP software tracing to log real-time binary messages. For more information about WPP, see https://docs.microsoft.com/en-us/windows-hardware/drivers/devtest/wpp-software-tracing
 Story Points: ---
Clone Of: Environment:
Last Closed: 2018-10-30 16:21:50 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1558125, 1558351    
Attachments:
Description Flags
screenshot-virtioinput none

Description Sameeh Jubran 2018-03-15 11:56:58 UTC 
Description of problem:

Currently only 6 drivers are supporting

balloon
netkvm
pvpanic
vioinput
viorng
vioserial

On most of them WPP is not working by default, I think it should be enabled on release builds as it has minimal if any overhead when it is not being monitored.

And these drivers dont support WPP yet:
viostor and vioscsi

I think they should
Comment 4 Sameeh Jubran 2018-03-25 01:13:20 UTC 
Commits that enabled WPP by deafult for all the drivers that support it have been merged into upstream in the following Pull request:

https://github.com/virtio-win/kvm-guest-drivers-windows/pull/262

This pull request however rearranges documentation along with some minor issues:
  
https://github.com/virtio-win/kvm-guest-drivers-windows/pull/263

However up until now it hasn't been merged, but should be soon.

We need the cooperation of the QA team with testing the WPP feature for all of the drivers that support it along with feedback on the documentation which would be awesome.
Comment 6 Yu Wang 2018-04-18 09:59:09 UTC 
Hi Sameeh Jubran,

I tried balloon,netkvm,pvpanic,vioinput,viorng,vioserial on win8.1 guest.
I can trace some information with these drivers (build150).

But I found that some drivers' name in the log is not correct, it shows "sys" not drivers' name. Is it a bug or not? (screenshot refer to attachment)

driver name     balloon   input    rng      pvpanic   vioser   netkvm
shows in log    sys       sys      viorng   pvpanic   sys      NetKVM

BTW, which tracing level we should set when testing? default level is "Error". Is that OK?


Thanks
Yu Wang
Comment 7 Yu Wang 2018-04-18 09:59:48 UTC 
Created attachment 1423461 [details]
screenshot-virtioinput
Comment 9 Sameeh Jubran 2018-04-26 12:45:15 UTC 
(In reply to Yu Wang from comment #6)
> Hi Sameeh Jubran,
> 
> I tried balloon,netkvm,pvpanic,vioinput,viorng,vioserial on win8.1 guest.
> I can trace some information with these drivers (build150).
> 
> But I found that some drivers' name in the log is not correct, it shows
> "sys" not drivers' name. Is it a bug or not? (screenshot refer to attachment)
> 
> driver name     balloon   input    rng      pvpanic   vioser   netkvm
> shows in log    sys       sys      viorng   pvpanic   sys      NetKVM
> 
> BTW, which tracing level we should set when testing? default level is
> "Error". Is that OK?
> 
> 
> Thanks
> Yu Wang

Yes this is actually  a bug and it is fixed in the following PR:
https://github.com/virtio-win/kvm-guest-drivers-windows/pull/278
Comment 13 lijin 2018-05-29 07:59:32 UTC 
(In reply to Sameeh Jubran from comment #9)
> (In reply to Yu Wang from comment #6)
> > Hi Sameeh Jubran,
> > 
> > I tried balloon,netkvm,pvpanic,vioinput,viorng,vioserial on win8.1 guest.
> > I can trace some information with these drivers (build150).
> > 
> > But I found that some drivers' name in the log is not correct, it shows
> > "sys" not drivers' name. Is it a bug or not? (screenshot refer to attachment)
> > 
> > driver name     balloon   input    rng      pvpanic   vioser   netkvm
> > shows in log    sys       sys      viorng   pvpanic   sys      NetKVM
> > 

> Yes this is actually  a bug and it is fixed in the following PR:
> https://github.com/virtio-win/kvm-guest-drivers-windows/pull/278

Hi Vadim,

Is this commit included in 153 build?

Thanks
Comment 14 Vadim Rozenfeld 2018-05-29 08:26:39 UTC 
(In reply to lijin from comment #13)
> (In reply to Sameeh Jubran from comment #9)
> > (In reply to Yu Wang from comment #6)
> > > Hi Sameeh Jubran,
> > > 
> > > I tried balloon,netkvm,pvpanic,vioinput,viorng,vioserial on win8.1 guest.
> > > I can trace some information with these drivers (build150).
> > > 
> > > But I found that some drivers' name in the log is not correct, it shows
> > > "sys" not drivers' name. Is it a bug or not? (screenshot refer to attachment)
> > > 
> > > driver name     balloon   input    rng      pvpanic   vioser   netkvm
> > > shows in log    sys       sys      viorng   pvpanic   sys      NetKVM
> > > 
> 
> > Yes this is actually  a bug and it is fixed in the following PR:
> > https://github.com/virtio-win/kvm-guest-drivers-windows/pull/278
> 
> Hi Vadim,
> 
> Is this commit included in 153 build?
> 
> Thanks

Not yet. 
It will be included into the next build which should be done in next several days.

Vadim.
Comment 15 Sameeh Jubran 2018-06-19 10:11:10 UTC 
*** Bug 1554090 has been marked as a duplicate of this bug. ***
Comment 16 Ademar Reis 2018-06-21 18:37:18 UTC 
(In reply to Vadim Rozenfeld from comment #14)
> (In reply to lijin from comment #13)
> > (In reply to Sameeh Jubran from comment #9)
> > > (In reply to Yu Wang from comment #6)
> > > > Hi Sameeh Jubran,
> > > > 
> > > > I tried balloon,netkvm,pvpanic,vioinput,viorng,vioserial on win8.1 guest.
> > > > I can trace some information with these drivers (build150).
> > > > 
> > > > But I found that some drivers' name in the log is not correct, it shows
> > > > "sys" not drivers' name. Is it a bug or not? (screenshot refer to attachment)
> > > > 
> > > > driver name     balloon   input    rng      pvpanic   vioser   netkvm
> > > > shows in log    sys       sys      viorng   pvpanic   sys      NetKVM
> > > > 
> > 
> > > Yes this is actually  a bug and it is fixed in the following PR:
> > > https://github.com/virtio-win/kvm-guest-drivers-windows/pull/278
> > 
> > Hi Vadim,
> > 
> > Is this commit included in 153 build?
> > 
> > Thanks
> 
> Not yet. 
> It will be included into the next build which should be done in next several
> days.

What's the current status? We're at the very end of the RHEL-7.6 development phase and might need exception+ for this. Please provide a plan and ETA otherwise we should defer or close it.
Comment 17 Vadim Rozenfeld 2018-06-21 23:48:10 UTC 
(In reply to Ademar Reis from comment #16)
> (In reply to Vadim Rozenfeld from comment #14)
> > (In reply to lijin from comment #13)
> > > (In reply to Sameeh Jubran from comment #9)
> > > > (In reply to Yu Wang from comment #6)
> > > > > Hi Sameeh Jubran,
> > > > > 
> > > > > I tried balloon,netkvm,pvpanic,vioinput,viorng,vioserial on win8.1 guest.
> > > > > I can trace some information with these drivers (build150).
> > > > > 
> > > > > But I found that some drivers' name in the log is not correct, it shows
> > > > > "sys" not drivers' name. Is it a bug or not? (screenshot refer to attachment)
> > > > > 
> > > > > driver name     balloon   input    rng      pvpanic   vioser   netkvm
> > > > > shows in log    sys       sys      viorng   pvpanic   sys      NetKVM
> > > > > 
> > > 
> > > > Yes this is actually  a bug and it is fixed in the following PR:
> > > > https://github.com/virtio-win/kvm-guest-drivers-windows/pull/278
> > > 
> > > Hi Vadim,
> > > 
> > > Is this commit included in 153 build?
> > > 
> > > Thanks
> > 
> > Not yet. 
> > It will be included into the next build which should be done in next several
> > days.
> 
> What's the current status? We're at the very end of the RHEL-7.6 development
> phase and might need exception+ for this. Please provide a plan and ETA
> otherwise we should defer or close it.

WPP for both storage drivers (viostor and vioscsi) is in. Firstly introduced in build 154 and ready for testing.
Comment 18 Yu Wang 2018-06-25 04:05:29 UTC 
Tested on all the drivers (balloon/input/rng/pvpanic/vioser/netkvm/viostor/vioscsi), can trace info by trace view and all the driver names are correct.

But still have a doubt, when setting level to None on TraceView, it can still trace info with netkvm/viostor/vioscsi, is this normal? If yes, I will change status to verified.

Thanks
Yu Wang
Comment 19 Sameeh Jubran 2018-06-25 06:52:37 UTC 
For NetKVM this behavior is okay as the way to turn on and off the NetKVM prints if from the driver advanced tap (registry settings). It is configured this way in order to keep this aligned with the old style debugging function using kdprint.
Comment 20 Yu Wang 2018-06-25 07:05:21 UTC 
Thanks,  Sameeh Jubran. 

Hi Vadim,

Could you help to check comment#18, is this behavior okay?

Thanks
Yu Wang
Comment 21 Vadim Rozenfeld 2018-06-25 11:15:53 UTC 
(In reply to Yu Wang from comment #20)
> Thanks,  Sameeh Jubran. 
> 
> Hi Vadim,
> 
> Could you help to check comment#18, is this behavior okay?
> 
> Thanks
> Yu Wang

Hi Yu Wang,

Level has no meaning for viostor and vioscsi, only flags are important.
Enabling Flag "TRACE_LEVEL_NONE" only should stop logging new trace records, 
but we have to remember that TraceView reads and prints trace information from 
some sort of in-memory ring buffers, which means that we can expect delay (sometimes several minutes long) between toggling a flag and its visible effect
in TraceView.

Best,
Vadim.
Comment 22 Yu Wang 2018-06-26 05:40:00 UTC 
(In reply to Vadim Rozenfeld from comment #21)
> (In reply to Yu Wang from comment #20)
> > Thanks,  Sameeh Jubran. 
> > 
> > Hi Vadim,
> > 
> > Could you help to check comment#18, is this behavior okay?
> > 
> > Thanks
> > Yu Wang
> 
> Hi Yu Wang,
> 
> Level has no meaning for viostor and vioscsi, only flags are important.
> Enabling Flag "TRACE_LEVEL_NONE" only should stop logging new trace records, 
> but we have to remember that TraceView reads and prints trace information
> from 
> some sort of in-memory ring buffers, which means that we can expect delay
> (sometimes several minutes long) between toggling a flag and its visible
> effect
> in TraceView.

Get it, thanks a lot.
according to comment#20 and comment#21, change status to verified

> 
> Best,
> Vadim.
Comment 26 errata-xmlrpc 2018-10-30 16:21:50 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2018:3413