https://bugzilla.kernel.org/show_bug.cgi?id=221841
--- Comment #4 from [email protected] ---
(In reply to vkuznets from comment #2)
> Ideally, we can try and see what genuine Hyper-V gives us
> in this situation (by e.g. running an instrumented version of KVM there). It
> does not seem that we have an extreme urgency here so I can put it to my
> backlog and try to get to it some time next week -- unless someone beats me
> to it of course!
Tested on Azure. Apparently, VMPTRLD is completely unsupported and generates
#UD right away, no matter if I give it the same 'enlightened' address or
something else. VMPTRST, however, is different: before VMLAUNCH it gives us
0xffffffffffffffff even after we set a valid eVMCS pointer to the VP assist
page. This is (AFAIU) somewhat similar to the architectural behavior when we
execute VMPTRST with no current-VMCS pointer. After VMLAUNCH it works normally
and gives us the eVMCS pointer we used. I think it makes sense to mimic the
behavior in KVM.
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.