Keir Fraser [Fri, 8 Aug 2008 13:24:33 +0000 (14:24 +0100)]
linux/x86: fix issues with the assignment of huge amounts of memory
At the same time remove the non-applicable and broken support for the
memmap= command line option.
Also fix the overlap of the modules area with the fixmaps on x86-64.
linux/blkfront: Add "media" file to vbd sysfs directory
Patch adds "media" file to the vbd sysfs directory. File contains a
string, cdrom or disk.
Currently all PV vbd devices are seen by HAL as "disk". Applications
that query HAL info.capabilities attribute to determine a block
devices capabilities fail to see a PV cdrom as having CDROM
capabilities. With the attached patch and a small corresponding patch
to HAL, applications that query HAL for the storage type of the block
device will see it as a disk or a cdrom. Standard Linux IDE devices
use this same mechanism.
lshal of vbd without patches:
info.capabilities = {'storage', 'block'} (string list)
lshal of vbd with patches:
info.capabilities = {'storage', 'block', 'storage.cdrom'} (string
list)
Decouple xen controlled cpufreq path from dom0 CONFIG_CPU_FREQ,
since only processor_perflib.o is required for necessary freq
information parse. This avoids hacks to cpufreq drivers and
fortunately the change is not intrusive.
Signed-off-by Kevin Tian <kevin.tian@intel.com>
Signed-off-by Jinsong Liu <jinsong.liu@inte.com>
Fn arch_acpi_processor_init_extcntl need to be called before any
acpi_processor init stuff, otherwise many special paths for
xen-cpu-idle & xen-cpu-freq can't get executed. So keep
arch_acpi_processor_init_extcntl call in processor_extcntl_init and
call it very early, move other stuff of processor_extcntl_init into a
new fn processor_extcntl_prepare.
x86: restrict keyboard io ports reservation to make ipmi driver
work
On some of our (single board computer) boards (x86) we are using
an IPMI controller that uses I/O ports 0x62 and 0x66 for a KCS
(keyboard controller style) IPMI system interface.
Trying to load the openipmi driver fails, because the ports
(0x62/0x66) are reserved for keyboard. keyboard reserves the full
range 0x60-0x6F while it doesn't need to.
Reserve only ports 0x60 and 0x64 for the legacy PS/2 i8042 keyboad
controller instead of 0x60-0x6F to allow the openipmi driver to
work.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: H. Peter Anvin <hpa@zytor.com> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Markus Armbruster <armbru@redhat.com>
linux/acpi: adjust extcntl's changes to (mostly) common code, mostly for readability
While I realize that it may have been upon my request that all these
#ifdef-s were introduced, I think this went too far here: With the
abstraction in include/acpi/processor.h in place, the code still
guarantees even without all these #ifdef-s that in native kernels
built from the same source the logic will not change.
The one thing that appears a little weak still is the NR_ACPI_CPUS
construct - nothing guarantees that the ACPI IDs are constrained to 8
bits, and hence using an array here doesn't seem either safe or
scalable looking forward. To make the issue explict, the patch adds a
respective BUG_ON().
linux/evtchn: Add memory barriers to evtchn ring accesses.
Xenstore infrequently hangs up on IA64.
Actually the xenstored is still alive but no response from
xenstore-XXX commands.
After tracking down, I've found that evtchn_read() infrequently
returns a wrong evtchn port number and evtchn_write() never
unmask the exact port.
Signed-off-by: Kouya Shimura <kouya@jp.fujitsu.com>
Yes, updates of the ring_prod and ring_cons are separately protected
by different locks/mutexes, but the data communication between
producer and consumer is lock-free. Barriers are needed.
When resuming from S3, some platforms may clear SCI_EN bit in
PM1_CONTROL register and cause SCI interrupt disabled in Domain0. This
patch fixes this issue as Linux-2.6.19 does.
A recent need for our kernel was to be able to run on 3.0.2-based Xen,
and this pointed out that while the fallback code in hypercall.h deals
with most of the cases, the multicalls used in the context switch code
didn't have appropriate fallback mechanisms. Short of breaking up the
multicall or checking individual operation status, the easier method
to fix this seemed to be to simply use the old hypercalls when
CONFIG_XEN_COMPAT_030002_AND_LATER is defined.
This patch fixes the following compilation error.
scsiback_interface_exit() is called by scsiback_init().
remove __exit.
> LD .tmp_vmlinux1
>`scsiback_interface_exit' referenced in section `.init.text' of
>drivers/built-in.o: defined in discarded section `.exit.text' of
>drivers/built-in.o
- Sanity check for REPORT_LUN emulation.
- Return "residual" value from backend to frontend. The residual value
is used to represent difference between request size the frontend
requested and size backend actually responded.
Signed-off-by: Tomonari Horikoshi <t.horikoshi@jp.fujitsu.com> Signed-off-by: Jun Kamada <kama@jp.fujitsu.com>
The extended blkfront code would allocate the wrong device for xvdc,
since we had changed mi->type along the way. To fix this, have a
separate "major_info" entry for the extended block devices, even
though it isn't technically a different major number. With these
fixes in place, the above sequence works for me.
Signed-off-by: Chris Lalancette <clalance@redhat.com>
Add "white list" control to SCSI command emulation. Current setting
allows following mandatory and safe commands.
TEST UNIT READY
REZERO UNIT
REQUEST SENSE
FORMAT UNIT
READ BLOCK LIMITS
READ(06)
WRITE(06)
WRITE FILEMARKS
SPACE
INQUIRY
ERASE
MODE SENSE(06)
SEND DIAGNOSTIC
READ CAPACITY
READ(10)
WRITE(10)
REPORT LUN
Signed-off-by: Tomonari Horikoshi <t.horikoshi@jp.fujitsu.com> Signed-off-by: Jun Kamada <kama@jp.fujitsu.com>
Keir Fraser [Mon, 30 Jun 2008 15:14:04 +0000 (16:14 +0100)]
x86/64: Fix syscall return code when ptrace or audit is active
Fix the return value from the 64-bit kernel when you call with a bad
system call number with tracing enabled (for either ptrace or audit).
What should happen is that the user process gets a -ENOSYS return
call from the syscall; what actually happens (only in the 64-bit
kernel) is that you get back the system call number. The 32-bit
kernel does not suffer from this bug.
Signed-off-by: Chris Lalancette <clalance@redhat.com>
Keir Fraser [Fri, 27 Jun 2008 15:07:56 +0000 (16:07 +0100)]
blktap: bugfix and support extended device numbers
This simple patch puts two fixes into the blktap backend. The first
is a change of busid from an unsigned short to a u32 so we can
accommodate the new expanded format (which doesn't fit into 16-bits).
The second is a minor fix to signal_tapdisk(); while developing, if
the tools happen to set up the tapfds wrong, you can get into a
situation where the idx passed to signal_tapdisk() is NULL, causing a
kernel OOPS. The fix for signal_tapdisk() just returns if the idx is
negative, preventing the crash.
Signed-off-by: Chris Lalancette <clalance@redhat.com>
Keir Fraser [Fri, 27 Jun 2008 15:06:41 +0000 (16:06 +0100)]
blkfront: Fix blkfront to accept expanded devices (v2)
This patch implements the new extended allocation scheme on the
blkfront end. Note that there is a new xenbus node for the extended
stuff, called "virtual-device-ext". On a blkfront_probe(), if nothing
is found in "virtual-device", then it will go looking in
"virtual-device-ext". This prevents old guest kernels from potentially
mis-interpreting data in "virtual-device" (and then subsequently
crashing).
Changes since v1:
- Restructure the changes to remove duplicate code
- Add some error checks on the xlvbd_add() path. Note that I did not
do full error checking on the existing numbering scheme (i.e. the
202<<8 for xvd, 3<<8 for IDE, 8<<8 for SCSI, etc). The reason I
didn't do full checking is that it is perfectly legal to do something
like: "xm block-attach pv tap:aio:/disk 0xCB10 w" (which is major
203), which then maps onto the 202 xvd device. It's not particularly
nice behavior, in my opinion, but changing it now would change this
behavior. So the only check I added was to make sure we weren't above
the extended device range (1<<28).
Signed-off-by: Chris Lalancette <clalance@redhat.com>
Keir Fraser [Fri, 27 Jun 2008 13:46:41 +0000 (14:46 +0100)]
Fix CMOS time error after writing /proc/acpi/alarm
When writing /proc/acpi/alarm in adjust mode, e.g.
echo "+0000-00-00 00:00:15" >/proc/acpi/alarm
The "century" field should be read and added to "year" field before
writing, otherwise the CMOS time will go back to 2000 years ago, e.g.
# cat /proc/acpi/alarm
0008-06-21 11:38:46=20
Then the system time may be reset to the date of manufacture after
rebooting. This patch fixes this issue.
Ian Campbell [Tue, 24 Jun 2008 20:02:47 +0000 (21:02 +0100)]
privcmd: avoid deadlock due to copy_(to|from)_user with mmap_sem write lock held.
Accessing user memory with the write lock held is illegal, if the pages are
non-present then we will deadlock against the lock in do_page_fault. Avoid this
for IOCTL_PRIVCMD_MMAP and MMAPBATCH by copying the entire input data structure
into the kernel before taking the lock.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Keir Fraser [Fri, 20 Jun 2008 16:43:16 +0000 (17:43 +0100)]
AMD PowerNow! in the Hypervisor
This patch set moves support for AMD's PowerNow! technology from
dom0 into the hypervisor, now that there is support for
transferring ACPI data to the hypervisor. It will only work for
AMD processors that support the architectural P-state driver,
such as 3rd generation Opterons, Phenoms, and Turion Ultras.
This patch guarantees that the previous dom0 PowerNow!
controller will not instantiate if the hypervisor PowerNow!
controller is enabled.
Signed-off-by: Mark Langsdorf <mark.langsdorf@amd.com> Acked-by: Conny Seidel <conny.seidel@amd.com>
Keir Fraser [Mon, 16 Jun 2008 09:36:24 +0000 (10:36 +0100)]
x86: Back port from latest Linux kernel to enable C2/C3 entry via MWAIT
Current xen-linux (2.6.18) not include support for Cx MWAIT entry
method. Back port from latest Linux kernel (already there since
2.6.23). Without this patch, _CST method couldn't get C states with
FFH address space type.
Keir Fraser [Fri, 13 Jun 2008 08:54:50 +0000 (09:54 +0100)]
extract vmcoreinfo from /proc/vmcore for Xen
- get the machine address of the vmcoreinfo area of xen
- expose the machine address and the size of the vmcoreinfo area
via /sys/hypervisor/vmcoreinfo so that the kexec-tools looks them.
Ian Campbell [Tue, 10 Jun 2008 07:50:39 +0000 (08:50 +0100)]
Use GFP_NOIO to avoid allocations which swap on resume.
377:e8b49cfbdac0 and 497:fdb998e79aba added __GFP_HIGH to allocations
which could cause swap on resume. __GFP_HIGH actually only makes such
allocations less likely (by allowing access to the emergency pools of
memory).
Ian Campbell [Tue, 10 Jun 2008 07:35:59 +0000 (08:35 +0100)]
Export additional data from watch events through to userspace xenbus clients.
This functionality is already available when connecting directly to
xenstore in dom0 or from within the kernel, but the xenbus dev which
is used from userspace to access xenbus over the kernel's xenbus
connection lacks this functionality -- it will only pass the path
where the watch fired and the token.
xend uses this functionality already when firing the @releaseDomain
watch from xenstored and passing the uuid of the domain which was
released.
The diff changes the implementation of split to return an additional
entry marking the end of the final string, in case the final string is
not null terminated. None of the callers to split are affected by this
change. The other change in the diff is to change the watch firing code
to return the additional data.
Signed-off-by: Christian Limpach <christian.limpach@citrix.com> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Keir Fraser [Fri, 30 May 2008 18:08:50 +0000 (19:08 +0100)]
xen: Set blocking timeout to 1/2 jiffy later than we want. This avoids
repeated early wakeup just before the jiffy tick, causing us to
effectively spin rather than sleep.
Keir Fraser [Thu, 15 May 2008 08:42:27 +0000 (09:42 +0100)]
balloon: Fix minimum_target() check to work when built as a module.
From: Jan Beulich <jbeulich@novell.com> Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
Keir Fraser [Wed, 14 May 2008 12:53:06 +0000 (13:53 +0100)]
acpi: Fix a bug related to parse named objects
This patch is pulled from native linux, and is needed in our patchset
to make it run, otherwise will parse wrong _PSD info.
Fixed a problem with the Package operator where all named
references were created as object references and left otherwise
unresolved. According to the ACPI specification, a Package can
only contain Data Objects or references to control methods. The
implication is that named references to Data Objects (Integer,
Buffer, String, Package, BufferField, Field) should be resolved
immediately upon package creation. This is the approach taken
with this change. References to all other named objects (Methods,
Devices, Scopes, etc.) are all now properly created as reference
objects.
Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
Keir Fraser [Wed, 14 May 2008 12:51:50 +0000 (13:51 +0100)]
xen: Basic framework of getting and notifying Px info
Setup basic framework for ACPI Px parse, get basic Px info,
transfer Px info to hypervisor through platform op hypercall.
Add external control for ACPI parse, add notify mechanism for
dynamic Px event (like ppc).
Signed-off-by: Tian Kevin <kevin.tian@intel.com> Signed-off-by: Liu Jinsong <jinsong.liu@intel.com>
Keir Fraser [Tue, 13 May 2008 08:32:00 +0000 (09:32 +0100)]
xen: Cleanup of MSI code
A few cleanups of the MSI code. There were a couple of race
conditions in the use of msi_dev_head which this patch fixes. Use
list_empty rather than list_empty_careful since pirq_list_head is only
ever accessed under pirq_list_lock. I removed some unused variables.
Signed-off-by: Neil Turton <nturton@solarflare.com>
Isaku Yamahata [Tue, 13 May 2008 01:42:09 +0000 (10:42 +0900)]
[IA64] implement xencomm routine for HVMOP_track_dirty_vram.
This patches implement xencomm routine for HVMOP_track_dirty_vram hypercall.
Without this, using vfb results in annoying messages in dom0 as
> xencomm_privcmd_hvm_op: unknown HVMOP 6
xen/ia64 doesn't implement the hypercall at this moment so that
it simply returns -ENOSYS. So the xencomm routine returns -ENOSYS
directly without issuing the useless hypercall.
projects / xenclient / kernel.git / log