[Qemu-devel] high resolution timer question

[Qemu-devel] high resolution timer question

[Robert Reif]

Writing data to a serial port on the sparc emulation happens immediately.
I would like to throttle the write speed to match the actual baud rate. 
What's the best way to do this in qemu?  Will QEMUTimer work for a
1 millisecond timer?

RE: [Qemu-devel] high resolution timer question

[Arnon Gilboa]

The usb host controller emulations in qemu (usb-uhci & usb-ohci) use
QEMUTimer for 1 millisecond timer.
This precise interval is required for generating usb 1.1 frames.
I currently implement usb 2.0 host controller emulation for qemu
(usb-ehci).
It uses QEMUTimer for generating usb 2.0 microframes of 125 microsecond.
This resolution worked precisely only after compiling the host kernel
with high resolution timers and dynamic ticks.

-----Original Message-----
From: qemu-devel-bounces+arnong=qumranet.com@nongnu.org
[mailto:qemu-devel-bounces+arnong=qumranet.com@nongnu.org] On Behalf Of
Robert Reif
Sent: Monday, December 10, 2007 3:00 PM
To: qemu-devel@nongnu.org
Subject: [Qemu-devel] high resolution timer question

Writing data to a serial port on the sparc emulation happens
immediately.
I would like to throttle the write speed to match the actual baud rate. 
What's the best way to do this in qemu?  Will QEMUTimer work for a
1 millisecond timer?

Re: [Qemu-devel] high resolution timer question

[Blue Swirl]

On 12/10/07, Robert Reif <reif@earthlink.net> wrote:
> Writing data to a serial port on the sparc emulation happens immediately.
> I would like to throttle the write speed to match the actual baud rate.
> What's the best way to do this in qemu?  Will QEMUTimer work for a
> 1 millisecond timer?

Do you mean that you want the serial port to match the host speed so
that for example, at 9600 baud, target would only receive 9600 bits
per second? Or do you mean that the emulated CPU should see bits
arriving at the same rate that the real CPU would see compared to CPU
execution speed?

On the positive side, this would fix a bug with serial interrupts
arriving too fast which can trigger Linux panics. But this would also
complicate the design because currently the devices do not need to
emulate any internal buffers.

I think the throttling should be done at CharDriver level so that all
targets and also other devices, like parallel ports (SUNW,bpp anyone?)
can benefit. It should be turned off when talking to real hardware on
the host.

Re: [Qemu-devel] high resolution timer question

[Anthony Liguori]

Blue Swirl wrote:
> On 12/10/07, Robert Reif <reif@earthlink.net> wrote:
>   
>> Writing data to a serial port on the sparc emulation happens immediately.
>> I would like to throttle the write speed to match the actual baud rate.
>> What's the best way to do this in qemu?  Will QEMUTimer work for a
>> 1 millisecond timer?
>>     
>
> Do you mean that you want the serial port to match the host speed so
> that for example, at 9600 baud, target would only receive 9600 bits
> per second? Or do you mean that the emulated CPU should see bits
> arriving at the same rate that the real CPU would see compared to CPU
> execution speed?
>
> On the positive side, this would fix a bug with serial interrupts
> arriving too fast which can trigger Linux panics. But this would also
> complicate the design because currently the devices do not need to
> emulate any internal buffers.
>
> I think the throttling should be done at CharDriver level so that all
> targets and also other devices, like parallel ports (SUNW,bpp anyone?)
>   

But the timing is entirely a concept of the hardware devices.  It seems 
like it would be easier to just add a growable buffer, and then setup a 
timer in each device that reads from the buffer.

Regards,

Anthony Liguori

> can benefit. It should be turned off when talking to real hardware on
> the host.
>
>
>
>   

Re: [Qemu-devel] high resolution timer question

[Paul Brook]

> > I think the throttling should be done at CharDriver level so that all
> > targets and also other devices, like parallel ports (SUNW,bpp anyone?)
>
> But the timing is entirely a concept of the hardware devices.  It seems
> like it would be easier to just add a growable buffer, and then setup a
> timer in each device that reads from the buffer.

I don't see why timing is device specific. The mechanisms for setting the 
speed are device specific, but the throttling should not be.
You may need to augment the char driver API to support outgoing throttling.

I'd also like to request that this feature be disabled by default. As I've 
mentined several times before qemu is not cycle accurate, so any attempt to 
do "accurate" timing is completely arbitrary.

In practice I'd expect any throttling is probably going to have to be fairly 
coarse grained because the emulated cpu speed is extremely 
variable/irregular, and you're limited by host timer resolution.

Paul

Re: [Qemu-devel] high resolution timer question

[Robert Reif]

Blue Swirl wrote:

>On 12/10/07, Robert Reif <reif@earthlink.net> wrote:
>  
>
>>Writing data to a serial port on the sparc emulation happens immediately.
>>I would like to throttle the write speed to match the actual baud rate.
>>What's the best way to do this in qemu?  Will QEMUTimer work for a
>>1 millisecond timer?
>>    
>>
>
>Do you mean that you want the serial port to match the host speed so
>that for example, at 9600 baud, target would only receive 9600 bits
>per second? Or do you mean that the emulated CPU should see bits
>arriving at the same rate that the real CPU would see compared to CPU
>execution speed?
>
>On the positive side, this would fix a bug with serial interrupts
>arriving too fast which can trigger Linux panics. But this would also
>complicate the design because currently the devices do not need to
>emulate any internal buffers.
>
>  
>
The problem I'm having is with sparc32 using a sun openboot image in
nographics mode where the prom uses serial port A as the system console.
The serial port output shows up in the host terminal window that qemu
was started in.

Characters written to serial port A are not reliably making it to the 
screen.
Turning on serial debugging shows that the characters are written to the
serial port.  The characters do make it to the screen when debugging.

If characters are not queued, then that might explain the loss but it looks
like the characters are going to a write(fd, ...) so is stdio loosing 
the characters?

I thought slowing down the rate to realistic speeds might help but that 
doesn't
seem to be where the problem really is.

Re: [Qemu-devel] high resolution timer question

[Robert Reif]

Robert Reif wrote:

> The problem I'm having is with sparc32 using a sun openboot image in
> nographics mode where the prom uses serial port A as the system console.
> The serial port output shows up in the host terminal window that qemu
> was started in.
>
> Characters written to serial port A are not reliably making it to the 
> screen.
> Turning on serial debugging shows that the characters are written to the
> serial port.  The characters do make it to the screen when debugging.

The problem seems to be caused by multiple streams outputting to the screen.
It looks like different ways of outputting to the same device may use 
different
streams!

Re: [Qemu-devel] high resolution timer question

[Robert Reif]

Robert Reif wrote:

>> Characters written to serial port A are not reliably making it to the 
>> screen.
>> Turning on serial debugging shows that the characters are written to the
>> serial port.  The characters do make it to the screen when debugging.
>
>
> The problem seems to be caused by multiple streams outputting to the 
> screen.
> It looks like different ways of outputting to the same device may use 
> different
> streams!

Please disregard this possible cause.  I left a debugging printf in by 
accident.
The real problem is still there though.