On Thu, 2011-05-26 at 12:20 +0300, Pekka Enberg wrote:
> On Thu, May 26, 2011 at 12:14 PM, Sasha Levin wrote:
> >> > I've wanted to keep the original interface clean, Most of the IO port
> >> > users don't (and probably won't) require a parameter.
> >>
> >> Well now struct ioport_operations isn't
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 Thu, May 26, 2011 at 12:14 PM, Sasha Levin wrote:
>> > I've wanted to keep the original interface clean, Most of the IO port
>> > users don't (and probably won't) require a parameter.
>>
>> Well now struct ioport_operations isn't very clean is it - or the code
>> that needs to determine which f
On Thu, 2011-05-26 at 12:04 +0300, Pekka Enberg wrote:
> On Thu, May 26, 2011 at 12:02 PM, Sasha Levin wrote:
> > On Thu, 2011-05-26 at 11:53 +0300, Pekka Enberg wrote:
> >> On Thu, 2011-05-26 at 09:42 +0300, Sasha Levin wrote:
> >> > Allow specifying an optional parameter when registering an
> >>
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 12:02 PM, Sasha Levin wrote:
> On Thu, 2011-05-26 at 11:53 +0300, Pekka Enberg wrote:
>> On Thu, 2011-05-26 at 09:42 +0300, Sasha Levin wrote:
>> > Allow specifying an optional parameter when registering an
>> > ioport range. The callback functions provided by the registeri
On Thu, 2011-05-26 at 11:53 +0300, Pekka Enberg wrote:
> On Thu, 2011-05-26 at 09:42 +0300, Sasha Levin wrote:
> > Allow specifying an optional parameter when registering an
> > ioport range. The callback functions provided by the registering
> > module will be called with the same parameter.
> >
On Thu, 2011-05-26 at 09:42 +0300, Sasha Levin wrote:
> Allow specifying an optional parameter when registering an
> ioport range. The callback functions provided by the registering
> module will be called with the same parameter.
>
> This may be used to keep context during callbacks on IO operati
On Wed, May 25, 2011 at 03:49:40PM -0700, Shirley Ma wrote:
> On Fri, 2011-05-20 at 02:41 +0300, Michael S. Tsirkin wrote:
> > So the requirements are
> > - data must be released in a timely fashion (e.g. unlike virtio-net
> > tun or bridge)
> The current patch doesn't enable tun zero-copy. tun w
On 05/20/2011 08:12 PM, Jan Kiszka wrote:
This is a rather short round as the next and final one cannot be split
up very well.
We start with three code cleanup patches, then work towards using
upstream kvm_cpu_exec, and finally rework the core's PIO access
management used for device assignment.
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:19:03AM +0300, Avi Kivity wrote:
> On 05/25/2011 05:09 AM, Takuya Yoshikawa wrote:
> >From: Takuya Yoshikawa
> >
> >During tracing the emulator, we noticed that init_emulate_ctxt()
> >sometimes took a bit longer time than we expected.
> >
> >This patch is for mitigating t
On 05/25/2011 05:09 AM, Takuya Yoshikawa wrote:
From: Takuya Yoshikawa
During tracing the emulator, we noticed that init_emulate_ctxt()
sometimes took a bit longer time than we expected.
This patch is for mitigating the problem by some degree.
By looking into the function, we soon notice that
Am 25.05.2011 22:34, schrieb Josh Durgin:
> The new format is
> rbd:pool/image[@snapshot][:option1=value1[:option2=value2...]]
> Each option is used to configure rados, and may be any Ceph option, or "conf".
> The "conf" option specifies a Ceph configuration file to read.
>
> This allows rbd volu
Am 25.05.2011 22:34, schrieb Josh Durgin:
> Signed-off-by: Josh Durgin
> ---
> block/rbd.c | 15 +++
> 1 files changed, 15 insertions(+), 0 deletions(-)
>
> diff --git a/block/rbd.c b/block/rbd.c
> index a44d160..b95b1eb 100644
> --- a/block/rbd.c
> +++ b/block/rbd.c
> @@ -688,6 +6
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
101 - 120 of 120 matches
Mail list logo
