Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

hotplug_virtio_mem: updates unplug error message #4171

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

mcasquer
Copy link
Contributor

@mcasquer mcasquer commented Oct 4, 2024

hotplug_virtio_mem: updates unplug error message

From QEMU 9.1 onwards the error message displayed when the
virtio-mem device is tried to be unplugged while it still has
some memory plugged has been updated. Adding support for
both messages based on the version.

Signed-off-by: mcasquer [email protected]
ID: 128

@mcasquer mcasquer marked this pull request as ready for review October 4, 2024 08:44
@mcasquer
Copy link
Contributor Author

mcasquer commented Oct 4, 2024

Test result posted internally, please @yanan-fu @zhenyzha @YongxueHong @zhencliu could you review this PR? Thanks !

Comment on lines 31 to 32
error_msg = "virtio-mem device cannot get unplugged while 'size' != '0'"
new_error_msg = "virtio-mem device cannot get unplugged while some of its memory is still plugged"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could still use one parameter error_msg to represent different version's error messages by the regex expression: re.search.
For instance:
error_msg = "virtio-mem device cannot get unplugged while ('size' != '0')|(some of its memory is still plugged)"

Hi @mcasquer
How about it? Please let me know your thoughts.
Thanks.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@YongxueHong Updated, thanks !

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @mcasquer and @YongxueHong , I might have some concerns about this part, think about this situation:

qemu 9.1, the error msg somehow doesn't change to the latest one, the test case will still pass, which is not expected, it should fail.

So what about using RHEL version filters(we don't have qemu version filters) to set different error messages for different qemu versions,

error_msg = "virtio-mem device cannot get unplugged while some of its memory is still plugged"
Host_RHEL.m<xx>.u<yy>: >>> RHEL versions supporting the old error msg
    error_msg = "virtio-mem device cannot get unplugged while 'size' != '0'"

What do you think?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @mcasquer and @YongxueHong , I might have some concerns about this part, think about this situation:

qemu 9.1, the error msg somehow doesn't change to the latest one, the test case will still pass, which is not expected, it should fail.

Hi @zhencliu
Could you explain in more detail? I did not get your point.
As my understanding, The error meg should be virtio-mem device cannot get unplugged while some of its memory is still plugged with qemu 9.1 and than we could check if it match the expected regex expression error_msg = "virtio-mem device cannot get unplugged while ('size' != '0')|(some of its memory is still plugged)" by re.search.

So what about using RHEL version filters(we don't have qemu version filters) to set different error messages for different qemu versions,

error_msg = "virtio-mem device cannot get unplugged while some of its memory is still plugged"
Host_RHEL.m<xx>.u<yy>: >>> RHEL versions supporting the old error msg
    error_msg = "virtio-mem device cannot get unplugged while 'size' != '0'"

What do you think?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @mcasquer and @YongxueHong , I might have some concerns about this part, think about this situation:

qemu 9.1, the error msg somehow doesn't change to the latest one, the test case will still pass, which is not expected, it should fail.

So what about using RHEL version filters(we don't have qemu version filters) to set different error messages for different qemu versions,

error_msg = "virtio-mem device cannot get unplugged while some of its memory is still plugged"
Host_RHEL.m<xx>.u<yy>: >>> RHEL versions supporting the old error msg
    error_msg = "virtio-mem device cannot get unplugged while 'size' != '0'"

What do you think?

@zhencliu we can do the QEMU version filter in the python script (as I implemented at first), but filtering by RHEL version could be a problem rather than a solution. IMHO the @YongxueHong solution is the best.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, I am OK with then.

@mcasquer mcasquer force-pushed the 128_virtio_mem_unplug_message branch from eeddc5e to d6f3887 Compare October 7, 2024 06:29
Copy link
Contributor

@YongxueHong YongxueHong left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM.

From QEMU 9.1 onwards the error message displayed when the
virtio-mem device is tried to be unplugged while it still has
some memory plugged has been updated. Adding support for
both messages based on the version.

Signed-off-by: mcasquer <[email protected]>
@mcasquer mcasquer force-pushed the 128_virtio_mem_unplug_message branch from d6f3887 to 5f5008a Compare October 11, 2024 09:16
@mcasquer
Copy link
Contributor Author

This is a kindly reminder, @zhenyzha @yanan-fu could you review this PR? Thanks !

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants