Re: 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