* Jan Kiszka <[email protected]> [2017-07-26 07:28:06 +0200]:

> On 2017-07-25 23:23, Gustavo Lima Chaves wrote:
> > * Jan Kiszka <[email protected]> [2017-07-25 08:11:32 +0200]:
> > 
> > [...]
> > 
> >>>> +// TODO: convert to whitelist
> >>>>  static u8 __attribute__((aligned(PAGE_SIZE))) msr_bitmap[][0x2000/8] = {
> >>>>          [ VMX_MSR_BMP_0000_READ ] = {
> >>>>                  [      0/8 ...  0x7ff/8 ] = 0,
> >>>> -- 
> >>>> 2.1.4
> >>>
> >>> Just to get/align the rationale here on the MRS whitelist. The idea is to 
> >>> expose the whitelist as root/inmate cell configs as well, just like the 
> >>> PIO bitmap right now? If so, I wonder if having all accesses besides 
> >>> those already treated denied and then working with a minimal set to have, 
> >>> say, a bootable Linux inmate as a default config would be acceptable or 
> >>> there is another idea... 
> >>>
> >>
> >> The idea is to first of all try to define a static whitelist of MSRs
> >> that are safe to be handed out to the guest because they do not affect
> >> the integrity of the hypervisor on that same logical CPU, nor do they
> >> have cross-cell effects. If working out that list requires per-board
> >> configurations (maybe not unlikely), we may need to extend the config
> >> format as well.
> > 
> > Thanks! What about MSRs that are the key/point-of-access for other
> > features, like power management (changing P/C-states on x86)? So is it
> > that the power management TODO entry is totally encompassed by the MSR
> > one or am I missing something?
> 
> MSRs are one way to manage power on x86. mwait is another. This area
> requires a careful analysis and waits with some nasty dependencies on us
> (plus horrible ACPI complexity). So, MSRs access control will play a
> role for it but will solve it alone.

Thanks again. I'm still wondering where is the desired direction here:
either to allow/disallow cells to reach knobs controlling
performance/sleep states or to control those at Jailhouse level. Also,
can we skip ACPI altogether where we can (think intel_idle driver "The
intel_idle driver knows the sleep state capabilities of the processor
and ignores ACPI BIOS exported processor sleep states tables.")?

> 
> Jan
> 
> -- 
> Siemens AG, Corporate Technology, CT RDA ITP SES-DE
> Corporate Competence Center Embedded Linux
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Jailhouse" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to [email protected].
> For more options, visit https://groups.google.com/d/optout.

-- 
Gustavo Lima Chaves
Intel - Open Source Technology Center

-- 
You received this message because you are subscribed to the Google Groups 
"Jailhouse" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to