Re: Setting hardware breakpoints in guest OS

[Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org>]

duck-j34lQMj1tz/QT0dZR+AlfA@public.gmane.org wrote:
>> While we tried to make debugging inside the guest work, this
>> was never really tested, so it's likely broken.  I'll try to
>> look at what it will take to make it work; I don't think there's
>> much needed.
>>     
>
>   

Thinking a bit, it may well be broken only when using the external 
module.  If you use a distro-provided kvm (or compile your own kernel 
with kvm included) then it might work.

Then again, distro provided kvms tend to be old and therefore slow.

> That sounds encouraging -- I had imagined there might be some
> "impossibility factor" in sharing something like hardware breakpoints
> between host and guest.
>
>   

Both vmx and svm fully allow virtualizing the hardware breakpoints (and 
even things like last branch recording).

> For now I'm simply sticking to QEMU+kqemu when I expect deliberate
> trickiness or need to do hard-breakpoint debugging, and QEMU/KVM (which is
> up to 50% faster when doing Windows software builds on my PC, nice!) when I
> don't care.
>
> I haven't had any problems loading and using the kvm drivers and kqemu at
> the same time, and I have assumed that there ought to be no issues in doing
> so, since they work quite differently and (from my very dangerously limited
> understanding) ought not to be competing for any mutually exclusive
> hardware resources. Is that a reasonable assumption?
>   

I believe so.  I know VirtualBox and VMware have problems coexisting 
with kvm (since they tend to switch to real mode which is forbidden by 
vmx), but if kqemu works, then there shouldn't be any hidden problems.

>   
>> What hardware are you using?  If you have both AMD and Intel
>> hardware, you might have better luck switching, since this is
>> very subarch dependent.
>>     
>
> Intel Core Duo (T2400 @ 1.83GHz according to /proc/cpuinfo), running 32-bit
> Linux 2.6.21.5 using KVM drivers built from the kvm-59 sourceball.
>
> Sorry, I don't have other vendors or CPU bitnesses to test on.
>
> PS: When I build KVM "out of the box," I get a qemu binary called
> qemu-system-x86_64, though I have a 32-bit CPU and a 32-bit OS. Forgive my
> ignorance on this, but...why does the name of the binary imply a 64-bit
> flavour?
>   

The qemu binary is 32-bit, but is capable of running a 64-bit guest if 
you have a 64-bit cpu and a 64-bit kernel (still retaining 32-bit 
userspace).

You can generate a 32-bit only binary, but that does not have any 
advantages over the 64-bit capable binary.

Yes, it confuses me too.

-- 
error compiling committee.c: too many arguments to function


-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace