Hi Gabe, That worked. Thank you.
Yasuko -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Gabe Black Sent: Friday, March 16, 2012 3:26 AM To: [email protected] Subject: Re: [gem5-dev] x86 segmentation support in gem5 Here, give this a try. http://reviews.gem5.org/r/1104/ Gabe On 03/15/12 08:33, Steve Reinhardt wrote: > Though on second thought maybe it's not worth truncating the linear > address at all... in protected mode, I expect that the proper behavior > for an address that overflows 32 bits is to fail the segment limit > test, which is probably easier if we just leave the address at 33 bits > and do a 64-bit compare with the limit. The 32-bit real mode issue is > one I'm willing to punt on, since (1) we don't run BIOS code at this > point and afaik don't have plans to, (2) even if we did decide to run > BIOS code we'd be crazy/stupid not to just use UEFI which won't have > this issue, and (3) even if we're crazy/stupid and try to run a BIOS > that uses this mode, I'd think there's a decent chance it doesn't rely > on handling this corner case correctly. So actually going through the > bother of figuring out if we should be doing the truncation and then > doing it on every single memory access seems like a high price to pay > relative to the odds that it will ever really matter. > > Steve > > On Thu, Mar 15, 2012 at 7:55 AM, Steve Reinhardt <[email protected]> wrote: > >> From what I can glean from the manual, the address size prefix >> controls the size of the "effective address", which in x86 lingo is >> the segment offset, not the "linear address", which is >> post-segmentation but pre-translation. So I think the only issue >> here is that we're truncating the linear address to the effective >> address size. As long as we're not bothering with emulating the A20 >> bit (which I think we shouldn't), then there's no need to truncate the >> linear address in real mode. >> >> I couldn't find anything specific in the documentation on 32-bit code >> beyond this assertion: "16-bit and 32-bit applications running in >> compatibility mode can access only the low 4GB of the long-mode >> virtual-address space. Likewise, a 32-bit address generated in 64-bit >> mode can access only the low 4GB of the long-mode virtual-address space." >> >> So overall I would suggest doing the address calc in two steps, an >> x86 effective address calc truncated to the address size (as stored >> in >> addrSize) followed by a linear address calc (addition of the segment >> base >> register) truncated to either 32 or 64 bits depending on the mode. >> Maybe we need a linearAddrSize variable to track the second limit? >> >> Steve >> >> >> On Thu, Mar 15, 2012 at 2:17 AM, Gabriel Michael Black < >> [email protected]> wrote: >> >>> Ok, I see why that's a problem, but now the question is what's the >>> right thing to do? In the 16 bit real mode case it would be to >>> truncate the address to 16 bits and then add the segment base, but >>> what about, say, the >>> 32 bit real mode case when an address size prefix is used and we've >>> inherited segment attributes from protected mode (a legal behavior >>> used by real BIOSes)? Do we let those addresses spill into bit 33? >>> That same problem would apply to 32 bit code in general. What about >>> 32 bit protected mode code with an address size prefix (inducing 16 >>> bit addresses) where adding in the 16 bit address carries into the >>> 17th bit? If we can determine what the rules for address sizes truly >>> are in a broad, ideally comprehensive, set of circumstances, then we >>> can figure out what this code should actually be doing so it always >>> (or some approximation there of) gets the right answer. >>> >>> Gabe >>> >>> >>> Quoting Nilay Vaish <[email protected]>: >>> >>> Yasuko, are you saying that the bits() operation below converts the >>>> address from 20-bits to a 16-bits? >>>> >>>> EA = bits(SegBase + scale * Index + Base + disp, addressSize * 8 - >>>> 1, 0); >>>> >>>> Note that all the addition operations are 64-bit, but the bits() >>>> operation will suitably choose the required bits. >>>> >>>> -- >>>> Nilay >>>> >>>> On Thu, 15 Mar 2012, Watanabe, Yasuko wrote: >>>> >>>> Hi Gabe, >>>>> Unfortunately, I cannot easily send an example because it is >>>>> proprietary code. But I will try to be more specific. >>>>> >>>>> Macro-op MOV_R_M has the following single micro-op: >>>>> Ld req, seg, sib, disp >>>>> >>>>> In 16-bit mode, seg contains a 20-bit segment-base address, and >>>>> sib and disp are used to compute a 16-bit offset. However, when >>>>> the segment-base address is added to the offset, it uses 16-bit >>>>> addition, so the load address becomes 16 bits, not 20 bits. >>>>> >>>>> Does this make sense? >>>>> >>>>> Yasuko >>>>> >>>>> -----Original Message----- >>>>> From: [email protected] >>>>> [mailto:gem5-dev-bounces@gem5.**org<[email protected]>] >>>>> On Behalf Of Gabriel Michael Black >>>>> Sent: Wednesday, March 14, 2012 3:33 AM >>>>> To: [email protected] >>>>> Subject: Re: [gem5-dev] x86 segmentation support in gem5 >>>>> >>>>> It would be really helpful if you could send me an example I could >>>>> run that demonstrates the problem. >>>>> >>>>> Gabe >>>>> >>>>> Quoting "Watanabe, Yasuko" <[email protected]>: >>>>> >>>>> Hi Gabe, >>>>>> Let me clarify. Setting a segment-base address is done correctly, >>>>>> as you pointed out by the MOV_REAL_* macro-ops. The issue is >>>>>> adding the 20-bit base address to a 16-bit address to produce a >>>>>> 20-bit linear address when accessing the memory. Specific >>>>>> examples include MOV_R_MI and MOV_R_M, just to name a few. >>>>>> >>>>>> Yasuko >>>>>> >>>>>> -----Original Message----- >>>>>> From: [email protected] >>>>>> [mailto:gem5-dev-bounces@gem5.**org<[email protected]> >>>>>> ] >>>>>> On Behalf Of Gabriel Michael Black >>>>>> Sent: Monday, March 12, 2012 11:32 PM >>>>>> To: [email protected] >>>>>> Subject: Re: [gem5-dev] x86 segmentation support in gem5 >>>>>> >>>>>> 16 bit real mode and 32 bit legacy mode are already supported, >>>>>> although not as well as 64 bit mode. When the address size is 16 >>>>>> bits, that's the size of the virtual address from the instruction. >>>>>> It's then turned into a linear address by applying segmentation, >>>>>> and then a physical address by applying paging. The first of >>>>>> those is done by the instruction itself. Paging and the >>>>>> permission checks for segmentation and paging are done by the >>>>>> TLB. The 16 bit real mode segment base should be used to compute >>>>>> the base added to the virtual address by shifting it to the left by 4, >>>>>> as defined by the ISA. >>>>>> That's done when the selector is assigned in real mode. See here: >>>>>> >>>>>> http://repo.gem5.org/gem5/**file/6df06e5975c6/src/arch/** >>>>>> x86/isa/insts/gen<http://repo.gem5.org/gem5/file/6df06e5975c6/src >>>>>> /arch/x86/isa/insts/gen> >>>>>> eral_purpose/data_transfer/**move.py#l214 >>>>>> >>>>>> Gabe >>>>>> >>>>>> Quoting "Watanabe, Yasuko" <[email protected]>: >>>>>> >>>>>> Hi, >>>>>>> I have been working on adding x86 16-bit and 32-bit legacy mode >>>>>>> operations. The current infrastructure makes it very hard to >>>>>>> compute linear addresses due to segmentation, and I would like >>>>>>> to get advice from the gem5 community. >>>>>>> >>>>>>> Here is the issue. In 16-bit legacy mode, the default effective >>>>>>> address size is 16-bits; however, it has to be zero-extended and >>>>>>> added to a 16-bit segment-base address that is left-shifted by >>>>>>> four bits, producing a 20-bit linear address. My understanding >>>>>>> is that >>>>>>> gem5 does not differentiate the effective address computation >>>>>>> part from the latter part of adding a 20-bit segment-base >>>>>>> address. That is, when you specify an address size either in >>>>>>> predecoder.cc through emi.addrSize or in the macro-op definition >>>>>>> files through addressSize, that size is enforced even to a segment-base >>>>>>> address. >>>>>>> As a result, in a typical case of 16-bit effective addresses in >>>>>>> legacy mode, you are truncating the upper four bits from a >>>>>>> segment-base address, getting a wrong 16-bit linear address. >>>>>>> >>>>>>> I have temporary workarounds but would love to implement a more >>>>>>> permanent solution. Please let me know if you have thoughts on this. >>>>>>> >>>>>>> Thank you, >>>>>>> Yasuko >>>>>>> >>>>>>> ______________________________**_________________ >>>>>>> gem5-dev mailing list >>>>>>> [email protected] >>>>>>> http://m5sim.org/mailman/**listinfo/gem5-dev<http://m5sim.org/ma >>>>>>> ilman/listinfo/gem5-dev> >>>>>>> >>>>>>> >>>>>> ______________________________**_________________ >>>>>> gem5-dev mailing list >>>>>> [email protected] >>>>>> http://m5sim.org/mailman/**listinfo/gem5-dev<http://m5sim.org/mai >>>>>> lman/listinfo/gem5-dev> >>>>>> >>>>>> >>>>>> ______________________________**_________________ >>>>>> gem5-dev mailing list >>>>>> [email protected] >>>>>> http://m5sim.org/mailman/**listinfo/gem5-dev<http://m5sim.org/mai >>>>>> lman/listinfo/gem5-dev> >>>>>> >>>>>> >>>>> ______________________________**_________________ >>>>> gem5-dev mailing list >>>>> [email protected] >>>>> http://m5sim.org/mailman/**listinfo/gem5-dev<http://m5sim.org/mail >>>>> man/listinfo/gem5-dev> >>>>> >>>>> >>>>> ______________________________**_________________ >>>>> gem5-dev mailing list >>>>> [email protected] >>>>> http://m5sim.org/mailman/**listinfo/gem5-dev<http://m5sim.org/mail >>>>> man/listinfo/gem5-dev> >>>>> >>>>> ______________________________**_________________ >>>> gem5-dev mailing list >>>> [email protected] >>>> http://m5sim.org/mailman/**listinfo/gem5-dev<http://m5sim.org/mailm >>>> an/listinfo/gem5-dev> >>>> >>>> >>> ______________________________**_________________ >>> gem5-dev mailing list >>> [email protected] >>> http://m5sim.org/mailman/**listinfo/gem5-dev<http://m5sim.org/mailma >>> n/listinfo/gem5-dev> >>> >> > _______________________________________________ > gem5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/gem5-dev _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
