On Tue, Jun 16, 2015 at 06:17:14PM +0100, Will Deacon wrote:
> On Mon, Jun 15, 2015 at 12:49:45PM +0100, Andreas Herrmann wrote:
> > W/o dedicated endianess it's impossible to find reliably a match
> > e.g. in kernel/virt/kvm/eventfd.c ioeventfd_in_range.
>
> Hmm, but shouldn't this be the endianness of the guest, rather than just
> forcing things to little-endian?
With my patch and following adaption to
ioeventfd_in_range (in virt/kvm/eventfd.c):
switch (len) {
case 1:
_val = *(u8 *)val;
break;
case 2:
_val = le16_to_cpu(*(u16 *)val);
break;
case 4:
_val = le32_to_cpu(*(u32 *)val);
break;
case 8:
_val = le64_to_cpu(*(u64 *)val);
break;
default:
return false;
}
return _val == le64_to_cpu(p->datamatch) ? true : false;
datamatch is properly evaluated on either endianess.
The current code in ioeventfd_in_range looks fragile to me (for big
endian systems) and didn't work with kvmtool:
switch (len) {
case 1:
_val = *(u8 *)val;
break;
case 2:
_val = *(u16 *)val;
break;
case 4:
_val = *(u32 *)val;
break;
case 8:
_val = *(u64 *)val;
break;
default:
return false;
}
return _val == p->datamatch ? true : false;
But now I see, w/o a correponding kernel change the patch shouldn't
be merged.
Andreas
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
