Re: [Xen-devel] [PATCH for-4.7 1/4] xen: remove usage of ENODATA error code

[Roger Pau Monne]

On Mon, May 02, 2016 at 03:06:21AM -0600, Jan Beulich wrote:
> >>> On 02.05.16 at 10:55,  wrote:
> > On Mon, May 02, 2016 at 12:22:35AM -0600, Jan Beulich wrote:
> >> But how would that help you? Would you mean to monitor future
> >> patches for not again introducing some use of ENODATA that the
> >> tool stack wants to explicitly check for? That would be quite tedious
> >> a task...
> > 
> > Yes it is, but TBH I cannot find any other solution. Adding ENODATA to the 
> > FreeBSD list of error codes seems quite pointless when there's no in-tree 
> > user of it.
> 
> That's a slightly strange way of looking at it: Shouldn't a component
> sitting on top of another component be capable of dealing with all
> output of that lower component, i.e. also any of the error codes that
> one may produce? In which case "no in-tree user" simply becomes a
> non-argument imo... (For comparison, consider a user mode library
> not itself using EINVAL: Would you say it's okay for the library to not
> care about EINVAL coming back from system calls?)

If it wasn't marked as optional and obsolescent I would have added it to 
FreeBSD without questioning, but the fact that the POSIX standard says that 
strictly conforming POSIX applications should not use it makes me wonder 
whether that is the right to do. ENODATA is the only error code that Xen 
uses that's not part of the core POSIX error codes.

IMHO Xen should be a strictly conforming POSIX application, it being a 
kernel that shares a common interface between a wide variety of different 
OSes.

I don't really want to make this any longer than necessary, so I think I'm 
going to try to get ENODATA added to the FreeBSD errno.h header, but I 
wouldn't be surprised if I found some resistance there, and TBH, I don't 
think I will be able to make a good point.

Roger.

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

Re: [Xen-devel] [PATCH for-4.7 1/4] xen: remove usage of ENODATA error code

[Jan Beulich]

>>> On 02.05.16 at 10:55,  wrote:
> On Mon, May 02, 2016 at 12:22:35AM -0600, Jan Beulich wrote:
>> But how would that help you? Would you mean to monitor future
>> patches for not again introducing some use of ENODATA that the
>> tool stack wants to explicitly check for? That would be quite tedious
>> a task...
> 
> Yes it is, but TBH I cannot find any other solution. Adding ENODATA to the 
> FreeBSD list of error codes seems quite pointless when there's no in-tree 
> user of it.

That's a slightly strange way of looking at it: Shouldn't a component
sitting on top of another component be capable of dealing with all
output of that lower component, i.e. also any of the error codes that
one may produce? In which case "no in-tree user" simply becomes a
non-argument imo... (For comparison, consider a user mode library
not itself using EINVAL: Would you say it's okay for the library to not
care about EINVAL coming back from system calls?)

Jan


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

Re: [Xen-devel] [PATCH for-4.7 1/4] xen: remove usage of ENODATA error code

[Roger Pau Monne]

On Mon, May 02, 2016 at 12:22:35AM -0600, Jan Beulich wrote:
> >>> On 29.04.16 at 18:52,  wrote:
> > On Fri, Apr 29, 2016 at 10:42:06AM -0600, Jan Beulich wrote:
> >> >>> On 29.04.16 at 18:34,  wrote:
> >> > On Fri, Apr 29, 2016 at 10:19:41AM -0600, Jan Beulich wrote:
> >> >> >>> On 29.04.16 at 17:06,  wrote:
> >> >> > On Fri, Apr 29, 2016 at 08:44:48AM -0600, Jan Beulich wrote:
> >> >> >> >>> On 29.04.16 at 16:21,  wrote:
> >> >> >> > According to the POSIX standard for error codes [0], ENODATA is 
> >> >> >> > both
> >> >> >> > obsolescent (so it may be removed in the future) and optional.
> >> >> >> 
> >> >> >> It being optional still doesn't preclude us using it.
> >> >> >> 
> >> >> >> > Replace it's
> >> >> >> > usage with ENOENT, which seems like the closest match. Both 
> >> >> >> > FreeBSD and
> >> >> >> > OpenBSD don't have this error code in the native errno.h headers.
> >> >> >> 
> >> >> >> There's no rule saying that Xen's errno set must match any other 
> >> >> >> OS'es.
> >> >> >> That's one of the reasons why we (finally) separated ours.
> >> >> > 
> >> >> > I understand that, but doing this means that then on the toolstack 
> >> >> > side we 
> > 
> >> >> > need to start doing ifdefery in order to match values that are not 
> >> >> > present 
> > 
> >> >> > in the native OS. For example a check was added to libxl against 
> >> >> > XENVER_build_id returning ENODATA, this means that then on libxl I 
> >> >> > would 
> >> >> > have to add a:
> >> >> > 
> >> >> > #ifdef __FreeBSD__
> >> >> > #define ENODATA ENOENT
> >> >> > #endif
> >> >> 
> >> >> You ought to be using XEN_NODATA there anyway.
> >> > 
> >> > No, the privcmd driver is the one that performs the translation from Xen 
> >> > error codes into the OS error code space, so the tools just see error 
> >> > codes 
> > 
> >> > in the OS space. No tools at all use XEN_* error codes directly.
> >> 
> >> That's the supposed behavior for return values, but not for
> >> structure contents. The structures are Xen-specific, so them
> >> holding Xen-specific values is known to the callers, and they
> >> should (be made) cope.
> > 
> > And the usage of ENODATA I'm trying to fix here is from the direct return 
> > of 
> > 
> > an hypercall (__HYPERVISOR_xen_version). I don't mind adding this define, I 
> > just think it would be better to simply replace the usage of ENODATA with 
> > something else, so I could avoid adding more ifdefery to the tools.
> > 
> > Would you be fine with me just adjusting xen_build_id (in 
> > xen/common/version.c) to return ENOENT instead of ENODATA?
> 
> Well, I wouldn't be particularly happy, but I'd also not be as heavily
> opposed as to removing that error code altogether. In general (and
> I probably should have said this in the first reply, despite there
> having been the other more important reason to object) I don't view
> ENOENT as a good replacement for ENODATA. The two really mean
> different things, but in this particular case it would seem a reasonable
> replacement.

Right. But since the privcmd driver does the error code translation I think 
ENOENT is the closest match to ENODATA when doing automatic error 
translation (I'm open to suggestions if someone knows a better replacement 
for it).

> But how would that help you? Would you mean to monitor future
> patches for not again introducing some use of ENODATA that the
> tool stack wants to explicitly check for? That would be quite tedious
> a task...

Yes it is, but TBH I cannot find any other solution. Adding ENODATA to the 
FreeBSD list of error codes seems quite pointless when there's no in-tree 
user of it.

Roger.

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

Re: [Xen-devel] [PATCH for-4.7 1/4] xen: remove usage of ENODATA error code

[Jan Beulich]

>>> On 29.04.16 at 18:52,  wrote:
> On Fri, Apr 29, 2016 at 10:42:06AM -0600, Jan Beulich wrote:
>> >>> On 29.04.16 at 18:34,  wrote:
>> > On Fri, Apr 29, 2016 at 10:19:41AM -0600, Jan Beulich wrote:
>> >> >>> On 29.04.16 at 17:06,  wrote:
>> >> > On Fri, Apr 29, 2016 at 08:44:48AM -0600, Jan Beulich wrote:
>> >> >> >>> On 29.04.16 at 16:21,  wrote:
>> >> >> > According to the POSIX standard for error codes [0], ENODATA is both
>> >> >> > obsolescent (so it may be removed in the future) and optional.
>> >> >> 
>> >> >> It being optional still doesn't preclude us using it.
>> >> >> 
>> >> >> > Replace it's
>> >> >> > usage with ENOENT, which seems like the closest match. Both FreeBSD 
>> >> >> > and
>> >> >> > OpenBSD don't have this error code in the native errno.h headers.
>> >> >> 
>> >> >> There's no rule saying that Xen's errno set must match any other OS'es.
>> >> >> That's one of the reasons why we (finally) separated ours.
>> >> > 
>> >> > I understand that, but doing this means that then on the toolstack side 
>> >> > we 
> 
>> >> > need to start doing ifdefery in order to match values that are not 
>> >> > present 
> 
>> >> > in the native OS. For example a check was added to libxl against 
>> >> > XENVER_build_id returning ENODATA, this means that then on libxl I 
>> >> > would 
>> >> > have to add a:
>> >> > 
>> >> > #ifdef __FreeBSD__
>> >> > #define ENODATA ENOENT
>> >> > #endif
>> >> 
>> >> You ought to be using XEN_NODATA there anyway.
>> > 
>> > No, the privcmd driver is the one that performs the translation from Xen 
>> > error codes into the OS error code space, so the tools just see error 
>> > codes 
> 
>> > in the OS space. No tools at all use XEN_* error codes directly.
>> 
>> That's the supposed behavior for return values, but not for
>> structure contents. The structures are Xen-specific, so them
>> holding Xen-specific values is known to the callers, and they
>> should (be made) cope.
> 
> And the usage of ENODATA I'm trying to fix here is from the direct return of 
> 
> an hypercall (__HYPERVISOR_xen_version). I don't mind adding this define, I 
> just think it would be better to simply replace the usage of ENODATA with 
> something else, so I could avoid adding more ifdefery to the tools.
> 
> Would you be fine with me just adjusting xen_build_id (in 
> xen/common/version.c) to return ENOENT instead of ENODATA?

Well, I wouldn't be particularly happy, but I'd also not be as heavily
opposed as to removing that error code altogether. In general (and
I probably should have said this in the first reply, despite there
having been the other more important reason to object) I don't view
ENOENT as a good replacement for ENODATA. The two really mean
different things, but in this particular case it would seem a reasonable
replacement.

But how would that help you? Would you mean to monitor future
patches for not again introducing some use of ENODATA that the
tool stack wants to explicitly check for? That would be quite tedious
a task...

Jan


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

Re: [Xen-devel] [PATCH for-4.7 1/4] xen: remove usage of ENODATA error code

[Roger Pau Monne]

On Fri, Apr 29, 2016 at 10:42:06AM -0600, Jan Beulich wrote:
> >>> On 29.04.16 at 18:34,  wrote:
> > On Fri, Apr 29, 2016 at 10:19:41AM -0600, Jan Beulich wrote:
> >> >>> On 29.04.16 at 17:06,  wrote:
> >> > On Fri, Apr 29, 2016 at 08:44:48AM -0600, Jan Beulich wrote:
> >> >> >>> On 29.04.16 at 16:21,  wrote:
> >> >> > According to the POSIX standard for error codes [0], ENODATA is both
> >> >> > obsolescent (so it may be removed in the future) and optional.
> >> >> 
> >> >> It being optional still doesn't preclude us using it.
> >> >> 
> >> >> > Replace it's
> >> >> > usage with ENOENT, which seems like the closest match. Both FreeBSD 
> >> >> > and
> >> >> > OpenBSD don't have this error code in the native errno.h headers.
> >> >> 
> >> >> There's no rule saying that Xen's errno set must match any other OS'es.
> >> >> That's one of the reasons why we (finally) separated ours.
> >> > 
> >> > I understand that, but doing this means that then on the toolstack side 
> >> > we 
> >> > need to start doing ifdefery in order to match values that are not 
> >> > present 
> >> > in the native OS. For example a check was added to libxl against 
> >> > XENVER_build_id returning ENODATA, this means that then on libxl I would 
> >> > have to add a:
> >> > 
> >> > #ifdef __FreeBSD__
> >> > #define ENODATA ENOENT
> >> > #endif
> >> 
> >> You ought to be using XEN_NODATA there anyway.
> > 
> > No, the privcmd driver is the one that performs the translation from Xen 
> > error codes into the OS error code space, so the tools just see error codes 
> > in the OS space. No tools at all use XEN_* error codes directly.
> 
> That's the supposed behavior for return values, but not for
> structure contents. The structures are Xen-specific, so them
> holding Xen-specific values is known to the callers, and they
> should (be made) cope.

And the usage of ENODATA I'm trying to fix here is from the direct return of 
an hypercall (__HYPERVISOR_xen_version). I don't mind adding this define, I 
just think it would be better to simply replace the usage of ENODATA with 
something else, so I could avoid adding more ifdefery to the tools.

Would you be fine with me just adjusting xen_build_id (in 
xen/common/version.c) to return ENOENT instead of ENODATA?

Roger.

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

Re: [Xen-devel] [PATCH for-4.7 1/4] xen: remove usage of ENODATA error code

[Jan Beulich]

>>> On 29.04.16 at 18:34,  wrote:
> On Fri, Apr 29, 2016 at 10:19:41AM -0600, Jan Beulich wrote:
>> >>> On 29.04.16 at 17:06,  wrote:
>> > On Fri, Apr 29, 2016 at 08:44:48AM -0600, Jan Beulich wrote:
>> >> >>> On 29.04.16 at 16:21,  wrote:
>> >> > According to the POSIX standard for error codes [0], ENODATA is both
>> >> > obsolescent (so it may be removed in the future) and optional.
>> >> 
>> >> It being optional still doesn't preclude us using it.
>> >> 
>> >> > Replace it's
>> >> > usage with ENOENT, which seems like the closest match. Both FreeBSD and
>> >> > OpenBSD don't have this error code in the native errno.h headers.
>> >> 
>> >> There's no rule saying that Xen's errno set must match any other OS'es.
>> >> That's one of the reasons why we (finally) separated ours.
>> > 
>> > I understand that, but doing this means that then on the toolstack side we 
>> > need to start doing ifdefery in order to match values that are not present 
>> > in the native OS. For example a check was added to libxl against 
>> > XENVER_build_id returning ENODATA, this means that then on libxl I would 
>> > have to add a:
>> > 
>> > #ifdef __FreeBSD__
>> > #define ENODATA ENOENT
>> > #endif
>> 
>> You ought to be using XEN_NODATA there anyway.
> 
> No, the privcmd driver is the one that performs the translation from Xen 
> error codes into the OS error code space, so the tools just see error codes 
> in the OS space. No tools at all use XEN_* error codes directly.

That's the supposed behavior for return values, but not for
structure contents. The structures are Xen-specific, so them
holding Xen-specific values is known to the callers, and they
should (be made) cope.

> This is because privcmd does the translation, and because it would be 
> impossible to differentiate if the errno returned by the ioctl belongs to 
> Xen space or to the OS space.

Exactly - I agree for the return values.

Jan


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

Re: [Xen-devel] [PATCH for-4.7 1/4] xen: remove usage of ENODATA error code

[Roger Pau Monne]

On Fri, Apr 29, 2016 at 10:19:41AM -0600, Jan Beulich wrote:
> >>> On 29.04.16 at 17:06,  wrote:
> > On Fri, Apr 29, 2016 at 08:44:48AM -0600, Jan Beulich wrote:
> >> >>> On 29.04.16 at 16:21,  wrote:
> >> > According to the POSIX standard for error codes [0], ENODATA is both
> >> > obsolescent (so it may be removed in the future) and optional.
> >> 
> >> It being optional still doesn't preclude us using it.
> >> 
> >> > Replace it's
> >> > usage with ENOENT, which seems like the closest match. Both FreeBSD and
> >> > OpenBSD don't have this error code in the native errno.h headers.
> >> 
> >> There's no rule saying that Xen's errno set must match any other OS'es.
> >> That's one of the reasons why we (finally) separated ours.
> > 
> > I understand that, but doing this means that then on the toolstack side we 
> > need to start doing ifdefery in order to match values that are not present 
> > in the native OS. For example a check was added to libxl against 
> > XENVER_build_id returning ENODATA, this means that then on libxl I would 
> > have to add a:
> > 
> > #ifdef __FreeBSD__
> > #define ENODATA ENOENT
> > #endif
> 
> You ought to be using XEN_NODATA there anyway.

No, the privcmd driver is the one that performs the translation from Xen 
error codes into the OS error code space, so the tools just see error codes 
in the OS space. No tools at all use XEN_* error codes directly.

This is because privcmd does the translation, and because it would be 
impossible to differentiate if the errno returned by the ioctl belongs to 
Xen space or to the OS space.

Roger.

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

Re: [Xen-devel] [PATCH for-4.7 1/4] xen: remove usage of ENODATA error code

[Jan Beulich]

>>> On 29.04.16 at 17:06,  wrote:
> On Fri, Apr 29, 2016 at 08:44:48AM -0600, Jan Beulich wrote:
>> >>> On 29.04.16 at 16:21,  wrote:
>> > According to the POSIX standard for error codes [0], ENODATA is both
>> > obsolescent (so it may be removed in the future) and optional.
>> 
>> It being optional still doesn't preclude us using it.
>> 
>> > Replace it's
>> > usage with ENOENT, which seems like the closest match. Both FreeBSD and
>> > OpenBSD don't have this error code in the native errno.h headers.
>> 
>> There's no rule saying that Xen's errno set must match any other OS'es.
>> That's one of the reasons why we (finally) separated ours.
> 
> I understand that, but doing this means that then on the toolstack side we 
> need to start doing ifdefery in order to match values that are not present 
> in the native OS. For example a check was added to libxl against 
> XENVER_build_id returning ENODATA, this means that then on libxl I would 
> have to add a:
> 
> #ifdef __FreeBSD__
> #define ENODATA ENOENT
> #endif

You ought to be using XEN_NODATA there anyway.

Jan


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

Re: [Xen-devel] [PATCH for-4.7 1/4] xen: remove usage of ENODATA error code

[Roger Pau Monne]

On Fri, Apr 29, 2016 at 08:44:48AM -0600, Jan Beulich wrote:
> >>> On 29.04.16 at 16:21,  wrote:
> > According to the POSIX standard for error codes [0], ENODATA is both
> > obsolescent (so it may be removed in the future) and optional.
> 
> It being optional still doesn't preclude us using it.
> 
> > Replace it's
> > usage with ENOENT, which seems like the closest match. Both FreeBSD and
> > OpenBSD don't have this error code in the native errno.h headers.
> 
> There's no rule saying that Xen's errno set must match any other OS'es.
> That's one of the reasons why we (finally) separated ours.

I understand that, but doing this means that then on the toolstack side we 
need to start doing ifdefery in order to match values that are not present 
in the native OS. For example a check was added to libxl against 
XENVER_build_id returning ENODATA, this means that then on libxl I would 
have to add a:

#ifdef __FreeBSD__
#define ENODATA ENOENT
#endif

I think this adds more complexity, when we could solve it by only using 
error codes that are part of the POSIX standard, and that are present on all 
UNIX systems.

> > --- a/xen/include/public/errno.h
> > +++ b/xen/include/public/errno.h
> > @@ -93,7 +93,6 @@ XEN_ERRNO(ENAMETOOLONG,   36) /* File name too long */
> >  XEN_ERRNO(ENOLCK,  37) /* No record locks available */
> >  XEN_ERRNO(ENOTEMPTY,   39) /* Directory not empty */
> >  XEN_ERRNO(ENOSYS,  38) /* Function not implemented */
> > -XEN_ERRNO(ENODATA, 61) /* No data available */
> >  XEN_ERRNO(ETIME,   62) /* Timer expired */
> >  XEN_ERRNO(EBADMSG, 74) /* Not a data message */
> >  XEN_ERRNO(EOVERFLOW,   75) /* Value too large for defined data 
> > type */
> 
> And in absolutely no case can you unconditionally remove _anything_
> from other than the tools-only parts of the public interface.

Right, the problem with leaving it there is that I'm quite certain it's 
going to be used again as a return value from a hypercall.

Roger.

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

Re: [Xen-devel] [PATCH for-4.7 1/4] xen: remove usage of ENODATA error code

[Jan Beulich]

>>> On 29.04.16 at 16:21,  wrote:
> According to the POSIX standard for error codes [0], ENODATA is both
> obsolescent (so it may be removed in the future) and optional.

It being optional still doesn't preclude us using it.

> Replace it's
> usage with ENOENT, which seems like the closest match. Both FreeBSD and
> OpenBSD don't have this error code in the native errno.h headers.

There's no rule saying that Xen's errno set must match any other OS'es.
That's one of the reasons why we (finally) separated ours.

> --- a/xen/include/public/errno.h
> +++ b/xen/include/public/errno.h
> @@ -93,7 +93,6 @@ XEN_ERRNO(ENAMETOOLONG, 36) /* File name too long */
>  XEN_ERRNO(ENOLCK,37) /* No record locks available */
>  XEN_ERRNO(ENOTEMPTY, 39) /* Directory not empty */
>  XEN_ERRNO(ENOSYS,38) /* Function not implemented */
> -XEN_ERRNO(ENODATA,   61) /* No data available */
>  XEN_ERRNO(ETIME, 62) /* Timer expired */
>  XEN_ERRNO(EBADMSG,   74) /* Not a data message */
>  XEN_ERRNO(EOVERFLOW, 75) /* Value too large for defined data type */

And in absolutely no case can you unconditionally remove _anything_
from other than the tools-only parts of the public interface.

Jan


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

[Xen-devel] [PATCH for-4.7 1/4] xen: remove usage of ENODATA error code

[Roger Pau Monne]

According to the POSIX standard for error codes [0], ENODATA is both
obsolescent (so it may be removed in the future) and optional. Replace it's
usage with ENOENT, which seems like the closest match. Both FreeBSD and
OpenBSD don't have this error code in the native errno.h headers.

[0] http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/errno.h.html

Signed-off-by: Roger Pau Monné 
---
Cc: Ian Jackson 
Cc: Wei Liu 
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Tim Deegan 
Cc: George Dunlap 
Cc: Stefano Stabellini 
Cc: Julien Grall 
---
 tools/libxl/libxl.c |  2 +-
 xen/arch/x86/hvm/hvm.c  |  8 
 xen/arch/x86/microcode_amd.c|  4 ++--
 xen/arch/x86/mm/shadow/common.c |  2 +-
 xen/common/device_tree.c|  2 +-
 xen/common/domctl.c |  2 +-
 xen/common/version.c| 10 +-
 xen/drivers/acpi/pmstat.c   |  2 +-
 xen/drivers/acpi/tables.c   |  2 +-
 xen/include/public/errno.h  |  1 -
 10 files changed, 17 insertions(+), 18 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index c39d745..0dcc06f 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -5361,7 +5361,7 @@ static const int libxl__xc_version_wrap(libxl__gc *gc, 
libxl_version_info *info,
 r = xc_version(CTX->xch, XENVER_build_id, build);
 switch (r) {
 case -EPERM:
-case -ENODATA:
+case -ENOENT:
 case 0:
 info->build_id = libxl__strdup(NOGC, "");
 break;
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 8cb6e9e..980b4a1 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -1274,14 +1274,14 @@ static int hvm_load_cpu_xsave_states(struct domain *d, 
hvm_domain_context_t *h)
 printk(XENLOG_G_WARNING
"HVM%d.%d restore: not enough data left to read xsave 
descriptor\n",
d->domain_id, vcpuid);
-return -ENODATA;
+return -ENOENT;
 }
 if ( desc->length + sizeof (*desc) > h->size - h->cur)
 {
 printk(XENLOG_G_WARNING
"HVM%d.%d restore: not enough data left to read %u xsave 
bytes\n",
d->domain_id, vcpuid, desc->length);
-return -ENODATA;
+return -ENOENT;
 }
 if ( desc->length < offsetof(struct hvm_hw_cpu_xsave, save_area) +
 XSTATE_AREA_MIN_SIZE )
@@ -1402,14 +1402,14 @@ static int hvm_load_cpu_msrs(struct domain *d, 
hvm_domain_context_t *h)
 printk(XENLOG_G_WARNING
"HVM%d.%d restore: not enough data left to read MSR 
descriptor\n",
d->domain_id, vcpuid);
-return -ENODATA;
+return -ENOENT;
 }
 if ( desc->length + sizeof (*desc) > h->size - h->cur)
 {
 printk(XENLOG_G_WARNING
"HVM%d.%d restore: not enough data left to read %u MSR bytes\n",
d->domain_id, vcpuid, desc->length);
-return -ENODATA;
+return -ENOENT;
 }
 if ( desc->length < HVM_CPU_MSR_SIZE(1) )
 {
diff --git a/xen/arch/x86/microcode_amd.c b/xen/arch/x86/microcode_amd.c
index a61c926..ca1a026 100644
--- a/xen/arch/x86/microcode_amd.c
+++ b/xen/arch/x86/microcode_amd.c
@@ -342,7 +342,7 @@ static int container_fast_forward(const void *data, size_t 
size_left, size_t *of
 *offset += size;
 
 if ( !size_left )
-return -ENODATA;
+return -ENOENT;
 }
 
 return 0;
@@ -454,7 +454,7 @@ static int cpu_request_microcode(unsigned int cpu, const 
void *buf,
 break;
 
 error = container_fast_forward(buf, bufsize - offset, );
-if ( error == -ENODATA )
+if ( error == -ENOENT )
 {
 ASSERT(offset == bufsize);
 break;
diff --git a/xen/arch/x86/mm/shadow/common.c b/xen/arch/x86/mm/shadow/common.c
index 4e06c13..6ce76e2 100644
--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/common.c
@@ -3729,7 +3729,7 @@ int shadow_track_dirty_vram(struct domain *d,
 dirty_vram->last_dirty = NOW();
 
 /* Tell the caller that this time we could not track dirty bits. */
-rc = -ENODATA;
+rc = -ENOENT;
 }
 else if (dirty_vram->last_dirty == -1)
 /* still completely clean, just copy our empty bitmap */
diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
index 0ed86a7..9d1896e 100644
--- a/xen/common/device_tree.c
+++ b/xen/common/device_tree.c
@@ -204,7 +204,7 @@ int dt_property_read_string(const struct dt_device_node *np,
 if ( !pp )
 return -EINVAL;
 if ( !pp->value )
-return -ENODATA;
+return -ENOENT;
 if ( strnlen(pp->value, pp->length) >= pp->length )
 return -EILSEQ;
 
diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index e43904e..d07114a