[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v4 07/17] x86/hvm: add length to mmio check op



> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> Sent: 24 June 2015 14:25
> To: Paul Durrant
> Cc: Andrew Cooper; xen-devel@xxxxxxxxxxxxxxxxxxxx; Keir (Xen.org)
> Subject: RE: [Xen-devel] [PATCH v4 07/17] x86/hvm: add length to mmio
> check op
> 
> >>> On 24.06.15 at 15:14, <Paul.Durrant@xxxxxxxxxx> wrote:
> >> From: xen-devel-bounces@xxxxxxxxxxxxx [mailto:xen-devel-
> >> bounces@xxxxxxxxxxxxx] On Behalf Of Jan Beulich
> >> Sent: 24 June 2015 14:08
> >> >>> On 24.06.15 at 13:24, <paul.durrant@xxxxxxxxxx> wrote:
> >> > --- a/xen/include/asm-x86/hvm/io.h
> >> > +++ b/xen/include/asm-x86/hvm/io.h
> >> > @@ -35,7 +35,9 @@ typedef int (*hvm_mmio_write_t)(struct vcpu *v,
> >> >                                  unsigned long addr,
> >> >                                  unsigned long length,
> >> >                                  unsigned long val);
> >> > -typedef int (*hvm_mmio_check_t)(struct vcpu *v, unsigned long
> addr);
> >> > +typedef int (*hvm_mmio_check_t)(struct vcpu *v,
> >> > +                                unsigned long addr,
> >> > +                                unsigned long length);
> >>
> >> I don't think this really needs to be "long"?
> >>
> >
> > For consistency with the mmio read and write function types I went with
> > 'long'. Is there any harm in that?
> 
> Generally generates worse code (due to the need for the REX64
> prefix on all involved instructions). Perhaps the other ones don't
> need sizes/lengths passed as longs either?
> 

I'm happy to do it that way round if you don't mind the extra diffs. I'll do it 
as a separate patch just before this one, to ease review.

  Paul

> Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.