behavioral change due to new elf code

behavioral change due to new elf code

[Jan Beulich]

Is it intentional that with the new ELF code notes unknown to the hypervisor
lead to dom0 being unbootable? The old code simply queried for those notes
mattering at all for dom0, but din't care about any others...

Thanks, Jan

Re: behavioral change due to new elf code

[Gerd Hoffmann]

[-- Attachment #1: Type: text/plain, Size: 280 bytes --]

Jan Beulich wrote:
> Is it intentional that with the new ELF code notes unknown to the hypervisor
> lead to dom0 being unbootable? The old code simply queried for those notes
> mattering at all for dom0, but din't care about any others...

No.

-- 
Gerd Hoffmann <kraxel@suse.de>

[-- Attachment #2: fix --]
[-- Type: text/plain, Size: 467 bytes --]

--- xen/common/libelf/libelf-dominfo.c~	2007-02-08 09:39:33.000000000 +0100
+++ xen/common/libelf/libelf-dominfo.c	2007-02-09 14:14:58.000000000 +0100
@@ -107,9 +107,9 @@
     if ((type >= sizeof(note_desc) / sizeof(note_desc[0])) ||
 	(NULL == note_desc[type].name))
     {
-	elf_err(elf, "%s: unknown xen elf note (0x%x)\n",
+	elf_msg(elf, "%s: unknown xen elf note (0x%x)\n",
 		__FUNCTION__, type);
-	return -1;
+	return 0;
     }
 
     if (note_desc[type].str)

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: behavioral change due to new elf code

[Jan Beulich]

But wouldn't that change behavior for domU-s then in an undesirable way? I
would have thought that at best this should be conditional upon __XEN__.

Even better, I would think, would be to split the note namespace to
distinguish
- general required notes
- general optional notes
- dom0 required notes
- etc.

Jan

>>> Gerd Hoffmann <kraxel@suse.de> 09.02.07 14:17 >>>
Jan Beulich wrote:
> Is it intentional that with the new ELF code notes unknown to the hypervisor
> lead to dom0 being unbootable? The old code simply queried for those notes
> mattering at all for dom0, but din't care about any others...

No.

-- 
Gerd Hoffmann <kraxel@suse.de>

Re: behavioral change due to new elf code

[Gerd Hoffmann]

Jan Beulich wrote:
> But wouldn't that change behavior for domU-s then in an undesirable way?

Why?  dom0 and domU should have the same behavior ...

> Even better, I would think, would be to split the note namespace to
> distinguish
> - general required notes
> - general optional notes
> - dom0 required notes

Point being?  I'm not aware of any dom0-required note.  And I don't
think splitting into required and optional is useful, especially as this
is arch-dependent ...

cheers,
  Gerd

-- 
Gerd Hoffmann <kraxel@suse.de>

Re: behavioral change due to new elf code

[Jan Beulich]

>>> Gerd Hoffmann <kraxel@suse.de> 09.02.07 15:00 >>>
>Jan Beulich wrote:
>> But wouldn't that change behavior for domU-s then in an undesirable way?
>
>Why?  dom0 and domU should have the same behavior ...

I didn't check how the old domU-related tools code behaved here, I just
assumed the new code was based more on the old tools code than the
hypervisor one, and hence old behavior might have been the one I had
just seen.
Regardless of that, the function shouldn't return here, but rather
continue the loop.

>> Even better, I would think, would be to split the note namespace to
>> distinguish
>> - general required notes
>> - general optional notes
>> - dom0 required notes
>
>Point being?  I'm not aware of any dom0-required note.  And I don't
>think splitting into required and optional is useful, especially as this
>is arch-dependent ...

To e.g. catch notes the presence of which is necessary (i.e. a newer
hypervisor will misbehave in its absence), but ignore such that only
provide hints in certain directions.

At present I also don't know of any dom0 required note, yet if any
splitting is done, then all possible (i.e. foreseeable) groups should be
allowed for. As you say, the list should also include an arch-specific
range.

Jan

Re: behavioral change due to new elf code

[Gerd Hoffmann]

Jan Beulich wrote:
>>>> Gerd Hoffmann <kraxel@suse.de> 09.02.07 15:00 >>>
>> Jan Beulich wrote:
>>> But wouldn't that change behavior for domU-s then in an undesirable way?
>> Why?  dom0 and domU should have the same behavior ...
> 
> I didn't check how the old domU-related tools code behaved here, I just
> assumed the new code was based more on the old tools code than the
> hypervisor one, and hence old behavior might have been the one I had
> just seen.

Old domU builder was cut&pasted from old dom0 builder three years ago ;)

> Regardless of that, the function shouldn't return here, but rather
> continue the loop.

No, the function parses just one note, the loop is one level up.

>>> Even better, I would think, would be to split the note namespace to
>>> distinguish
>>> - general required notes
>>> - general optional notes
>>> - dom0 required notes
>> Point being?  I'm not aware of any dom0-required note.  And I don't
>> think splitting into required and optional is useful, especially as this
>> is arch-dependent ...
> 
> To e.g. catch notes the presence of which is necessary (i.e. a newer
> hypervisor will misbehave in its absence), but ignore such that only
> provide hints in certain directions.

I don't think there are such notes.  domU's are supposed to be
compatible in both directions.

> At present I also don't know of any dom0 required note, yet if any
> splitting is done, then all possible (i.e. foreseeable) groups should be
> allowed for. As you say, the list should also include an arch-specific
> range.

Shouldn't happen.  Starting with 3.0.3 dom0 kernel has no hypervisor
dependencies any more, only xen kernel and tools must match version-wise.

cheers,
  Gerd

-- 
Gerd Hoffmann <kraxel@suse.de>