[Xen-devel] Re: [PATCH 01/04] Kexec / Kdump: Generic code

["Magnus Damm" <magnus.damm@xxxxxxxxx>]

Hi Keir, thanks for the comments!

On 10/16/06, Keir Fraser <Keir.Fraser@xxxxxxxxxxxx> wrote:
> Some comments:
>
> No need for IO-APIC work on the guest side of the kexec interfaces (e.g.,
> don't call disable_IO_APIC()).
Ok, good idea.

> What's the second argument to the hypercall for? There's no clear
> explanation of what the TYPE parameter means, and currently it is only ever
> specified as TYPE_CRASH. So what's TYPE_DEFAULT for? And do we really need
> to avoid copy_to/from_guest so it can't be folded into the structural
> parameter?
>
> The comment attached to every use of xchg() is dubious. We don't specify
> warn_unused_result on that function so there's no good reason for the
> compiler to complain about discarding the result. If it's a reproducible
> problem it needs investigating. We shouldn't work around a broken compiler.
>
> Attribution at the top of many files: 'Horms' is a bit vague. Could we have
> a full name? A company name? An email address?
I agree with all your observations. The purpose of this release was to
quickly release something that supports VT hardware and applies to a
working x86_64 changeset.

Now when the release is done I'd like to focus on fixing the issues
you've brought up together with scratching some itches that I've
listed below:

- Headers and comments cleanup.
- Merge load and unload hypercall - make unload same as load NULL.
- Investigate xen/common/kexec.c locking - clean up the code.
- Merge crash and smp code - it may be possible to share cpu stopping code.
- Try to move the ELF notes out of the hypervisor - this is intrusive
and complicated.

My plan is to spend the week fixing these things and post a new
release some time next week.

Thanks!

/ magnus

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