On Thu, Feb 28, 2019 at 10:05:02 -0800, Richard Henderson wrote:
> On 2/28/19 9:18 AM, Stephen Checkoway wrote:
> > I wonder if it would make sense to maintain a small cache of TLBs. The
> > majority of cases are likely to involving setting segment registers to one
> > of a handful of segments (e.g
On 2/28/19 9:18 AM, Stephen Checkoway wrote:
> I wonder if it would make sense to maintain a small cache of TLBs. The
> majority of cases are likely to involving setting segment registers to one
> of a handful of segments (e.g., setting es to ds or ss). So it might be nice
> to avoid the flushes en
This is all extremely helpful! I'll dig in and try this approach soon.
> On Feb 28, 2019, at 11:11, Richard Henderson
> wrote:
>
>> Are you thinking that this should be modeled as independent sets of TLBs,
>> one per mode?
>
> One per segment you mean?
Yes.
> Yes, exactly. Since each segm
On 2/28/19 7:01 AM, Stephen Checkoway wrote:
> I'm very new to this part of the code base. I'm not entirely sure how the
> softmmu translation process works. It looks like each target defines a
> number of MMU_MODES and each memory access TCG instruction (I'm not sure
> what these are called) encod
Apologies. I started writing this response several days ago but got busy.
> On Feb 26, 2019, at 11:56, Richard Henderson
> wrote:
>
> I am happy to have proper segmentation support upstream, but having read
> through your patch I think I would approach it differently: I would
> incorporate
> s
On 2/25/19 4:32 PM, Stephen Checkoway wrote:
> FWIW, I figured out an approach to this. Essentially, I'm reusing the
> function which computes linear addresses to enforce not only segment limits
> (in everything but long mode), but also read/write access (in protected mode).
>
> Unfortunately, t
FWIW, I figured out an approach to this. Essentially, I'm reusing the function
which computes linear addresses to enforce not only segment limits (in
everything but long mode), but also read/write access (in protected mode).
Unfortunately, that meant every call to the linear address computation
> On Feb 24, 2019, at 14:46, Peter Maydell wrote:
>
> On Sun, 24 Feb 2019 at 19:37, Stephen Checkoway
> wrote:
>> I think that something about adding the tcg_gen_brcond_tl is causing values
>> to become dead and then qemu aborts.
>
> Yep -- all "TCG temporaries" are dead at the end
> of a b
On Sun, 24 Feb 2019 at 19:37, Stephen Checkoway
wrote:
> I think that something about adding the tcg_gen_brcond_tl is causing values
> to become dead and then qemu aborts.
Yep -- all "TCG temporaries" are dead at the end
of a basic block, and brcond ends a basic block.
Only globals and "local te
Hi all,
Sorry for the long email. The TL;DR is I'm trying to add x86 segment limit
checks in TCG and my added code is causing qemu to abort during code generation
because some registers have become dead.
I have some x86 firmware that refuses to boot unless a variety of x86 security
mechanisms
10 matches
Mail list logo
