Re: [Xen-devel] [stage1-xen PATCH v1 04/10] build/fedora: Add `run` and `components/*` scripts

[Rajiv Ranganath <rajiv.ranganath@xxxxxxxxxxx>]

On Tue, Sep 12 2017 at 01:36:04 AM, Stefano Stabellini <sstabellini@xxxxxxxxxx> 
wrote:

[...]

> Fortunately, from the stage1-xen code point of view, there is very
> little difference between PVHv2 and PV. Switching from one to the
> other should be a matter of adding one line to the xl config file.

There is a related use-case here that I think will be important to
users.

In stage1-xen we are packaging a Dom-U kernel. When this kernel crashes
we would want to capture its crash log. Depending on the nature of the
issue, users can then work with their own kernel team, vendor (who is
open to supporting LTS kernels) or upstream.

We might also want to consider supporting two LTS kernel versions on a
rolling basis. Users can then use something like labels [1] or
annotations [2] to toggle the kernel version. That way if their
containers start crashing under a newer Dom-U kernel, they can roll back
to a working kernel.

[...]

>> 3. Multiboot2 - One of the reasons why I documented using EFI is because
>> I could not get multiboot2 to work. It looks like the fix for it is on
>> its way. I anticipate using multiboot2 would be easier for users.
>
> That's for the host right? I didn't have that problem, but maybe because
> I am not using Fedora.

That's correct! I ran into this issue on Fedora host.

[...]

> You have a good point. I think we should be clear about the stability
> of the project and the backward compatibility in the README. We should
> openly say that it is still a "preview" and there is no "support" or
> "compatibility" yet.

Sounds good. I'll update README to reflect this.

> Choosing Xen 4.9 should not be seen as a statement of support. I think
> we should choose the Xen version based only on the technical merits.
>
> In the long term it would be great to support multiple stable versions
> and a development version of Xen. As of now, I think it makes sense to
> have an "add-hoc approach": I would use Xen 4.9 just because it is the
> best choice at the moment. Then, I would update to other versions when
> it makes sense, manually. I don't think that building against a changing
> target ("master") is a good idea, because we might end up stumbling
> across confusing and time-consuming bugs that have nothing to do with
> stage1-xen. However, we could pick a random commit on the Xen tree if
> that's convenient for us, because at this stage there is no support
> really. For example, PVCalls will require some tools changes in Xen.
> Once they are upstream, we'll want to update the Xen version to the
> latest with PVCalls support.
>
> Does it make sense?

Yes, it does. I'll switch to xen-4.9, qemu-2.10 and rkt-1.28 in the next
version of the patchset.

Best,
Rajiv

[1] https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/
[2] 
https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/

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