Re: countdownEvent in BOCHS

I expect GUI update_freq to use real time but this is not always right:

#     The VGA update frequency is based on the emulated clock and the
default
#     value is 5. Keep in mind that you must tweak the 'cpu: ips=N'
directive
#     to be as close to the number of emulated instructions-per-second your
#     workstation can do, for this to be accurate. If the realtime sync is
#     enabled with the 'clock' option, the value is based on the real time.
#     This parameter can be changed at runtime.

Stanislav

-----Original Message-----
From: Xin Tong [mailto:[email protected]] 
Sent: Friday, October 05, 2012 3:20 PM
To: Stanislav
Cc: Volker Ruppert; [email protected]
Subject: Re: [Bochs-developers] countdownEvent in BOCHS

On Thu, Oct 4, 2012 at 11:22 AM, Stanislav <[email protected]> wrote:
>>If only CPU0 executes the BX_TICKN.  then what about APIC periodic 
>>timer
> interrupt specific to each CPU. i think for the least part each CPU 
> should be responsible to execute BX_TICKN for their own timer 
> interrupt, should
>>not they ?
>
> APIC timer periodic interrupt is not CPU specific. It says - I want 
> interrupt on this CPU after N ticks passed.
>
> When the N ticks are passed cannot be decided within single CPU, at 
> least with current definition of a "tick" in SMP mode.
>
> In SMP mode amount of "ticks" passed between two points in time can be 
> calculated using simple formula:
>
>  Sum of (instructions executed by each processor) / Number of 
> processors
>
> When ticks in their DEFINITION connected to #instruction executed - 
> things might look unnatural.
>
> Stanislav

I see, the  currCountdownPeriod is a global to all CPUs in the code.
so even only CPU0 executes the BX_TICKN. it is ok as eventually APIC will be
raised for all CPUs when the count down reaches 0. BTW, bochs seems to
estimate amount of time spent in terms of instructions emulated. is there
any place in bochs in which real time is used ?

Thanks

Xin

>
> -----Original Message-----
> From: Xin Tong [mailto:[email protected]]
> Sent: Thursday, October 04, 2012 4:45 PM
> To: Stanislav
> Cc: Volker Ruppert; [email protected]
> Subject: Re: [Bochs-developers] countdownEvent in BOCHS
>
> On Tue, Oct 2, 2012 at 3:18 PM, Stanislav <[email protected]> wrote:
>>>Right now, if one is to parallelize BOCHS. what is needed ? a couple 
>>>of
>> things that i know right off the bat.
>>>1. every CPU needs to be put in its own threads ( pthread on linux).
>>>2. only one cpu executes BX_TICKN in main.cc ( is this true ? ).
>>
>> Yes
>
> If only CPU0 executes the BX_TICKN.  then what about APIC periodic 
> timer interrupt specific to each CPU. i think for the least part each 
> CPU should be responsible to execute BX_TICKN for their own timer 
> interrupt, should not they ?
>
> Xin
>
>>
>>>3. code cache needs to be protected with locks or private code cache 
>>>needs
>> to be implemented.
>>>4. lock instructions need to be emulated properly.
>>
>> When every cpu runs in its own thread the one CPU which calls to 
>> BX_TICKN will have hard time to do so.
>> It should ping other CPUs and see how they are going, otherwise it is 
>> possible that one of the threads will go significantly faster than 
>> others or another bad artifacts.
>> Better way is to have smth like thread scheduler in the main.cc which 
>> will spawn threads for different CPUs with some limitations.
>> For example - if it knows that next interrupt should come after N 
>> instructions - it could let all threads to run N instructions at most 
>> and when stop at some barrier.
>> When handle interrupt properly and allow them to run again.
>>
>> Disclaimer: I never thought about it seriously so take all that I am 
>> saying with grain of salt.
>> I guess nobody will know what are the problems gonna be until trying 
>> to do actual implementation.
>>
>> Stanislav
>>
>> P.S. There is another issue - Intel Arch assumes that all naturally 
>> aligned memory accesses of 1,2,4 and 8 bytes length are atomic so 
>> some locks and barriers could be avoided if using them.
>> This is not necessary true in Bochs as is and some work required to 
>> guarantee that - especially on big endian hosts!
>>
>> -----Original Message-----
>> From: Xin Tong [mailto:[email protected]]
>> Sent: Tuesday, October 02, 2012 9:48 PM
>> To: Stanislav
>> Cc: Volker Ruppert; [email protected]
>> Subject: Re: [Bochs-developers] countdownEvent in BOCHS
>>
>> On Tue, Oct 2, 2012 at 3: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.
>>> 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
>>
>> Right now, if one is to parallelize BOCHS. what is needed ? a couple 
>> of things that i know right off the bat.
>> 1. every CPU needs to be put in its own threads ( pthread on linux).
>> 2. only one cpu executes BX_TICKN in main.cc ( is this true ? ).
>> 3. code cache needs to be protected with locks or private code cache 
>> needs to be implemented.
>> 4. lock instructions need to be emulated properly.
>>
>> Xin
>>
>>>
>>> -----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