Re: memory operation operand len

>missing Guest2Host TLB is different from missing the TLEntry, right ?
missing the TLB entry would result in call to translate_*** which will
refill the TLB with the lpf and ppf mapping and possibly hostaddr as well.

 

Guest2Host TLB is a hostaddr field in the TLBEntry. So TLB entry could be
also Guest2HstTLB but not necessary

 

Stanislav

 

From: Xin Tong [mailto:[email protected]] 
Sent: Monday, October 22, 2012 2:33 AM
To: Stanislav
Cc: [email protected]
Subject: Re: [Bochs-developers] memory operation operand len

 

 

On Sat, Oct 20, 2012 at 4:10 PM, Stanislav <[email protected]> wrote:

I didn't get which change you talking about .

 

BTW, I personally like incremental solutions.

 

I.e on the first step to spawn separate threads for each CPU and even but
real mutex per page for every load and store instructions (and don't forget
about code fetches).

Make sure this is works correctly with GUI libraries and devices and you
don't see any X11 assertions firing.

At the end of this stage you already could measure the performance gain vs
single threaded and merge it into SVN immediately for testing.

 

Later we could think of optimizations - eliminating mutexes and etc.

 

As I once explained, the stuff you currently doing won't work on other, non
x86 host. Even x86 host is not so trivial and might be a problem.

On x86 there is a guarantee that every 1,2,4 and 8 byte aligned access are
atomic and many libraries use this fact to build lock-less thread-safe
structures like queues and etc.

If you break this property and for example execute 8-byte aligned access as
4-byte followed by another 4-byte - real programs will break.

 

Yea, this could happen in case of emulating a 64bits guest on 32 bit host.
trying to lock the entire page (as what is done for atomic operations) may
be too expensive.

 

 

I could guarantee that no memory access (even aligned one) is atomic in
Bochs on big endian host (because of byte-swap required).

 

i do not think the byte swap is the problem here. as long as the writing is
atomic. I think it is ok. byte-swap is just a process to change the data
into a different endianness. 

 

I also cannot guarantee that much about non-x86 (like ARM).

I even need to go over the code and make sure that emulated memory access
missing Guest2Host TLB and served by memory object would be atomic. Might be
it even won't.

 

missing Guest2Host TLB is different from missing the TLEntry, right ?
missing the TLB entry would result in call to translate_*** which will
refill the TLB with the lpf and ppf mapping and possibly hostaddr as well.

 

So locked instructions are not only the problem.

 

Memory consistency differences may be a problem as well. 

 

Of course when first step is working (and could be kept as golden model) -
it is possible to continue to next step.

I like your idea writing to a page exclusively.

But I need to say that I never thought about it seriously. Hopefully I can
help you with understanding of infrastructural questions and Bochs design.

 

Stanislav

 

 

From: Xin Tong [mailto:[email protected]] 
Sent: Saturday, October 20, 2012 7:20 PM


To: Stanislav
Cc: [email protected]
Subject: Re: [Bochs-developers] memory operation operand len

 



On Sat, Oct 20, 2012 at 1:14 PM, Xin Tong <[email protected]> wrote:
> On Sat, Oct 20, 2012 at 7:12 AM, Stanislav <[email protected]> wrote:
>> If you want to acquire lock for all locked instructions you need to read
the
>> lock (check if the lock is acquired) by all others, right ?
>> It looks me the same effort as locking a page for ever memory access
without
>> taking care if it is locked instruction or not ...
>>
>> For the page split instructions -  think you already saw that
>> read_virtual_yyy would call for read/write_access_linear function where
page
>> split is handled.
>> The function is already written in the way it checks for both pages
before
>> the read or write actually happens. So at least you can guarantee that no
>> need to unlock anything in case of a fault.
>>
>> Could you explain the way you wanna do these locks ?
>
>
> Right now every page is associated with a lock. before an atomic
> instruction is about to be executed. the executing CPU send
> async_events to all other CPUs to give up their translations to the
> physical page. after this is don, the executing CPU can safely acquire
> exclusive access to the page. and it will release the exclusive access
> when it is done with the atomic instruction. and if the atomic
> instruction access crosses pages, the exclusive access is acquired on
> the adjacent linear address page.
>
> Hope this answers your question.

I suspect this will perform badly in case of lock contended pages. i.e. this
will cause many async events being sent and CPUs interrupted often. this
interrupt has a direct and indirect cost.

direct cost - interrupted CPU exits and a re-lookup of next entry is needed.
indirect cost - new entries being built in the middle of a basic block as
the CPU exits in the middle of a basicblock.

I have not measure the amount of impact these have.

a possible improvement would be to promote lock contended pages to a special
type of page of which a lock needs to be acquired/release before/after an
instruction that is going to access the page. 

i am thinking an extra check for contended pages can be added here 

// Translate a linear address to a physical address
bx_phy_address BX_CPU_C::translate_linear(bx_address laddr, unsigned user,
unsigned rw)
{
  ,...
  // already looked up TLB for code access
  if (TLB_LPFOf(tlbEntry->lpf) == lpf)
  {
    paddress = tlbEntry->ppf | poffset;

    // This is the meat of the TLB code. it uses the TLB to do fast
translation.
    if (! (tlbEntry->accessBits & ((isExecute<<2) | (isWrite<<1) | user)))
          return paddress;
    // The current access does not have permission according to the info
    // in our TLB cache entry.  Re-walk the page tables, in case there is
    // updated information in the memory image, and let the long path code
    // generate an exception if one is warranted.
  }

....
}


Xin 
>
> Xin
>
>
>>
>> Stanislav
>>
>> -----Original Message-----
>> From: Xin Tong [mailto:[email protected]]
>> Sent: Friday, October 19, 2012 10:37 PM
>> To: Stanislav
>> Cc: [email protected]
>> Subject: Re: [Bochs-developers] memory operation operand len
>>
>> i want to lock the page the atomic memory operation is going to work on .
>> this way atomic operations can be emulated correctly when the CPUs are
>> running in parallel.
>>
>> I happen to add function calls to acquire exclusive ownership of a page
just
>> before the atomic instruction is about to execute.
>>
>> In case of page fault, i think BOCHS returns to the CPU loop using
longjmp.
>> i  have code to release the exclusive ownership of the page there as
well.
>>
>> Xin
>>
>>
>> On Fri, Oct 19, 2012 at 3:27 PM, Stanislav <[email protected]> wrote:
>>> By reading the class bxInstruction_c you cannot know a thing,
>>> especially because some instructions access memory multiple times
>>> (FXSAVE, REP MOVS) or access variable amount of bytes (VMASKMOV).
>>>
>>> I am not talking about many memory access cases which not related to
>>> any instruction (page walks, descriptors reads and other system stuff).
>>>
>>> Also before the memory access actually happen an instruction might
>>> fault so the memory access won't happen.
>>>
>>> But what do you want to do ?
>>>
>>> Might be I can help ...
>>>
>>> If you searching to lock memory before memory access happens you can
>>> look for BX_NOTIFY_LIN_MEMORY_ACCESS and BX_NOTIFY_PHY_MEMORY_ACCESS
>>> all around the code.
>>>
>>> Stanislav
>>>
>>> -----Original Message-----
>>> From: Xin Tong [mailto:[email protected]]
>>> Sent: Friday, October 19, 2012 9:06 PM
>>> To: [email protected]
>>> Subject: [Bochs-developers] memory operation operand len
>>>
>>> what is the best way to figure out the length of the memory a memory
>>> operation is going to access in BOCHS ? I read the class
>>> bxInstruction_c. it does not seem to provide anything to do that ?
>>>
>>> Xin
>>>
>>> ----------------------------------------------------------------------
>>> ------
>>> --
>>> Everyone hates slow websites. So do we.
>>> Make your web apps faster with AppDynamics Download AppDynamics Lite
>>> for free today:
>>> http://p.sf.net/sfu/appdyn_sfd2d_oct
>>> _______________________________________________
>>> bochs-developers mailing list
>>> [email protected]
>>> https://lists.sourceforge.net/lists/listinfo/bochs-developers
>>>
>>

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct

_______________________________________________
bochs-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bochs-developers