Re: countdownEvent in BOCHS

The similar thing happens for IDE disk as well .

#0  bx_hard_drive_c::ide_read_sector (channel=0 '\000',
buffer=0x7fffb5c94010 "\355\201", buffer_size=512) at harddrv.cc:3329
#1  0x000000000049e0e6 in bx_hard_drive_c::bmdma_read_sector
(this=<value optimized out>, channel=0 '\000', buffer=0x7fffb5c94010
"\355\201",
    sector_size=<value optimized out>) at harddrv.cc:3223
#2  0x00000000004b2881 in bx_pci_ide_c::timer () at pci_ide.cc:264
#3  0x0000000000471a42 in bx_pc_system_c::countdownEvent
(this=0x8708c0) at pc_system.cc:377
#4  0x000000000045dcfd in bx_pc_system_c::tickn (n=1) at pc_system.h:109

I still do not get it. is not disk supposed to be asynchrornous
devices. why does the way this is handled  seem like synchronous
devices to me?

Thanks

Xin



On Wed, Oct 3, 2012 at 1:00 PM, Xin Tong <[email protected]> wrote:
> I digged a bit more into this. i am looking at the callstack
>
> #0  bx_local_apic_c::service_local_apic (this=0x909388) at apic.cc:858
> #1  0x000000000050918a in trigger_irq (this=0x909388, vector=48 '0',
> delivery_mode=<value optimized out>, trig_mode=0 '\000') at
> apic.cc:921
> #2  bx_local_apic_c::deliver (this=0x909388, vector=48 '0',
> delivery_mode=<value optimized out>, trig_mode=0 '\000') at
> apic.cc:868
> #3  0x00000000005094e8 in apic_bus_deliver_lowest_priority (vector=48
> '0', dest=1, trig_mode=0, broadcast=0) at apic.cc:123
> #4  0x00000000004ad1df in bx_ioapic_c::service_ioapic (this=0x97ef60)
> at ioapic.cc:288
> #5  0x000000000047c8f4 in bx_pic_c::raise_irq (this=<value optimized
> out>, irq_no=0) at pic.cc:645
> #6  0x00000000004b664d in pit_82C54::clock (this=0x95dcd0, cnum=0
> '\000') at pit82c54.cc:508
> #7  0x00000000004b6af8 in pit_82C54::clock_multiple (this=0x95dcd0,
> cnum=0 '\000', cycles=0) at pit82c54.cc:312
> #8  0x00000000004b6bdd in pit_82C54::clock_all (this=0x95dcd0,
> cycles=1) at pit82c54.cc:595
> #9  0x000000000047da0e in periodic () at pit.cc:359
> #10 bx_pit_c::handle_timer () at pit.cc:181
> #11 0x000000000047976b in bx_virt_timer_c::periodic (this=0x873160,
> time_passed=<value optimized out>) at virt_timer.cc:159
> #12 0x0000000000479b57 in advance_virtual_time (this=0x873160) at
> virt_timer.cc:311
> #13 bx_virt_timer_c::timer_handler (this=0x873160) at virt_timer.cc:425
> #14 0x0000000000471a42 in bx_pc_system_c::countdownEvent
> (this=0x8708c0) at pc_system.cc:377
> #15 0x000000000045dcfd in bx_pc_system_c::tickn (n=3) at pc_system.h:109
>
> It seems to me that a virtual timer interrupt is triggered here and
> interrrupt is delivered to the CPU. A few questions though.
>
> 1. the virtual timer is not counting the real time here, rather, i
> think it is depending on the number of instructions that are executed.
> i.e.  countdownEvent gets called when a fixed number of instructions
> are executed.
> 2. when the interrupt is delivered, the CPU INTR and async_event will
> be set and the CPU will enter the handleAsyncEvent() function, which
> will then be directed to the correctly interrupt handling code based
> on CPL , DPL and IntVector and some other things ?
>
> Am I right ?
>
> Xin
>
>
> On Wed, Oct 3, 2012 at 11:24 AM, Xin Tong <[email protected]> wrote:
>> can you please comment on this if you have the time. i really want to
>> undertstand how IO is emulated in BOCHS and there is not much on IO in
>> the BOCHS under the hood document
>>
>> Thank you
>>
>> Xin
>>
>>
>> On Wed, Oct 3, 2012 at 11:29 AM, Xin Tong <[email protected]> wrote:
>>> On Wed, Oct 3, 2012 at 1:10 AM, Stanislav <[email protected]> wrote:
>>>>
>>>>>Make sure i understand you correctly here. the emulated time is defined by
>>>> the number of CPU instructions emulated. the input from the device could be
>>>> ready before that. but the CPU only checks for it when CPU >believes to be
>>>> neccessary. i.e. the number of instructions executed exceed some number.
>>>>
>>>> Not quite right.
>>>>
>>>> If device is done right, it raises IRQ by itself through PIC or I/O APIC.
>>>
>>> Ok what devices are done through raising IRQ by itself through PIC or
>>> I/O APIC ? can you please give an example in the code ?
>>>
>>>> Everything that is done through timers is done differently.
>>>
>>> what devices are done through periodic timers ? can you please give an
>>> example in the code ?
>>>
>>> Thanks a lot
>>>
>>> Xin
>>>
>>>
>>>>
>>>> Stanislav
>>>>
>>>> -----Original Message-----
>>>> From: Xin Tong [mailto:[email protected]]
>>>> Sent: Tuesday, October 02, 2012 11:11 PM
>>>> To: Stanislav
>>>> Cc: Volker Ruppert; [email protected]
>>>> Subject: Re: [Bochs-developers] countdownEvent in BOCHS
>>>>
>>>> On Tue, Oct 2, 2012 at 2:36 PM, Stanislav <[email protected]> wrote:
>>>>> Think real hardware CPU, it communicates with outer world with pins
>>>>> and interrupts.
>>>>>
>>>>> The CPU won't be aware of keyboard button pressed until keyboard
>>>>> controller send interrupt to it through PIC, right ?
>>>>>
>>>>> The fact that timers code is also handled from CPU code is atavism and
>>>>> should be fixed at some time.
>>>>>
>>>>> The countdownEvent function is called not from handleAsyncEvent
>>>>> function of CPU but from BX_TICKN which is called from CPU when it likes
>>>> to do so.
>>>>> The BX_TICKN calls for countdownEvent function if it sees that next
>>>>> event has to come already in terms of emulated time.
>>>>> This is one this way only because emulated time is ***defined*** using
>>>>> CPU instructions executed.
>>>>> The IPS variable says how many executed instruction would be 1
>>>>> emulated second.
>>>>> So if IPS=100M and timer for example should be called 10 times a
>>>>> second it would be called every 10M instructions. How ? CPU calls
>>>> BX_TICKN.
>>>>> In another implementation the timer could seat in another thread and
>>>>> ping periodically Bochs about instructions executed.
>>>>
>>>> Make sure i understand you correctly here. the emulated time is defined by
>>>> the number of CPU instructions emulated. the input from the device could be
>>>> ready before that. but the CPU only checks for it when CPU believes to be
>>>> neccessary. i.e. the number of instructions executed exceed some number.
>>>>
>>>> Xin
>>>>
>>>>> When is sees 10M instructions passed it would raise interrupt to CPU
>>>>> though PIC - this is the way I like more and promise you that someday
>>>>> things would work like this.
>>>>> Especially because it allows to do SMP emulation by several HW threads
>>>>> in more robust way.
>>>>>
>>>>> Stanislav
>>>>>
>>>>> -----Original Message-----
>>>>> From: Xin Tong [mailto:[email protected]]
>>>>> Sent: Tuesday, October 02, 2012 9:03 PM
>>>>> To: Stanislav
>>>>> Cc: Volker Ruppert; [email protected]
>>>>> Subject: Re: [Bochs-developers] countdownEvent in BOCHS
>>>>>
>>>>> On Tue, Oct 2, 2012 at 2:57 PM, Stanislav <[email protected]> wrote:
>>>>>> The async_event is nothing more than just an indication that CPU
>>>>>> should check for external events.
>>>>>> The events themselves are not necessary have to be pending at this
>>>>>> time,
>>>>>
>>>>> not too sure about what you mean by events here. can you please give
>>>>> an example ?
>>>>>
>>>>> Xin
>>>>>
>>>>>> moreover setting the bit alone as is won't cause any side effect.
>>>>>> The interrupts delivered to CPU through PIC, I/O APIC or APIC or by
>>>>>> raising external pins like SMI/NMI
>>>>>>
>>>>>> Stanislav
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Xin Tong [mailto:[email protected]]
>>>>>> Sent: Tuesday, October 02, 2012 7:46 PM
>>>>>> To: Volker Ruppert
>>>>>> Cc: [email protected]
>>>>>> Subject: Re: [Bochs-developers] countdownEvent in BOCHS
>>>>>>
>>>>>> On Tue, Oct 2, 2012 at 1:23 PM, Volker Ruppert
>>>>>> <[email protected]>
>>>>>> wrote:
>>>>>>> Hi!
>>>>>>>
>>>>>>>
>>>>>>>> so no immediate interrupt is generated when the keystroke is
>>>>>>>> received from the keyboard ? rather, the interrupt is only
>>>>>>>> generated when the timer fires and the input buffer of keyboard is
>>>> checkd ?
>>>>>>>
>>>>>>>
>>>>>>> That's right. The keyboard controller should not generate interrupts
>>>>>>> faster than it happens on real hardware. Note that the keyboard and
>>>>>>> mouse interrupts are only generated if enabled in the controller
>>>>>>> (and of course in the PIC). The timer handler also manages the paste
>>>>>>> feature. When pressing the paste button in the Bochs header bar,
>>>>>>> text data can be sent to the keyboard controller. A delay is
>>>>>>> required between each character to avoid a buffer overflow. The
>>>>>>> keyboard does not
>>>>>> yet emulate the typematic feature.
>>>>>>> The delay and characters per second depend on the host settings.
>>>>>>> When implementing this feature, most of the job must be done by the
>>>>>>> timer handler.
>>>>>>
>>>>>> so lets say i press a key on my computer keyboard. it will raise an
>>>>>> interrupt on my physical machine. the character is read and stored in
>>>>>> a BUFFER A. this BUFFER A is then later copied to a BUFFER B (in
>>>>>> bochs emulated keyboard) in bochs and bochs checks for what is in
>>>>>> BUFFER B when a timer fires.
>>>>>>
>>>>>> 2 questions.
>>>>>>
>>>>>> 1. when and how is the copying done from BUFFER A to BUFFER B ?
>>>>>> 2. why can not the same thread set a bit in the BX_CPU_C async_event
>>>>>> bit to force the checking of BUFFER B ?
>>>>>>
>>>>>> Xin
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>> The timer for the gui event handler is located in the devices.cc
>>>>>>>>> code. It calls bx_gui->handle_events() every 1 millisecond.
>>>>>>>>
>>>>>>>>
>>>>>>>>> This method sends the
>>>>>>>>> keyboard / mouse data to the buffer of the emulated device.
>>>>>>>>>
>>>>>>>> can you explain this a bit more ?
>>>>>>>
>>>>>>>
>>>>>>> The gui event handler is always called from the simulation thread
>>>>>>> (timer handler in devices.cc). If there is only one thread, the code
>>>>>>> polls outstanding events from the library used (e.g. X11, SDL).
>>>>>>> Mouse events can be sent directly to the hardware emulation (PS/2 ,
>>>> USB).
>>>>>>> Keyboard events must be translated to BX_KEY_* constants. If
>>>>>>> necessary (and enabled) a remap of the localized keyboard layout to
>>>>>>> the U.S. one is handled. In a multi-threaded environment (rfb,
>>>>>>> win32,
>>>>>>> wx) the gui thread detects events and stores them in a queue. The
>>>>>>> gui method
>>>>>>> handle_events() only has to read from this queue and continues
>>>>>>> processing
>>>>>> events as described above.
>>>>>>>
>>>>>>> Our development docs still have some empty sections. Some parts of
>>>>>>> this text might be useful there.
>>>>>>>
>>>>>>> --
>>>>>>> Thanks
>>>>>>>
>>>>>>> Volker
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> -
>>>>>> ------
>>>>>> --
>>>>>> Don't let slow site performance ruin your business. Deploy New Relic
>>>>>> APM Deploy New Relic app performance management and know exactly what
>>>>>> is happening inside your Ruby, Python, PHP, Java, and .NET app Try
>>>>>> New Relic at no cost today and get our sweet Data Nerd shirt too!
>>>>>> http://p.sf.net/sfu/newrelic-dev2dev
>>>>>> _______________________________________________
>>>>>> bochs-developers mailing list
>>>>>> [email protected]
>>>>>> https://lists.sourceforge.net/lists/listinfo/bochs-developers
>>>>>>
>>>>>
>>>>

------------------------------------------------------------------------------
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev