|
|
|
|
|
|
|
|
|
|
xen-devel
[Xen-devel] Re: [PATCH 01/04] Kexec / Kdump: Generic code
To: |
"Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx> |
Subject: |
[Xen-devel] Re: [PATCH 01/04] Kexec / Kdump: Generic code |
From: |
"Magnus Damm" <magnus.damm@xxxxxxxxx> |
Date: |
Tue, 17 Oct 2006 15:36:34 +0900 |
Cc: |
Ian Pratt <m+Ian.Pratt@xxxxxxxxxxxx>, Kazuo Moriwaka <moriwaka@xxxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, Akio Takebe <takebe_akio@xxxxxxxxxxxxxx>, Isaku Yamahata <yamahata@xxxxxxxxxxxxx>, Magnus Damm <magnus@xxxxxxxxxxxxx>, Horms <horms@xxxxxxxxxxxx> |
Delivery-date: |
Mon, 16 Oct 2006 23:36:59 -0700 |
Domainkey-signature: |
a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ldxFgch8pBKzet/WaLCGT6GW20KRsGYl7d9zvvH9zD9X4a0ZTqOA5yYggbfqO0A7gYZCB1u5UV3j9xIo2LUIyNYc3gHld/BF+EpR9aY4mquzeG7cIL6+FY9118zzYwZhP7i6p7gyHloktrUTxPHaBNgdqJodyQv3CI9TdnkOfuA= |
Envelope-to: |
www-data@xxxxxxxxxxxxxxxxxx |
In-reply-to: |
<C1594FC1.2934%Keir.Fraser@xxxxxxxxxxxx> |
List-help: |
<mailto:xen-devel-request@lists.xensource.com?subject=help> |
List-id: |
Xen developer discussion <xen-devel.lists.xensource.com> |
List-post: |
<mailto:xen-devel@lists.xensource.com> |
List-subscribe: |
<http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> |
List-unsubscribe: |
<http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> |
References: |
<20061016083324.7611.3312.sendpatchset@localhost> <C1594FC1.2934%Keir.Fraser@xxxxxxxxxxxx> |
Sender: |
xen-devel-bounces@xxxxxxxxxxxxxxxxxxx |
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
|
|
|
|
|