Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1625332 > unrolled thread
| Started by | Matt Fleming <matt@codeblueprint.co.uk> |
|---|---|
| First post | 2017-04-18 15:50 +0200 |
| Last post | 2017-04-19 21:40 +0200 |
| Articles | 4 — 2 participants |
Back to article view | Back to linux.kernel
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: [PATCH] arm64: xen: Implement EFI reset_system callback Matt Fleming <matt@codeblueprint.co.uk> - 2017-04-18 15:50 +0200
Re: [PATCH] arm64: xen: Implement EFI reset_system callback Matt Fleming <matt@codeblueprint.co.uk> - 2017-04-19 21:40 +0200
Re: [PATCH] arm64: xen: Implement EFI reset_system callback Daniel Kiper <daniel.kiper@oracle.com> - 2017-04-19 21:50 +0200
Re: [PATCH] arm64: xen: Implement EFI reset_system callback Daniel Kiper <daniel.kiper@oracle.com> - 2017-04-19 21:40 +0200
| From | Matt Fleming <matt@codeblueprint.co.uk> |
|---|---|
| Date | 2017-04-18 15:50 +0200 |
| Subject | Re: [PATCH] arm64: xen: Implement EFI reset_system callback |
| Message-ID | <txBG2-6LC-5@gated-at.bofh.it> |
On Thu, 06 Apr, at 04:55:11PM, Mark Rutland wrote: > > Please, let's keep the Xen knowledge constrained to the Xen EFI wrapper, > rather than spreading it further. > > IMO, given reset_system is a *mandatory* function, the Xen wrapper > should provide an implementation. > > I don't see why you can't implement a wrapper that calls the usual Xen > poweroff/reset functions. I realise I'm making a sweeping generalisation, but adding EFI_PARAVIRT is almost always the wrong thing to do. I'd much prefer to see Mark's idea implemented.
[toc] | [next] | [standalone]
| From | Matt Fleming <matt@codeblueprint.co.uk> |
|---|---|
| Date | 2017-04-19 21:40 +0200 |
| Message-ID | <ty3Ci-7ov-7@gated-at.bofh.it> |
| In reply to | #1625332 |
On Wed, 19 Apr, at 09:29:06PM, Daniel Kiper wrote: > On Tue, Apr 18, 2017 at 02:46:50PM +0100, Matt Fleming wrote: > > On Thu, 06 Apr, at 04:55:11PM, Mark Rutland wrote: > > > > > > Please, let's keep the Xen knowledge constrained to the Xen EFI wrapper, > > > rather than spreading it further. > > > > > > IMO, given reset_system is a *mandatory* function, the Xen wrapper > > > should provide an implementation. > > > > > > I don't see why you can't implement a wrapper that calls the usual Xen > > > poweroff/reset functions. > > > > I realise I'm making a sweeping generalisation, but adding > > EFI_PARAVIRT is almost always the wrong thing to do. > > Why? Because it makes paravirt a special case, and there's usually very little reason to make it special in the EFI code. Special-casing means more branches, more code paths, a bigger testing matrix and more complex code. EFI_PARAVIRT does have its uses, like for those scenarios where we don't have a table of function pointers that can be overidden for paravirt. But we do have such a table for ->reset_system().
[toc] | [prev] | [next] | [standalone]
| From | Daniel Kiper <daniel.kiper@oracle.com> |
|---|---|
| Date | 2017-04-19 21:50 +0200 |
| Message-ID | <ty3LY-7rV-23@gated-at.bofh.it> |
| In reply to | #1626729 |
On Wed, Apr 19, 2017 at 08:37:38PM +0100, Matt Fleming wrote: > On Wed, 19 Apr, at 09:29:06PM, Daniel Kiper wrote: > > On Tue, Apr 18, 2017 at 02:46:50PM +0100, Matt Fleming wrote: > > > On Thu, 06 Apr, at 04:55:11PM, Mark Rutland wrote: > > > > > > > > Please, let's keep the Xen knowledge constrained to the Xen EFI wrapper, > > > > rather than spreading it further. > > > > > > > > IMO, given reset_system is a *mandatory* function, the Xen wrapper > > > > should provide an implementation. > > > > > > > > I don't see why you can't implement a wrapper that calls the usual Xen > > > > poweroff/reset functions. > > > > > > I realise I'm making a sweeping generalisation, but adding > > > EFI_PARAVIRT is almost always the wrong thing to do. > > > > Why? > > Because it makes paravirt a special case, and there's usually very > little reason to make it special in the EFI code. Special-casing means > more branches, more code paths, a bigger testing matrix and more > complex code. > > EFI_PARAVIRT does have its uses, like for those scenarios where we > don't have a table of function pointers that can be overidden for > paravirt. > > But we do have such a table for ->reset_system(). This is more or less what I expected. Thanks a lot for explanation. Daniel
[toc] | [prev] | [next] | [standalone]
| From | Daniel Kiper <daniel.kiper@oracle.com> |
|---|---|
| Date | 2017-04-19 21:40 +0200 |
| Message-ID | <ty3Ci-7ov-9@gated-at.bofh.it> |
| In reply to | #1625332 |
On Tue, Apr 18, 2017 at 02:46:50PM +0100, Matt Fleming wrote: > On Thu, 06 Apr, at 04:55:11PM, Mark Rutland wrote: > > > > Please, let's keep the Xen knowledge constrained to the Xen EFI wrapper, > > rather than spreading it further. > > > > IMO, given reset_system is a *mandatory* function, the Xen wrapper > > should provide an implementation. > > > > I don't see why you can't implement a wrapper that calls the usual Xen > > poweroff/reset functions. > > I realise I'm making a sweeping generalisation, but adding > EFI_PARAVIRT is almost always the wrong thing to do. Why? > I'd much prefer to see Mark's idea implemented. If you wish I do not object. Daniel
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web