Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 15 3月, 2012 2 次提交
    • K
      xen/acpi-processor: C and P-state driver that uploads said data to hypervisor. · 59a56802
      由 Konrad Rzeszutek Wilk 提交于 
      This driver solves three problems:
 1). Parse and upload ACPI0007 (or PROCESSOR_TYPE) information to the
     hypervisor - aka P-states (cpufreq data).
 2). Upload the the Cx state information (cpuidle data).
 3). Inhibit CPU frequency scaling drivers from loading.

The reason for wanting to solve 1) and 2) is such that the Xen hypervisor
is the only one that knows the CPU usage of different guests and can
make the proper decision of when to put CPUs and packages in proper states.
Unfortunately the hypervisor has no support to parse ACPI DSDT tables, hence it
needs help from the initial domain to provide this information. The reason
for 3) is that we do not want the initial domain to change P-states while the
hypervisor is doing it as well - it causes rather some funny cases of P-states
transitions.

For this to work, the driver parses the Power Management data and uploads said
information to the Xen hypervisor. It also calls acpi_processor_notify_smm()
to inhibit the other CPU frequency scaling drivers from being loaded.

Everything revolves around the 'struct acpi_processor' structure which
gets updated during the bootup cycle in different stages. At the startup, when
the ACPI parser starts, the C-state information is processed (processor_idle)
and saved in said structure as 'power' element. Later on, the CPU frequency
scaling driver (powernow-k8 or acpi_cpufreq), would call the the
acpi_processor_* (processor_perflib functions) to parse P-states information
and populate in the said structure the 'performance' element.

Since we do not want the CPU frequency scaling drivers from loading
we have to call the acpi_processor_* functions to parse the P-states and
call "acpi_processor_notify_smm" to stop them from loading.

There is also one oddity in this driver which is that under Xen, the
physical online CPU count can be different from the virtual online CPU count.
Meaning that the macros 'for_[online|possible]_cpu' would process only
up to virtual online CPU count. We on the other hand want to process
the full amount of physical CPUs. For that, the driver checks if the ACPI IDs
count is different from the APIC ID count - which can happen if the user
choose to use dom0_max_vcpu argument. In such a case a backup of the PM
structure is used and uploaded to the hypervisor.

[v1-v2: Initial RFC implementations that were posted]
[v3: Changed the name to passthru suggested by Pasi Kärkkäinen <pasik@iki.fi>]
[v4: Added vCPU != pCPU support - aka dom0_max_vcpus support]
[v5: Cleaned up the driver, fix bug under Athlon XP]
[v6: Changed the driver to a CPU frequency governor]
[v7: Jan Beulich <jbeulich@suse.com> suggestion to make it a cpufreq scaling driver
     made me rework it as driver that inhibits cpufreq scaling driver]
[v8: Per Jan's review comments, fixed up the driver]
[v9: Allow to continue even if acpi_processor_preregister_perf.. fails]
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      59a56802
    • J
      xen: constify all instances of "struct attribute_group" · ead1d014
      由 Jan Beulich 提交于 
      The functions these get passed to have been taking pointers to const
since at least 2.6.16.
Signed-off-by: NJan Beulich <jbeulich@suse.com>
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      ead1d014
  3. 14 3月, 2012 2 次提交
  5. 27 2月, 2012 1 次提交
  7. 13 1月, 2012 1 次提交
  9. 09 1月, 2012 1 次提交
  11. 08 1月, 2012 2 次提交
  13. 05 1月, 2012 4 次提交
    • I
      xen/xenbus: don't reimplement kvasprintf via a fixed size buffer · a800651e
      由 Ian Campbell 提交于 
      Signed-off-by: NIan Campbell <ian.campbell@citrix.com>
Cc: Haogang Chen <haogangchen@gmail.com>
Acked-by: NJan Beulich <JBeulich@suse.com>
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      a800651e
    • I
      xenbus: maximum buffer size is XENSTORE_PAYLOAD_MAX · 50bf7379
      由 Ian Campbell 提交于 
      Use this now that it is defined even though it happens to be == PAGE_SIZE.

The code which takes requests from userspace already validates against the size
of this buffer so no further checks are required to ensure that userspace
requests comply with the protocol in this respect.
Signed-off-by: NIan Campbell <ian.campbell@citrix.com>
Cc: Haogang Chen <haogangchen@gmail.com>
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      50bf7379
    • I
      xen/xenbus: Reject replies with payload > XENSTORE_PAYLOAD_MAX. · 9e7860ce
      由 Ian Campbell 提交于 
      Haogang Chen found out that:

 There is a potential integer overflow in process_msg() that could result
 in cross-domain attack.

 	body = kmalloc(msg->hdr.len + 1, GFP_NOIO | __GFP_HIGH);

 When a malicious guest passes 0xffffffff in msg->hdr.len, the subsequent
 call to xb_read() would write to a zero-length buffer.

 The other end of this connection is always the xenstore backend daemon
 so there is no guest (malicious or otherwise) which can do this. The
 xenstore daemon is a trusted component in the system.

 However this seem like a reasonable robustness improvement so we should
 have it.

And Ian when read the API docs found that:
        The payload length (len field of the header) is limited to 4096
        (XENSTORE_PAYLOAD_MAX) in both directions.  If a client exceeds the
        limit, its xenstored connection will be immediately killed by
        xenstored, which is usually catastrophic from the client's point of
        view.  Clients (particularly domains, which cannot just reconnect)
        should avoid this.

so this patch checks against that instead.

This also avoids a potential integer overflow pointed out by Haogang Chen.
Signed-off-by: NIan Campbell <ian.campbell@citrix.com>
Cc: Haogang Chen <haogangchen@gmail.com>
CC: stable@kernel.org
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      9e7860ce
    • J
      Xen: consolidate and simplify struct xenbus_driver instantiation · 73db144b
      由 Jan Beulich 提交于 
      The 'name', 'owner', and 'mod_name' members are redundant with the
identically named fields in the 'driver' sub-structure. Rather than
switching each instance to specify these fields explicitly, introduce
a macro to simplify this.

Eliminate further redundancy by allowing the drvname argument to
DEFINE_XENBUS_DRIVER() to be blank (in which case the first entry from
the ID table will be used for .driver.name).

Also eliminate the questionable xenbus_register_{back,front}end()
wrappers - their sole remaining purpose was the checking of the
'owner' field, proper setting of which shouldn't be an issue anymore
when the macro gets used.

v2: Restore DRV_NAME for the driver name in xen-pciback.
Signed-off-by: NJan Beulich <jbeulich@suse.com>
Cc: Jens Axboe <axboe@kernel.dk>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: David S. Miller <davem@davemloft.net>
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      73db144b
  15. 04 1月, 2012 1 次提交
    • J
      xen-gntalloc: introduce missing kfree · 2e163414
      由 Julia Lawall 提交于 
      Error handling code following a kmalloc should free the allocated data.
Out_unlock is used on both success and failure, so free vm_priv before
jumping to that label.

A simplified version of the semantic match that finds the problem is as
follows: (http://coccinelle.lip6.fr)

// <smpl>
@r exists@
local idexpression x;
statement S;
identifier f1;
position p1,p2;
expression *ptr != NULL;
@@

x@p1 = \(kmalloc\|kzalloc\|kcalloc\)(...);
...
if (x == NULL) S
<... when != x
     when != if (...) { <+...x...+> }
x->f1
...>
(
 return \(0\|<+...x...+>\|ptr\);
|
 return@p2 ...;
)

@script:python@
p1 << r.p1;
p2 << r.p2;
@@

print "* file: %s kmalloc %s return %s" % (p1[0].file,p1[0].line,p2[0].line)
// </smpl>
Signed-off-by: NJulia Lawall <julia@diku.dk>
[v1: Altered the description a bit]
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      2e163414
  17. 22 12月, 2011 1 次提交
  19. 21 12月, 2011 3 次提交
  21. 20 12月, 2011 1 次提交
  23. 19 12月, 2011 1 次提交
  25. 17 12月, 2011 11 次提交
  27. 16 12月, 2011 2 次提交
  29. 15 12月, 2011 1 次提交
  31. 06 12月, 2011 1 次提交
  33. 22 11月, 2011 5 次提交