On Thu, May 26, 2011 at 09:49:21AM +0200, Paolo Bonzini wrote:
> On 05/26/2011 09:07 AM, Gleb Natapov wrote:
> >> Still, op_bytes is irrelevant for
> >> SrcDX, the 16-bit version is always used.
> >
> >If SrcDX/DstDX will be used only for decoding in/out instruction
> >then yes. Otherwise it is nic
On Thu, May 26, 2011 at 11:00:24AM +0200, Paolo Bonzini wrote:
> On 05/26/2011 10:26 AM, Gleb Natapov wrote:
> >Why would c->dst.bytes != c->src.bytes for cwd/cdq/cqo if we'll set
> >c->dst.bytes to op_bytes during decode?
>
> Duh, you're right, cwd/cdq/cqo uses SrcAcc which has
>
>
On Thu, May 26, 2011 at 11:23:44AM +0200, Paolo Bonzini wrote:
> On 05/26/2011 11:02 AM, Gleb Natapov wrote:
> >We can make it honor ByteOp. There will be no instruction that will
> >specify DstDX | ByteOp though.
>
> "in %dx, %al" and "out %al, %dx" will via D2bv.
>
Yeah. Should ignore ByteOp th
On 05/26/2011 11:02 AM, Gleb Natapov wrote:
We can make it honor ByteOp. There will be no instruction that will
specify DstDX | ByteOp though.
"in %dx, %al" and "out %al, %dx" will via D2bv.
Paolo
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to maj
On 05/26/2011 10:26 AM, Gleb Natapov wrote:
Why would c->dst.bytes != c->src.bytes for cwd/cdq/cqo if we'll set
c->dst.bytes to op_bytes during decode?
Duh, you're right, cwd/cdq/cqo uses SrcAcc which has
c->src.bytes = (c->d & ByteOp) ? 1 : c->op_bytes;
so in practice c->src.
On Thu, May 26, 2011 at 09:49:21AM +0200, Paolo Bonzini wrote:
> On 05/26/2011 09:07 AM, Gleb Natapov wrote:
> >> Still, op_bytes is irrelevant for
> >> SrcDX, the 16-bit version is always used.
> >
> >If SrcDX/DstDX will be used only for decoding in/out instruction
> >then yes. Otherwise it is nic
On 05/26/2011 09:07 AM, Gleb Natapov wrote:
> Still, op_bytes is irrelevant for
> SrcDX, the 16-bit version is always used.
If SrcDX/DstDX will be used only for decoding in/out instruction
then yes. Otherwise it is nice to have more general decoder.
Not counting instructions that read/write ma
On Thu, May 26, 2011 at 10:04:24AM +0300, Avi Kivity wrote:
> On 05/26/2011 10:02 AM, Avi Kivity wrote:
> >
> >>Can
> >>c->op_bytes ever be 1?
> >
> >in %dx, %al
> >
>
> er, that doesn't change op_bytes.
Yep.
>Still, op_bytes is irrelevant for
> SrcDX, the 16-b
On 05/26/2011 10:02 AM, Avi Kivity wrote:
Can
c->op_bytes ever be 1?
in %dx, %al
er, that doesn't change op_bytes. Still, op_bytes is irrelevant for
SrcDX, the 16-bit version is always used.
--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to con
On 05/26/2011 09:55 AM, Gleb Natapov wrote:
> >
> >+ case SrcDX:
> >+ c->src.type = OP_REG;
> >+ c->src.bytes = c->op_bytes;
>
> Needs to be 2. Otherwise we'll see extra bits from edx, or lose
> bits from dx if it's a 1-byte instruction.
>
But those extra bits w
On Thu, May 26, 2011 at 09:31:50AM +0300, Avi Kivity wrote:
> On 05/25/2011 09:18 PM, Marcelo Tosatti wrote:
> >Commit fa4491a6b667304 moved the permission check for io instructions
> >to the ->check_perm callback. It failed to copy the port value from RDX
> >register for string and "in,out ax,dx"
On 05/25/2011 09:18 PM, Marcelo Tosatti wrote:
Commit fa4491a6b667304 moved the permission check for io instructions
to the ->check_perm callback. It failed to copy the port value from RDX
register for string and "in,out ax,dx" instructions.
Fix it by reading RDX register at decode stage when ap
Commit fa4491a6b667304 moved the permission check for io instructions
to the ->check_perm callback. It failed to copy the port value from RDX
register for string and "in,out ax,dx" instructions.
Fix it by reading RDX register at decode stage when appropriate.
Fixes FC8.32 installation.
Signed-
13 matches
Mail list logo
