| |
| |
| |
|
Page: 1 2 3
Comments:
<0> howdy hint
<0> hint: what do you think about a shared memory display driver for use by a gui? this would make the whole wxwindows/c++ a little more managable
<0> i was thinking -shmem dev where the name of a CharDriver.. that would be used to communicate update/resize info and the actual shared memory id
<1> hi
<1> aliguori: I have currently no opinion for that !
<0> :-)
<1> and my opinion about the GUI is changing every day in fact
<0> hehe
<0> any current thoughts?
<0> fwiw
<1> I can change my mind about wxWindows
<1> Another point is that it is likely that there will be at least two "official GUIs"
<1> let me explain:
<1> I am currently thinking about making a debugger based on QEMU and this debugger will need a GUI
<1> it is not sure yet if the GUI for this project will be open source
<2> that sounds really interesting
<1> and in such case it will not be part of QEMU so it will be an external process
<1> another point is that most users want a GUI to use QEMU to launch their favorite OS
<3> hint: For debugging I'd reccomment exposing the functionality over the gdb remote protocol.
<3> That way yyou can reuse existing debuggers instead of having to write your own.
<4> pbrook: which gdb protocol?
<3> The gdb remote protocol. AFAIK there's only one.
<1> pbrook:I don't know yet what to do for the protocol. I may make a new debugger GUI because the QEMU debugger will have features very different from other debuggers
<3> Really? How so?
<0> hint: i'll send out a shmem patch then.. with x-windows, it'll allow you to have an external gui that performs just as well as sdl currently does
<4> pbrook: IIRC there are several versions, and it's cryptic after all
<1> but if I see an existing GUI I will use it of course as it will save a lot of work !
<3> gdb is currently growing all the remote protocol bits needed to support nontrivial remote targets.
<1> pbrook: it is very likely that gdb will be the protocol, although with some extensions
<3> hint: How is qemu different to any other debug target?
<1> pbrook: I want to favorise the temporal aspects and the ability to see a huge number of events
<3> And that means what?
<1> to go back in time and to record any number of "interesting events" such as function calls, phys or virt mem access, syscalls, device access...
<3> There's plenty of fancy debug hardware can do that.
<1> I don't have these hardwares :-)
<3> No, but my point is it doesn't seem specific to qemu. Hence it's worth implementing in a generic manner.
<3> ... unless you really want to implement a debugger gui :-)
<1> pbrook: I don't want to implement the GUI, but I see no other solutions yet
<1> and the first step is to have the basic features in QEMU itself - then anyone can use it the way he wants
<1> the interface can be either the gdb protocol or the QEMU monitor .
<3> FWIW we (CodeSourcery) are also looking at adding better trace/debug stuff.
<1> so you will help me :-)
<3> We've come to the conclusion that eclipse plugins are the only sane way forward.
<3> We'd almost certainly be interested in cooperating.
<1> as I said the first step is to implement the features in QEMU
<1> I begin to wrote a small TODO list - I can share it if you want
<3> That'd be good.
<3> Watchpoints have been on my list of things to implement for ages.
<1> aliguori: OK send the patch !
<1> pbrook: quickly here are the topics
<1> - cycle counter (almost ready)
<1> - event system to replace the logging (all the breakpoints for example will use this event system)
<1> better VM save/restore logic
<1> extraction of current process info according to the current OS
<1> but I'll make a more precise list
<3> Isn't the extraction something better left to the debugger?
<1> pbrook: yes - I just say it must be done somewhere
<1> I also want to be able to read and modify the state of every device
<1> a simple way to use the VM save/restore system and to give a name and type to every field
<1> a simple way *is* to use
<1> [I am now fixing the qemu timers in case of variable host tsc freq]
<3> Are you still using the TSC as a clock source?
<1> yes
<3> Can't you afford to use a higher overhead source (eg. gettimeofday) when you have a cycle counter?
<1> I thought about that and until yesterday it was my only solution
<1> but I think now it is possible to use the tsc and to correct its frequency on the fly
<1> I made a small simulation and it seems to work
<3> Does that really gain you anything?
<1> I am not sure!
<1> I think that for every device the speed is not critical
<3> It would be nice if it would work on hosts that don't have a TSC.
<1> IMHO the only critical case is when the target CPU uses RDTSC or equivalent
<1> and I realized there was 2 cases:
<3> But the target rdtsc just reads the clock counter doesn't it?
<3> s/clock/cycle/
<1> yes, and this is not fully correct in fact.
<3> Oh?
<1> on i386 there are two cases:
<1> - if kqemu is enabled, the only sane behaviour is that target RDTSC = host RDTSC
<1> - if kqemu is not enabled or if not i386 host, one can use an arbitrary TSC frequency (see the PPC target case)
<3> Oh. Well with kqemu you're screwed anyway.
<1> yes, kqemu is a very specific case
<1> but otherwise the target TSC freq should be arbitrary
<1> currently on i386 it is the same as the host, but I don't see any reason for that
<3> Are you trying to maintain a constant guest TSC frequency?
<1> so the critical point is really what to do for i386 target RDTSC !
<1> doing something like a gettimeofday would be too slow
<1> (the windows port of QEMU does that and it was a mistake for me to accept it)
<1> (on my pc gettimeofday takes about 0.6 us)
<3> Why don't you just return the value of the cycle counter? I'd expect that you only need fairly coarse sync between read and virtual time (say every few ms)
<1> pbrook: when the cycle counter is enabled it is another story and it is simple in this case
<3> Oh, so you're implementing this without the cycle counter activated?
<1> yes - I just want to fix the variable TSC issue for the 0.8.2. I see it as a complelety different task than the cycle counter
<1> but maybe the solution is to always use the cycle counter in fact !!!
<1> even if it is slower
<1> when the cycle counter is enabled, there is no specific problem except if you want that the VM stays in sync with the real time - but I don't want that yet
<1> maybe the same algorithm than the TSC freq estimation could be used to keep the cycle counter in sync with real time
<3> I was thinking you have all the qemu timers use a fixed timebase. Then internally map that onto the cycle counter. Periodically adjust that mapping depending whether the guest is ahead/behind realtime.
<3> The important bit being the internal mapping so you can change the ratio without breaking N different bits of hardware emulation.
<3> Does your non-cycle counted solution compensate for missed timer interrupts?
<3> On moderately loaded machines that can cause noticable clock drift.
<1> for the cycle counter, as you say all the qemu timers use a fixed timebase
<3> I think you want to do that in all cases.
<3> fixed timebase == constant value of ticks_per_sec.
<1> the only parameter is ticks_per_sec which is used to make the correspondance between target cycles and device timers
<3> That's not a constant though.
<3> Which means all the device code has to deal with variable timer fequencies.
<1> in my current implement of the cycle counter it is constant (the user gives it as parameter)
<3> I think we need to design this so it works in both deterministig and realtime modes.
<1> so you suggest to add a mode where the cycle counter is used in real time ?
<3> Yes.
<1> interesting. I know bochs does that
<3> Basically use the cycle counter instead of the host TSC.
<1> the question is : do we need to keep a version without the cycle counter !
<3> If we can make the cycle counter go reasonably fast, no.
<1> the cycle counter is very interesting too because it solves another problem: it is much easier to stop the virtual CPU in a thread safe manner (useful for win32 SMP or if threads are used in QEMU)
<3> Yes. I agree.
<1> Good. I need to think about it (and to sleep !)
<1> I will make some benches to see the slow down
<1> if it is something like say 5% then it is OK
<3> There's some slack because well get speedup from not eliminating the overhead of thousands of SIGALARMS.
<3> s/form not /from /
<1> agreed. Another point is that the current I/O event handling of QEMU is not optimal (the I/Os cannot stop the virtual CPU)
<3> That will still be true won't it?
<1> using a thread for the select() for I/Os would add some performance gain, and for that cpu_interrupt() must be thread safe...
<3> right.
<1> so maybe I should release the 0.8.2 before doing that :-)
<3> Maybe worth hacking some sort of TSC adaiptive scaling then.
<3> I guess you could isolate it all in cpu_get_ticks to minimize disruption.
<1> yes, my current patch just changes cpu_get_ticks()
<1> but it is not finished yet...
<1> (maybe tomorrow)
<3> Oh, I also notived that things break if ticks_per_sec doesn't fit into a 32-bit int.
<3> It's a 64-bit variable, but only the bottom 32 bits are used.
<1> where is the bug ?
<3> Modern CPUs are getting dangerously close to 2^32 Hz :-)
<3> I think the fix is to make it 32-bit and scale appropriately.
<3> It's used as a 32-bit argument to the muldiv routines.
<1> OK.
<1> I would like to suppress most of the muldiv64 in the devices by allowing the creation a fixed frequency timers. I did not do it yet as it is mostly a cosmetic patch
<3> Yeah.
<3> The device code has way too much timer related hair. They shouldn't have to bother about missed or delayed timer interrupts.
<1> I agree. It is a very good justification to remove completely the TSC based timers
<3> You should be able to do qemu_set_timer_periodic(n, callback) and ***ume the callback is called every N ticks.
<1> yes, with the cycle counter you can have the garanty the qemu_mod_timer() works as expected
<1> malc will be happy too because the VGA retrace hacks will be possible :-)
<5> but only w/o kqemu right?
<1> I don't know yet what to do if kqemu is enabled
<5> i c
<1> just patching the target RDTSC is likely to suffice.
Return to
#qemu
or
Go to some related
logs:
xset: bad font path ubuntu
#ubuntu
toshiba 610CT debian
#lisp
powerprompt hacking
hairulfr
#perl
ubuntu alien not found
#python
Frogbarf
|
|