[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20241028160156.71661aa3.olaf@aepfle.de>
Date: Mon, 28 Oct 2024 16:01:56 +0100
From: Olaf Hering <olaf@...fle.de>
To: Saurabh Singh Sengar <ssengar@...ux.microsoft.com>
Cc: linux-hyperv@...r.kernel.org, linux-kernel@...r.kernel.org, "K. Y.
Srinivasan" <kys@...rosoft.com>, Haiyang Zhang <haiyangz@...rosoft.com>,
Wei Liu <wei.liu@...nel.org>, Dexuan Cui <decui@...rosoft.com>
Subject: Re: [PATCH v1] tools/hv: terminate fcopy daemon if read from uio
fails
Mon, 28 Oct 2024 02:06:20 -0700 Saurabh Singh Sengar <ssengar@...ux.microsoft.com>:
> Thanks for the patch. Changes look good to me, I will suggest to improve this
> log message incase the error type is EIO by suggesting that users verify if
> 'Guest Services' is enabled.
No error happens if the state of "Guest services" remains unchanged during
the life time of the VM (either "enabled" or "disabled"). Also no error happens
if "Guest services" changes from "disabled" to "enabled". But the error happens
if "Guest services" changes from "enabled" to "disabled". I think the actual
error "EIO" is not relevant for the commit message. Maybe you mean the second
paragraph should read like this?
This happens if the state of "Guest services" integration service is changed
from "enabled" to "disabled" at runtime in the VM settings.
I'm probably not telling news if I say that this behavior is a regression compared
to the hv_utils based variant of fcopy. In the past one could flip the state of
"Guest services", it would always come back if state changed to "enabled" again,
because the "hv_fcopy" device node came back. With UIO the device node does not
come back AFAICS. Not a big deal to reboot the VM in this case.
Olaf
Content of type "application/pgp-signature" skipped
Powered by blists - more mailing lists