[lkml]   [2006]   [Mar]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [Xen-devel] [RFC PATCH 14/35] subarch modify CPU capabilities
    Chris Wright wrote:
    > +void __devinit machine_specific_modify_cpu_capabilities(struct cpuinfo_x86 *c)
    > +{
    > + clear_bit(X86_FEATURE_VME, c->x86_capability);
    > + clear_bit(X86_FEATURE_DE, c->x86_capability);
    > + clear_bit(X86_FEATURE_PSE, c->x86_capability);
    > + clear_bit(X86_FEATURE_PGE, c->x86_capability);
    > + clear_bit(X86_FEATURE_SEP, c->x86_capability);
    > + clear_bit(X86_FEATURE_MWAIT, c->x86_capability);
    > + if (!(xen_start_info->flags & SIF_PRIVILEGED))
    > + clear_bit(X86_FEATURE_MTRR, c->x86_capability);
    > + c->hlt_works_ok = 0;

    That's pretty heinous. Suppose Xen decides to start supporting any of
    these features. Now, you need to change all of the Xen modified kernels
    to remove pieces of this.

    You've effectively introduced completely arbitrary, but most
    importantly, static constraints into Linux based on what features Xen
    currently supports. This is not productive on either end.

    This is the entire point of the VMI interface. You can arbitrarily
    enable and disable these features in a hidden layer, call it VMI, call
    it Xen-bridge, call it hypercall page, whatever. Using this layer, you
    can automatically abstract away exactly this type of nasty, deliberately
    deprecating extraneous code. We use this feature exactly to strip away
    these bits, completely hidden from the guest, by "trapping" the CPUID
    instruction in the VMI layer. The VMI interface as it stands today is
    unimportant - it has and will continue to change to accommodate Xen.
    But the principles of it are important for maintainability, flexibility,
    and future compatibility. One of these principles is to avoid
    unbalanced changes like this to the guest kernel.

    And we certainly support VME, DE, PSE, PGE, and SEP features, and really
    would not like them disabled unconditionally in a virtual environment.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2006-03-22 09:39    [W:0.021 / U:10.248 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site