[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] [PATCH v2 22/23] x86: make Xen early boot code relocatab
Re: [Xen-devel] [PATCH v2 22/23] x86: make Xen early boot code relocatable
Tue, 01 Sep 2015 00:59:45 -0600
>>> On 31.08.15 at 21:49, <address@hidden> wrote:
> On Fri, Aug 28, 2015 at 08:16:05AM -0600, Jan Beulich wrote:
>> >>> On 28.08.15 at 15:42, <address@hidden> wrote:
>> > Now that said - do you have suggestions on how to make this work
>> > with GRUB in the picture?
>> ... I don't think I'm the one to make suggestions on how to make
>> things work with grub in the picture when I continue to be of the
>> opinion that it shouldn't have been brought into the picture in the
>> first place.
> Could you be more specific what is wrong with this patch or at least last
> hunk which you reviewed? What is real technical reason that it could not
> be accepted? If idea is wrong in general please tell me where and why.
> Otherwise I am not able to work out other better solution.
The patch may not be wrong technically (and I never said so), it is
just that the way you carry things out is too intrusive for my taste.
Since Andrew is happy with the change in principle, I think I wouldn't
veto it going in with his R-b.
> By the way, once I have put 3 (IIRC) proposals for this problem on the
> Even we discussed this issue in Shanghai. You and Andrew approved more or
> less this one. So, I am a bit disappointed that you withdraw your approval
> (yes, partial but still the approval) at this stage with just vague
I've never approved of anything here. At the hackathon we've only
hashed out possible options.
>> But for the purely technical (patch) aspect: Anything (e.g.
>> macroization such that at least some sym_phys() uses can remain
>> untouched) allowing to limit the impact of said patch on the source
>> code (thus helping review and perhaps also long term
>> maintainability) would be a step towards talking me into
>> withdrawing my objection.
> Ditto. This is too vague. So, I will be very grateful if you review this
> patch until the end or at least tell me what (if you add why it will be
> nice) exactly should be fixed.
How is this to vague? I gave a possible direction (macroization) as
well as the criteria (less impact on existing code; to be slightly more
precise I'd specifically like to see most of the open coded %fs: uses
Again - if Andrew thinks this is the right thing to do, I'll defer to him
for reviewing these final few patches of the series, since as said
before to me this is a workaround for a misguided design, and as
such I'm not willing to accept as intrusive a patch as this one is. (And
no, I don't really buy his argument of Xen boot code needing to be
relocatable anyway - the legacy boot path doesn't really need to
fear there not being free memory right above 1Mb. At least I have
seen no proof of there being any system [supporting legacy boot]
where Xen can't boot that way. And even if there was, it would
still need to be determined whether this is legitimately so, or again
due to poorly written firmware.)
|[Prev in Thread]
||[Next in Thread]|
- Re: [Xen-devel] [PATCH v2 22/23] x86: make Xen early boot code relocatable,
Jan Beulich <=