Re: [PATCH 2/2] cpu: intel, amd: mask cleared cpuid features

[Vladimir Davydov]

On 07/25/2012 03:17 PM, Andre Przywara wrote:
> On 07/25/2012 01:02 PM, Vladimir Davydov wrote:
> > On 07/25/2012 02:58 PM, Andre Przywara wrote:
> > > On 07/25/2012 12:31 PM, Vladimir Davydov wrote:
> > > > On 07/24/2012 04:44 PM, Alan Cox wrote:
> > > > > > This approach does not need any kernel support (except for the
> > > > > > /proc/cpuinfo filtering). Does this address the issues you have?
> > > > > You can do the /proc/cpuinfo filtering in user space too
> > > > How?
> > > I wanted to write the same reply yesterday, but followed the hint in
> > > Alan's previous mail:
> > > # mount --bind /dev/shm/faked_cpuinfo /somepath/proc/cpuinfo
> > >
> > > I checked it, it works even with chroots and is not visible from within.
> > If CPUs go online/offline?
> Do you support CPU offlining from within the guest? My OpenVZ guest only
> has /sys/class and nothing else, so I cannot offline any CPU.
>
> So you setup a "hand-crafted" cpuinfo for the guest and this should stay
> valid for the whole guest's runtime, right?
>
> And since it is a dumped file, "host" CPU off/onlining does not affect
> it. Or do you want to propagate this to the guests?

A guest cannot have more CPUs than the host in container virtualization 
(at least in OpenVZ). So yes, we will have to propagate.

Anyway, we've agreed that you were right and are going to think about 
/proc/cpuinfo virtualization.

Thank you for your time and feedback.

> (Sorry, but my thinking is more Xen/KVM oriented, where guests can only
> do most things if they are explicitly allowed to do it and separation
> between guests and host is much stricter).
>
>
> Regards,
> Andre.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/