Re: [Xen-devel] XSA 154 and ISA region (640K -> 1MB) WB cache instead of UC

[One Thousand Gnomes]

On Thu, 18 Aug 2016 05:12:54 -0600
"Jan Beulich"  wrote:

> >>> On 18.08.16 at 12:16,  wrote:  
> > On 18/08/16 11:06, Jan Beulich wrote:  
> > On 17.08.16 at 22:32,  wrote:  
> >>>Looking at the kernel it assumes that WB is ok for 640KB->1MB.
> >>>The comment says:
> >>>" /* Low ISA region is always mapped WB in page table. No need to 
> >>> track   
> > *"  
> >> As per above it's not clear to me what this comment is backed by.  
> > 
> > This states what is in the pagetables.  Not the combined result with MTRRs.
> > 
> > WB in the pagetables and WC/UB in the MTRRs is a legal combination which
> > functions correctly.  
> 
> True, but then again - haven't I been told multiple times that Linux
> nowadays prefers to run without using MTRRs?

The BIOS sets up the fixed MTRR registers for the 640K-1MB window. Those
are separate to the variable range MTRR registers used for main memory
with specific mappings for segments A000 to BFFF then C000-C7FF /
C800-CFFF / etc up to .

Alan

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [RFC v3 00/13] linux: generalize sections, ranges and linker tables

[One Thousand Gnomes]

> table development go under copyleft-next, Rusty recently asked for code
> to go in prior to the license tag being added denoting this license as
> GPL-compatible [3] -- I had noted in the patch submission which annotated
> copyleft-next's compatibility to GPLv2 that copyleft-next is the license
> of choice for ongoing kernel development on my end [4]. If this is
> objectionable I'm happy to change it to GPLv2 however I'd like a reason
> provided as I've gone through all possible channels to ensure this is kosher,
> including vetting by 3 attorneys now, 2 at SUSE.

You don't need a new tag, you can use "GPL" or "GPL and additional
rights". In fact you don't want any other tag because when combined with
the kernel it is GPLv2 anyway because the only way the two are fully
compatible is for the kernel community to license the derived work under
the GPL.

The second reason you must use the GPL or GPL with additional tag is
clause 8. We don't want anyone to create a module under your licence,
claim it is "open source" then fifteen years later release the module in
binary only form still with a tag saying "copyleft-next" which we treat
as GPL compatible. It's the same reason we don't have a BSD tag but use
"GPL with additional rights" to stop abuse of the module tags.

However you need to clarify the licence first I think. Linux is GPLv2,
your document only allows use of GPL with "GPL" works - not GPL v2 works ?

As PS: btw your licence is kind of weird. I can combine it with GPL work,
make it GPL therefore, and then use the GPL rights to remove the bits I
added thereby meaning I have your exact original work under the GPL. Not
sure how it's intended to work ?

It would also be good if someone clarified whether 6 and 7 are intended
to combine so you can take contributed patches and put them in your own
proprietary version. As a non-lawyer the intent is not clear at all.

Alan

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 0/6] Support calling functions on dedicated physical cpu

[One Thousand Gnomes]

On Fri, 11 Mar 2016 13:25:14 +0100
Peter Zijlstra  wrote:

> On Fri, Mar 11, 2016 at 12:59:28PM +0100, Juergen Gross wrote:
> > Some hardware (e.g. Dell Studio laptops) require special functions to
> > be called on physical cpu 0 in order to avoid occasional hangs. When
> > running as dom0 under Xen this could be achieved only via special boot
> > parameters (vcpu pinning) limiting the hypervisor in it's scheduling
> > decisions.  
> 
> So instead of telling Dell to get their act together and fix their damn
> firmware, we're going to add the most horrid gunk to the kernel? How
> does that make sense?

It's been normal forever. The convention with a lot of older BIOS crap
was always that it should be called on the boot CPU (APM. PnPBIOS etc).

It's a stretch pre-EFI to even call it a "bug"

Alan

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 1/3] xen-netback: fix license ident used in MODULE_LICENSE

[One Thousand Gnomes]

> The fact what include/linux/license.h:license_is_gpl_compatible includes
> "Dual MIT/GPL" as an option seems to suggest that it is enough of a thing
> to be validly used as the contents of a MODULE_LICENSE() thing.

Yes. The MIT licence most definitely exists, and people know what it
means.

Also nobody should be changing the licence on anything unless they have
the written permission of all rights holders on record, so it's best to
leave it be 8)

Alan

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel