Thread (38 messages) flat view 38 messages, 9 authors, 2012-12-11
STALE4989d

Revision rfc of 7 in this series.

Revisions (7)
  1. rfc [diff vs current]
  2. rfc [diff vs current]
  3. rfc [diff vs current]
  4. rfc current
  5. rfc [diff vs current]
  6. rfc [diff vs current]
  7. v2 [diff vs current]

[RFC PATCH 0/2] Add support for a fake, para-virtualised machine

From: Will Deacon <hidden>
Date: 2012-12-04 18:14:46

On Tue, Dec 04, 2012 at 06:02:13PM +0000, Nicolas Pitre wrote:
On Tue, 4 Dec 2012, Will Deacon wrote:
quoted
Hi Nicolas,

On Tue, Dec 04, 2012 at 05:00:07PM +0000, Nicolas Pitre wrote:
quoted
on the topic of a para-virtualised machine, I think that it should 
simply implement the PSCI calls to bring up CPUs _without_ any holding 
pen nor spinning tables.  You issue the appropriate PSCI call with the 
physical address for secondary_startup() as argument and you're done.  
The host intercepts that call and free a new CPU instance in response.  
That's all.
I'd be happy to go with this suggestion if it wasn't for one thing:
platforms that do not implement a secure mode. For these platforms, smc will
be an undefined instruction at the exception level where it is executed and
therefore cannot be trapped by the hypervisor.
Really?  I thought the hypervisor could virtualize SMC calls.  Or is 
that considered a security hazard?
If the security extensions aren't implemented, the hypervisor can't trap the
smc instruction.
I don't remember all the PSCI spec details, but I think there was some 
provision for this case i.e. the SMC call could be a HYP call instead.  
And if that's not in the spec, then it probably should be added and 
implemented as if it was.
Well, this depends on the guest taking an undefined instruction exception on
the smc, then deciding to issue an hvc instead and *then* having the
hypervisor somehow translate that into a PSCI invocation. It could work, but
it sounds easy to mess up and relies on the PSCI firmware co-existing with
things like kvm.
quoted
If that situation requires a pen, I see no benefit from having two boot
schemes where one of them would work in every case.
We always have the choice between several schemes in device drivers for 
example, depending on the hardware generation.  Yet we always implement 
the better scheme for the newest hardware for performance reasons, even 
if an older one could work in all cases.
Again, I totally agree when it comes to things like poweroff and hotplug but
for booting I don't think we gain much from having multiple implementations
for a single platform. Hopefully this is moot -- see below.
A holding pen is a rather stupid scheme.  Please let's try to do without 
it if possible.
I've just hacked up Rob's suggestion and it seems to be working, so I'll
post a pen-less v2 tomorrow. The hotplug/reboot code can come later when we
have something host-side that we can use (could be PSCI).

Will
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help