Joerg Roedel wrote: > On Thu, Mar 22, 2007 at 12:42:28PM +0200, Avi Kivity wrote: > >> Joerg Roedel wrote: >> >>> There is no danger for the host kernel but for the guest. If the >>> userspace sets the monitor bit the guest will receive an #UD when trying >>> to use it. And we don't want the guest to use it because it is not >>> virtualized yet. >>> >>> >> So, isn't a simpler fix not to set the monitor bit in cpuid? >> >> The patch is correct, but I don't see why it's needed as any guest will >> check the cpuid bit >> before using monitor. >> > > Right. But it is possible for userspace to enable monitor bit for the > guest. Without virtualization of these 2 instructions the guest would > idle in the guest state after calling mwait and prevent other processes > and guests from running in that time.
Won't an interrupt during mwait cause a vmexit? > I don't think this is acceptable. > And if we disable this bit in cpuid we should also prevent the > guest from executing it to emulate the behavior of a real cpu in host > mode. > So I agree we should mask the cpuid monitor bit. The savest way to do so > is in the kvm-amd module imho. And, also imho, we should the guest > really forbid to execute it. > I want to understand it exactly first. I don't see any barrier to applying the patch, I just want a full understanding. -- error compiling committee.c: too many arguments to function ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ kvm-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/kvm-devel
