Re: rpms/kernel/devel linux-2.6-net-fix-another-gro-bug.patch, NONE, 1.1 TODO, 1.59, 1.60 kernel.spec, 1.1482, 1.1483
Hi, On Mon, 2009-03-30 at 08:56 +, Mark McLoughlin wrote: +* linux-2.6-net-fix-another-gro-bug.patch: +virtio_net guest-remote GSO busted with 2.6.29 host +https://bugzilla.redhat.com/490266 +Should be in 2.6.29.1 I took the liberty of just going ahead and building this - pretty serious bug with a fairly trivial fix from upstream. Cheers, Mark. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Backport /sys/bus/pci/devices/*/remove_id
Hey,
Any objections to pulling in this patch from the linux-next PCI tree?
It adds a sysfs entry which we need for KVM/libvirt PCI device
assignment. See:
https://bugzilla.redhat.com/487103
TODO entry would be:
* linux-2.6-pci-sysfs-remove-id.patch
In jbarnes linux-next tree for 2.6.30
Needed for KVM PCI device assignment
https://bugzilla.redhat.com/487103
Cheers,
Mark.
From: Chris Wright chr...@sous-sol.org
Date: Tue, 24 Feb 2009 05:52:23 + (-0800)
Subject: PCI: add remove_id sysfs entry
X-Git-Url:
http://git.kernel.org/?p=linux%2Fkernel%2Fgit%2Fjbarnes%2Fpci-2.6.git;a=commitdiff_plain;h=0994375e9614f78657031e04e30019b9cdb62795
PCI: add remove_id sysfs entry
This adds a remove_id sysfs entry to allow users of new_id to later
remove the added dynid. One use case is management tools that want to
dynamically bind/unbind devices to pci-stub driver while devices are
assigned to KVM guests. Rather than having to track which driver was
originally bound to the driver, a mangement tool can simply:
Guest uses device
Signed-off-by: Chris Wright chr...@sous-sol.org
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
diff --git a/Documentation/ABI/testing/sysfs-bus-pci
b/Documentation/ABI/testing/sysfs-bus-pci
index e638e15..3d29793 100644
--- a/Documentation/ABI/testing/sysfs-bus-pci
+++ b/Documentation/ABI/testing/sysfs-bus-pci
@@ -41,6 +41,22 @@ Description:
for the device and attempt to bind to it. For example:
# echo 8086 10f5 /sys/bus/pci/drivers/foo/new_id
+What: /sys/bus/pci/drivers/.../remove_id
+Date: February 2009
+Contact: Chris Wright chr...@sous-sol.org
+Description:
+ Writing a device ID to this file will remove an ID
+ that was dynamically added via the new_id sysfs entry.
+ The format for the device ID is:
+ SVVV SDDD . That is Vendor ID, Device
+ ID, Subsystem Vendor ID, Subsystem Device ID, Class,
+ and Class Mask. The Vendor ID and Device ID fields are
+ required, the rest are optional. After successfully
+ removing an ID, the driver will no longer support the
+ device. This is useful to ensure auto probing won't
+ match the driver to the device. For example:
+ # echo 8086 10f5 /sys/bus/pci/drivers/foo/remove_id
+
What: /sys/bus/pci/devices/.../vpd
Date: February 2008
Contact: Ben Hutchings bhutchi...@solarflare.com
diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c
index 93eac14..87a5ddb 100644
--- a/drivers/pci/pci-driver.c
+++ b/drivers/pci/pci-driver.c
@@ -99,6 +99,52 @@ store_new_id(struct device_driver *driver, const char *buf,
size_t count)
}
static DRIVER_ATTR(new_id, S_IWUSR, NULL, store_new_id);
+/**
+ * store_remove_id - remove a PCI device ID from this driver
+ * @driver: target device driver
+ * @buf: buffer for scanning device ID data
+ * @count: input size
+ *
+ * Removes a dynamic pci device ID to this driver.
+ */
+static ssize_t
+store_remove_id(struct device_driver *driver, const char *buf, size_t count)
+{
+ struct pci_dynid *dynid, *n;
+ struct pci_driver *pdrv = to_pci_driver(driver);
+ __u32 vendor, device, subvendor = PCI_ANY_ID,
+ subdevice = PCI_ANY_ID, class = 0, class_mask = 0;
+ int fields = 0;
+ int retval = -ENODEV;
+
+ fields = sscanf(buf, %x %x %x %x %x %x,
+ vendor, device, subvendor, subdevice,
+ class, class_mask);
+ if (fields 2)
+ return -EINVAL;
+
+ spin_lock(pdrv-dynids.lock);
+ list_for_each_entry_safe(dynid, n, pdrv-dynids.list, node) {
+ struct pci_device_id *id = dynid-id;
+ if ((id-vendor == vendor)
+ (id-device == device)
+ (subvendor == PCI_ANY_ID || id-subvendor == subvendor)
+ (subdevice == PCI_ANY_ID || id-subdevice == subdevice)
+ !((id-class ^ class) class_mask)) {
+ list_del(dynid-node);
+ kfree(dynid);
+ retval = 0;
+ break;
+ }
+ }
+ spin_unlock(pdrv-dynids.lock);
+
+ if (retval)
+ return retval;
+ return count;
+}
+static DRIVER_ATTR(remove_id, S_IWUSR, NULL, store_remove_id);
+
static void
pci_free_dynids(struct pci_driver *drv)
{
@@ -125,6 +171,20 @@ static void pci_remove_newid_file(struct pci_driver *drv)
{
driver_remove_file(drv-driver, driver_attr_new_id);
}
+
+static int
+pci_create_removeid_file(struct pci_driver *drv)
+{
+ int error = 0;
+ if (drv-probe != NULL)
+ error = driver_create_file(drv-driver,driver_attr_remove_id);
+ return error;
+}
+
+static void
Xen Dom0 kernels on branch
Hey, Michael Young has been building some test kernels using Jeremy Fitzhardinge's dom0 patch set. I suggested that he use a private branch in CVS and scratch builds in Koji to make the task a bit easier. I've sponsored his FAS account and I'll help him out with getting started. Can someone approve his commit ACL for devel? https://admin.fedoraproject.org/pkgdb/packages/name/kernel Thanks, Mark. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
[PATCH] Disable kvmclock for non constant tsc cpus.
Hi,
We've a pretty gnarly issue with KVM paravirt clock at the moment.
Basically, cpufreq can kick the TSC out of sync on CPUs and that
confuses the hell out of guests because the current code assumes the
same TSC rate on all CPUs.
The problem manifests itself as completely random hangs and guest
crashes, with the current workaround being to boot the guest with
clocksource=acpi_pm. See:
https://bugzilla.redhat.com/475598
Glommer, Gerd, Juan and Marcelo are all trying to figure out the best
fix, with the latest candidate being:
https://bugzilla.redhat.com/attachment.cgi?id=329812
But we'd really like to add this temporary patch to rawhide (and maybe
F10 if we don't fix it soon) ... any objections?
Thanks,
Mark.
From: Glauber Costa glom...@redhat.com
Date: Thu, 29 Jan 2009 12:39:22 -0500
Subject: [PATCH] Disable kvmclock for non constant tsc cpus.
Currently, this code path is posing us big troubles,
and we won't have a decent patch in time. So, temporarily
disable it.
See:
https://bugzilla.redhat.com/475598
There's a module parameter for the adventurous who want to force
it.
Signed-off-by: Glauber Costa glom...@redhat.com
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
Signed-off-by: Mark McLoughlin mar...@redhat.com
---
arch/x86/kvm/x86.c |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index cc17546..2e22ac9 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -957,6 +957,9 @@ out:
return r;
}
+static int force_kvmclock = 0;
+module_param(force_kvmclock, bool, 0644);
+
int kvm_dev_ioctl_check_extension(long ext)
{
int r;
@@ -967,7 +970,6 @@ int kvm_dev_ioctl_check_extension(long ext)
case KVM_CAP_MMU_SHADOW_CACHE_CONTROL:
case KVM_CAP_SET_TSS_ADDR:
case KVM_CAP_EXT_CPUID:
- case KVM_CAP_CLOCKSOURCE:
case KVM_CAP_PIT:
case KVM_CAP_NOP_IO_DELAY:
case KVM_CAP_MP_STATE:
@@ -992,6 +994,9 @@ int kvm_dev_ioctl_check_extension(long ext)
case KVM_CAP_IOMMU:
r = iommu_found();
break;
+ case KVM_CAP_CLOCKSOURCE:
+ r = force_kvmclock || boot_cpu_has(X86_FEATURE_CONSTANT_TSC);
+ break;
default:
r = 0;
break;
--
1.6.1
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: rpms/kernel/devel linux-2.6-defaults-intel_iommu-off.patch, NONE, 1.1 kernel.spec, 1.1225, 1.1226
Hi Kyle, On Fri, 2009-01-23 at 18:49 +, Kyle McMartin wrote: * Fri Jan 23 2009 Kyle McMartin k...@redhat.com - disable intel_iommu by default (enable with intel_iommu=on) Why so? We're pretty much guaranteed that no-one will enable this ... do we know of specific hardware that this is breaking? One of the major virt features in F11 needs this: https://fedoraproject.org/wiki/Features/KVM_PCI_Device_Assignment Thanks, Mark. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
[patch 1/3] Remove flag args from kernel_variant_posttrans
plain text document attachment
(kernel-variant-posttrans-cleanup-args.patch)
kernel_variant_posttrans only takes a single arg, so don't bother
using flag arguments since they're a bit more confusing.
Note that the macro invocation didn't actually pass it a flag
arg, but it seemed to have access to the calling macros flag args
anyway.
Index: devel/kernel.spec
===
--- devel.orig/kernel.spec 2008-07-30 13:32:44.0 +0100
+++ devel.orig/kernel.spec 2008-07-30 13:32:44.0 +0100
@@ -1527,7 +1527,7 @@ rm -rf $RPM_BUILD_ROOT
#
# This macro defines a %%post script for a kernel*-devel package.
-# %%kernel_devel_post subpackage
+# %%kernel_devel_post [subpackage]
#
%define kernel_devel_post() \
%{expand:%%post %{?1:%{1}-}devel}\
@@ -1545,12 +1545,12 @@ fi\
%{nil}
# This macro defines a %%posttrans script for a kernel package.
-# %%kernel_variant_posttrans [-v subpackage] [-s s -r r]
+# %%kernel_variant_posttrans [subpackage]
# More text can follow to go at the end of this variant's %%post.
#
-%define kernel_variant_posttrans(s:r:v:) \
-%{expand:%%posttrans %{?-v*}}\
-/sbin/new-kernel-pkg --package kernel%{?-v:-%{-v*}} --rpmposttrans
%{KVERREL}%{?-v:.%{-v*}} || exit $?\
+%define kernel_variant_posttrans() \
+%{expand:%%posttrans %{?1}}\
+/sbin/new-kernel-pkg --package kernel%{?1:-%{1}} --rpmposttrans
%{KVERREL}%{?1:.%{1}} || exit $?\
%{nil}
#
--
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
[patch 2/3] Add kernel_%{variant}_replaces macros
plain text document attachment
(kernel-variant-post-kill-replace-arg.patch)
The -r arg is redundant because we already now the variant name
so we can use kernel%{?-v:-%{-v*}} instead. So, rename the -s arg
to -r and drop the existing meaning of -r.
Index: devel/kernel.spec
===
--- devel.orig/kernel.spec 2008-07-30 14:15:15.0 +0100
+++ devel.orig/kernel.spec 2008-07-30 14:15:15.0 +0100
@@ -1555,17 +1555,17 @@ fi\
#
# This macro defines a %%post script for a kernel package and its devel
package.
-# %%kernel_variant_post [-v subpackage] [-s s -r r]
+# %%kernel_variant_post [-v subpackage] [-r replace]
# More text can follow to go at the end of this variant's %%post.
#
-%define kernel_variant_post(s:r:v:) \
+%define kernel_variant_post(v:r:) \
%{expand:%%kernel_devel_post %{?-v*}}\
%{expand:%%kernel_variant_posttrans %{?-v*}}\
%{expand:%%post %{?-v*}}\
-%{-s:\
+%{-r:\
if [ `uname -i` == x86_64 -o `uname -i` == i386 ] \
[ -f /etc/sysconfig/kernel ]; then\
- /bin/sed -i -e 's/^DEFAULTKERNEL=%{-s*}$/DEFAULTKERNEL=%{-r*}/'
/etc/sysconfig/kernel || exit $?\
+ /bin/sed -i -e
's/^DEFAULTKERNEL=%{-r*}$/DEFAULTKERNEL=kernel%{?-v:-%{-v*}}/'
/etc/sysconfig/kernel || exit $?\
fi}\
/sbin/new-kernel-pkg --package kernel%{?-v:-%{-v*}} --mkinitrd --depmod
--install %{KVERREL}%{?-v:.%{-v*}} || exit $?\
#if [ -x /sbin/weak-modules ]\
@@ -1588,18 +1588,18 @@ fi}\
%{nil}
%kernel_variant_preun
-%kernel_variant_post -s kernel-smp -r kernel
+%kernel_variant_post -r kernel-smp
%kernel_variant_preun smp
%kernel_variant_post -v smp
%kernel_variant_preun PAE
-%kernel_variant_post -v PAE -s kernel-smp -r kernel-PAE
+%kernel_variant_post -v PAE -r kernel-smp
%kernel_variant_preun debug
%kernel_variant_post -v debug
-%kernel_variant_post -v PAEdebug -s kernel-smp -r kernel-PAEdebug
+%kernel_variant_post -v PAEdebug -r kernel-smp
%kernel_variant_preun PAEdebug
if [ -x /sbin/ldconfig ]
--
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: [patch 1/7] Fix kernel_{conflicts,obsoletes,provides}
On Wed, 2008-07-23 at 17:08 -0700, Roland McGrath wrote: On Wed, 2008-07-23 at 12:44 -0700, Roland McGrath wrote: If you try and use e.g. kernel_obsoletes, you'll soon find that it's actually kernel__obsoletes you currently need :-) So you want kernel to have an Obsoletes: that kernel-foo do not get? Yes; kernel-PAE.i686 obsoletes kernel-xen.i686 and kernel.x86_64 obsoletes kernel-xen.x86_64. But you don't want all kernel* to obsolete kernel-xen? Any special reason? If you install kernel.i686, we don't want kernel-xen.i686 to be considered for removal because only kernel-PAE.i686 has Xen DomU support. Cheers, Mark. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: [patch 2/7] Change how we do nosegneg
On Wed, 2008-07-23 at 17:41 -0700, Roland McGrath wrote:
So let's structure things around that: the kernel build for an arch that
uses vdso might include a kernelcap.conf file (or might not).
For simplicity and consistency in the .spec file, we'll install a file for
all variants even when it's an empty placeholder. For the magic, the diff
below probably covers it (wholly untested). Then it's up to BuildKernel
just to add/remove ldconfig-kernelcap.conf as part of the build (perhaps
eventually done by the upstream makefiles).
The .conf files have to not conflict (reuse same bit with different name)
across all installed kernels (or else ldconfig will complain). So a single
kernel-%{KVERREL}.conf file would be fine. But instead I made it
kernel-%{KVERREL}.variant.conf just to stay consistent with all existing
names like /lib/module/FOO and the fact that no two kernel rpms conflict on
the same file name (even if identical).
All sounds fairly reasonable to me, but why not have make vdso_install
install the file?
Looking at your patch, if you're going have a file per-variant, you need
to install it in BuildKernel. And you also only want to do it on
vdso_arches.
Another wholly untested patch below :)
Cheers,
Mark.
Index: devel/kernel.spec
===
--- devel.orig/kernel.spec 2008-07-24 08:49:22.0 +0100
+++ devel.orig/kernel.spec 2008-07-24 08:49:22.0 +0100
@@ -1312,6 +1312,13 @@ BuildKernel() {
make -s ARCH=$Arch INSTALL_MOD_PATH=$RPM_BUILD_ROOT modules_install
KERNELRELEASE=$KernelVer mod-fw=
%ifarch %{vdso_arches}
make -s ARCH=$Arch INSTALL_MOD_PATH=$RPM_BUILD_ROOT vdso_install
KERNELRELEASE=$KernelVer
+if [ ! -s ldconfig-kernelcap.conf ]; then
+ echo ldconfig-kernelcap.conf \
+# Placeholder file, no vDSO hwcap entries used in this kernel.
+fi
+
+%{__install} -D -m 444 ldconfig-kernelcap.conf \
+$RPM_BUILD_ROOT/etc/ld.so.conf.d/kernel-$KernelVer.conf
%endif
# And save the headers/makefiles etc for building modules against
@@ -1509,22 +1516,6 @@ BuildKernel vmlinux vmlinux kdump vmlinu
cd linux-%{kversion}.%{_target_cpu}
-%if %{includexen}
-%if %{with_xen}
-mkdir -p $RPM_BUILD_ROOT/etc/ld.so.conf.d
-rm -f $RPM_BUILD_ROOT/etc/ld.so.conf.d/kernelcap-%{KVERREL}.xen.conf
-cat $RPM_BUILD_ROOT/etc/ld.so.conf.d/kernelcap-%{KVERREL}.xen.conf \EOF
-# This directive teaches ldconfig to search in nosegneg subdirectories
-# and cache the DSOs there with extra bit 0 set in their hwcap match
-# fields. In Xen guest kernels, the vDSO tells the dynamic linker to
-# search in nosegneg subdirectories and to match this extra hwcap bit
-# in the ld.so.cache file.
-hwcap 0 nosegneg
-EOF
-chmod 444 $RPM_BUILD_ROOT/etc/ld.so.conf.d/kernelcap-%{KVERREL}.xen.conf
-%endif
-%endif
-
%if %{with_doc}
mkdir -p $RPM_BUILD_ROOT/usr/share/doc/kernel-doc-%{kversion}/Documentation
@@ -1728,6 +1719,7 @@ fi
/lib/modules/%{KVERREL}%{?2:.%{2}}/weak-updates\
%ifarch %{vdso_arches}\
/lib/modules/%{KVERREL}%{?2:.%{2}}/vdso\
+/etc/ld.so.conf.d/kernelcap-%{KVERREL}%{?2:.%{2}}.conf\
%endif\
/lib/modules/%{KVERREL}%{?2:.%{2}}/modules.block\
/lib/modules/%{KVERREL}%{?2:.%{2}}/modules.networking\
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: [patch 2/7] Change how we do nosegneg
On Thu, 2008-07-24 at 09:12 +0100, Mark McLoughlin wrote:
On Wed, 2008-07-23 at 17:41 -0700, Roland McGrath wrote:
For simplicity and consistency in the .spec file, we'll install a file for
all variants even when it's an empty placeholder. For the magic, the diff
below probably covers it (wholly untested). Then it's up to BuildKernel
just to add/remove ldconfig-kernelcap.conf as part of the build (perhaps
eventually done by the upstream makefiles).
So, for Xen, we'll want something like this until it's done upstream:
Index: devel/kernel.spec
===
--- devel.orig/kernel.spec2008-07-24 08:49:22.0 +0100
+++ devel.orig/kernel.spec2008-07-24 08:49:22.0 +0100
@@ -1312,6 +1312,13 @@ BuildKernel() {
make -s ARCH=$Arch INSTALL_MOD_PATH=$RPM_BUILD_ROOT modules_install
KERNELRELEASE=$KernelVer mod-fw=
%ifarch %{vdso_arches}
make -s ARCH=$Arch INSTALL_MOD_PATH=$RPM_BUILD_ROOT vdso_install
KERNELRELEASE=$KernelVer
+if grep '^CONFIG_XEN=y$' .config /dev/null; then
+ echo ldconfig-kernelcap.conf \
+# This directive teaches ldconfig to search in nosegneg subdirectories
+# and cache the DSOs there with extra bit 0 set in their hwcap match
+# fields. In Xen guest kernels, the vDSO tells the dynamic linker to
+# search in nosegneg subdirectories and to match this extra hwcap bit
+# in the ld.so.cache file.
+hwcap 0 nosegneg
+fi
+if [ ! -s ldconfig-kernelcap.conf ]; then
+ echo ldconfig-kernelcap.conf \
+# Placeholder file, no vDSO hwcap entries used in this kernel.
+fi
+%{__install} -D -m 444 ldconfig-kernelcap.conf \
+$RPM_BUILD_ROOT/etc/ld.so.conf.d/kernel-$KernelVer.conf
%endif
Cheers,
Mark.
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
[patch 7/7] Enable Xen support again
and retake the fault.
+
+Fix it by masking off the xen-sensitive control bits when checking
+that the segment descriptor is up-to-date, and comparing only the
+bits which affect the segment base and limit.
+
+Affects 32-bit only; execshield on 64-bit uses NX for this
+functionality.
+
+Signed-off-by: Stephen Tweedie [EMAIL PROTECTED]
+---
+ arch/x86/kernel/traps_32.c |3 ++-
+ 1 files changed, 2 insertions(+), 1 deletions(-)
+
+diff --git a/arch/x86/kernel/traps_32.c b/arch/x86/kernel/traps_32.c
+index d001d55..c932b3e 100644
+--- a/arch/x86/kernel/traps_32.c
b/arch/x86/kernel/traps_32.c
+@@ -621,7 +621,8 @@ check_lazy_exec_limit(int cpu, struct pt_regs *regs, long
error_code)
+ desc1 = current-mm-context.user_cs;
+ desc2 = get_cpu_gdt_table(cpu) + GDT_ENTRY_DEFAULT_USER_CS;
+
+- if (desc1-a != desc2-a || desc1-b != desc2-b) {
++ if ((desc1-a 0xffff) != (desc2-a 0xffff) ||
++ desc1-b != desc2-b) {
+ /*
+* The CS was not in sync - reload it and retry the
+* instruction. If the instruction still faults then
+--
+1.5.4.1
+
Index:
devel/linux-2.6-xen-execshield-only-define-load_user_cs_desc-on-32-bit.patch
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ /dev/null 1970-01-01 00:00:00.0 +
@@ -0,0 +1,122 @@
+From 226bc4b8f13ece618de046f6f8da88eeb4b8f8da Mon Sep 17 00:00:00 2001
+From: Mark McLoughlin [EMAIL PROTECTED]
+Date: Tue, 25 Mar 2008 11:56:43 +
+Subject: [PATCH] xen execshield: Only define load_user_cs_desc() on 32 bit
+
+load_user_cs_desc() is only used on 32 bit, so only
+define it in that case.
+
+Fixes compile failure in native_load_user_cs_desc()
+since mm_context_t-user_cs is only available on
+32 bit.
+
+Signed-off-by: Mark McLoughlin [EMAIL PROTECTED]
+---
+ arch/x86/kernel/paravirt.c |2 ++
+ arch/x86/xen/enlighten.c |4
+ include/asm-x86/desc.h |4
+ include/asm-x86/paravirt.h |4
+ 4 files changed, 14 insertions(+), 0 deletions(-)
+
+diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c
+index f2a678c..4277d1a 100644
+--- a/arch/x86/kernel/paravirt.c
b/arch/x86/kernel/paravirt.c
+@@ -336,7 +336,9 @@ struct pv_cpu_ops pv_cpu_ops = {
+ .read_tscp = native_read_tscp,
+ .load_tr_desc = native_load_tr_desc,
+ .set_ldt = native_set_ldt,
++#ifdef CONFIG_X86_32
+ .load_user_cs_desc = native_load_user_cs_desc,
++#endif
+ .load_gdt = native_load_gdt,
+ .load_idt = native_load_idt,
+ .store_gdt = native_store_gdt,
+diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
+index 9b95277..c54060c 100644
+--- a/arch/x86/xen/enlighten.c
b/arch/x86/xen/enlighten.c
+@@ -340,6 +340,7 @@ static void xen_set_ldt(const void *addr, unsigned entries)
+ xen_mc_issue(PARAVIRT_LAZY_CPU);
+ }
+
++#ifdef CONFIG_X86_32
+ static inline void xen_load_user_cs_desc(int cpu, struct mm_struct *mm)
+ {
+ void *gdt;
+@@ -355,6 +356,7 @@ static inline void xen_load_user_cs_desc(int cpu, struct
mm_struct *mm)
+
+ HYPERVISOR_update_descriptor(mgdt.maddr, descriptor);
+ }
++#endif
+
+ static void xen_load_gdt(const struct desc_ptr *dtr)
+ {
+@@ -1229,7 +1231,9 @@ static const struct pv_cpu_ops xen_cpu_ops __initdata = {
+
+ .load_tr_desc = paravirt_nop,
+ .set_ldt = xen_set_ldt,
++#ifdef CONFIG_X86_32
+ .load_user_cs_desc = xen_load_user_cs_desc,
++#endif
+ .load_gdt = xen_load_gdt,
+ .load_idt = xen_load_idt,
+ .load_tls = xen_load_tls,
+diff --git a/include/asm-x86/desc.h b/include/asm-x86/desc.h
+index 713634f..54234ac 100644
+--- a/include/asm-x86/desc.h
b/include/asm-x86/desc.h
+@@ -91,7 +91,9 @@ static inline int desc_empty(const void *ptr)
+
+ #define load_TLS(t, cpu) native_load_tls(t, cpu)
+ #define set_ldt native_set_ldt
++#ifdef CONFIG_X86_32
+ #define load_user_cs_desc native_load_user_cs_desc
++#endif
+
+ #define write_ldt_entry(dt, entry, desc) \
+ native_write_ldt_entry(dt, entry, desc)
+@@ -382,10 +384,12 @@ static inline void set_user_cs(struct desc_struct *desc,
unsigned long limit)
+ desc-b = (limit 0xf) | 0x00c0fb00;
+ }
+
++#ifdef CONFIG_X86_32
+ static inline void native_load_user_cs_desc(int cpu, struct mm_struct *mm)
+ {
+ get_cpu_gdt_table(cpu)[GDT_ENTRY_DEFAULT_USER_CS] = mm-context.user_cs;
+ }
++#endif
+
+ extern void arch_add_exec_range(struct mm_struct *mm, unsigned long limit);
+ extern void arch_remove_exec_range(struct mm_struct *mm, unsigned long limit);
+diff --git a/include/asm-x86/paravirt.h b/include/asm-x86/paravirt.h
+index 151ac7a..f354748 100644
+--- a/include/asm-x86/paravirt.h
b/include/asm-x86/paravirt.h
+@@ -113,7 +113,9 @@ struct pv_cpu_ops {
+ void (*store_gdt)(struct desc_ptr *);
+ void (*store_idt)(struct desc_ptr *);
+ void (*set_ldt)(const void *desc, unsigned entries
[patch 3/7] Kill old xen cruft
Kill off most of the remnants of the separate xen package
Gone is the kernel-xen variant and xen.gz
Index: devel/kernel.spec
===
--- devel.orig/kernel.spec 2008-07-23 14:13:25.0 +0100
+++ devel.orig/kernel.spec 2008-07-23 14:13:25.0 +0100
@@ -66,8 +66,6 @@ Summary: The Linux kernel
%define with_smp %{?_without_smp: 0} %{?!_without_smp: 1}
# kernel-PAE (only valid for i686)
%define with_pae %{?_without_pae: 0} %{?!_without_pae: 1}
-# kernel-xen
-%define with_xen %{?_without_xen: 0} %{?!_without_xen: 1}
# kernel-kdump
%define with_kdump %{?_without_kdump: 0} %{?!_without_kdump: 1}
# kernel-debug
@@ -94,17 +92,10 @@ Summary: The Linux kernel
%define with_smponly %{?_with_smponly: 1} %{?!_with_smponly: 0}
# Only build the pae kernel (--with paeonly):
%define with_paeonly %{?_with_paeonly: 1} %{?!_with_paeonly: 0}
-# Only build the xen kernel (--with xenonly):
-%define with_xenonly %{?_with_xenonly: 1} %{?!_with_xenonly: 0}
# should we do C=1 builds with sparse
%define with_sparse%{?_with_sparse: 1} %{?!_with_sparse: 0}
-# Whether or not to apply the Xen patches -- leave this enabled
-%define includexen 0
-# Xen doesn't work with current upstream kernel, shut it off
-%define with_xen 0
-
# Set debugbuildsenabled to 1 for production (build separate debug kernels)
# and 0 for rawhide (all kernels are debug kernels).
# See also 'make debug' and 'make release'.
@@ -135,11 +126,6 @@ Summary: The Linux kernel
%define make_target bzImage
-%define xen_hv_cset 11633
-%define xen_flags verbose=y crash_debug=y
-%define xen_target vmlinuz
-%define xen_image vmlinuz
-
%define KVERREL %{PACKAGE_VERSION}-%{PACKAGE_RELEASE}.%{_target_cpu}
%define hdrarch %_target_cpu
@@ -152,8 +138,6 @@ Summary: The Linux kernel
%endif
%if %{nopatches}
-%define includexen 0
-%define with_xen 0
%define with_bootwrapper 0
%define variant -vanilla
%else
@@ -181,7 +165,6 @@ Summary: The Linux kernel
%if %{with_baseonly}
%define with_smp 0
%define with_pae 0
-%define with_xen 0
%define with_kdump 0
%define with_debug 0
%endif
@@ -190,7 +173,6 @@ Summary: The Linux kernel
%if %{with_smponly}
%define with_up 0
%define with_pae 0
-%define with_xen 0
%define with_kdump 0
%define with_debug 0
%endif
@@ -199,16 +181,6 @@ Summary: The Linux kernel
%if %{with_paeonly}
%define with_up 0
%define with_smp 0
-%define with_xen 0
-%define with_kdump 0
-%define with_debug 0
-%endif
-
-# if requested, only build xen kernel
-%if %{with_xenonly}
-%define with_up 0
-%define with_smp 0
-%define with_pae 0
%define with_kdump 0
%define with_debug 0
%endif
@@ -230,11 +202,6 @@ Summary: The Linux kernel
%define with_pae 0
%endif
-# xen only builds on i686, x86_64 and ia64
-%ifnarch i686 x86_64 ia64
-%define with_xen 0
-%endif
-
# only build kernel-kdump on ppc64
# (no relocatable kernel support upstream yet)
%ifnarch ppc64
@@ -281,8 +248,6 @@ Summary: The Linux kernel
%define all_arch_configs kernel-%{version}-i?86*.config
%define image_install_path boot
%define hdrarch i386
-# we build always xen i686 HV with pae
-%define xen_flags verbose=y crash_debug=y pae=y
%define kernel_image arch/x86/boot/bzImage
%endif
@@ -334,10 +299,6 @@ Summary: The Linux kernel
%define image_install_path boot/efi/EFI/redhat
%define make_target compressed
%define kernel_image vmlinux.gz
-# ia64 xen HV doesn't building with debug=y at the moment
-%define xen_flags verbose=y crash_debug=y
-%define xen_target compressed
-%define xen_image vmlinux.gz
%endif
%ifarch alpha alphaev56
@@ -374,7 +335,6 @@ Summary: The Linux kernel
%define with_up 0
%define with_smp 0
%define with_pae 0
-%define with_xen 0
%define with_kdump 0
%define with_debuginfo 0
%define _enable_debug_packages 0
@@ -497,8 +457,6 @@ BuildRequires: rpm-build = 4.4.2.1-4
%endif
Source0: ftp://ftp.kernel.org/pub/linux/kernel/v2.6/linux-%{kversion}.tar.bz2
-#Source1: xen-%{xen_hv_cset}.tar.bz2
-Source2: Config.mk
Source10: COPYING.modules
Source11: genkey
@@ -509,18 +467,15 @@ Source20: Makefile.config
Source21: config-debug
Source22: config-nodebug
Source23: config-generic
-Source24: config-xen-generic
-Source25: config-rhel-generic
-Source26: config-rhel-x86-generic
+Source24: config-rhel-generic
+Source25: config-rhel-x86-generic
Source30: config-x86-generic
Source31: config-i586
Source32: config-i686
Source33: config-i686-PAE
-Source34: config-xen-x86
Source40: config-x86_64-generic
-Source41: config-xen-x86_64
Source50: config-powerpc-generic
Source51: config-powerpc32-generic
@@ -530,7 +485,6 @@ Source54: config-powerpc64-kdump
Source60: config-ia64-generic
Source61: config-ia64
-Source62: config-xen-ia64
Source70: config-s390x
@@ -823,13 +777,6 @@ It should only be installed when trying
on kernel bugs, as some
[patch 2/7] Change how we do nosegneg
We should really only install ld.so.conf files from packages
that actually have CONFIG_XEN enabled, but it would be
slightly messy to have only kernel-PAE.i686 and kernel.x86_64
include it.
Since it won't actually be used unless it's enabled by the
xen kernel at runtime, let's be lazy and have all variants
install them.
Index: devel/kernel.spec
===
--- devel.orig/kernel.spec 2008-07-23 14:05:27.0 +0100
+++ devel.orig/kernel.spec 2008-07-23 14:05:27.0 +0100
@@ -407,7 +407,7 @@ Summary: The Linux kernel
#
# The ld.so.conf.d file we install uses syntax older ldconfig's don't grok.
#
-%define kernel_xen_conflicts glibc 2.3.5-1, xen 3.0.1
+%define nosegneg_conflicts glibc 2.3.5-1, xen 3.0.1
# upto and including kernel 2.4.9 rpms, the 4Gb+ kernel was called
kernel-enterprise
# now that the smp kernel offers this capability, obsolete the old kernel
@@ -440,6 +440,7 @@ Provides: kernel-uname-r = %{KVERREL}%{?
Requires(pre): %{kernel_prereq}\
Conflicts: %{kernel_dot_org_conflicts}\
Conflicts: %{package_conflicts}\
+Conflicts: %{nosegneg_conflicts}\
%{?1:%{expand:%%{?kernel%{?1:_%{1}}_conflicts:Conflicts:
%%{kernel%{?1:_%{1}}_conflicts\
%{?1:%{expand:%%{?kernel%{?1:_%{1}}_obsoletes:Obsoletes:
%%{kernel%{?1:_%{1}}_obsoletes\
%{?1:%{expand:%%{?kernel%{?1:_%{1}}_provides:Provides:
%%{kernel%{?1:_%{1}}_provides\
@@ -1440,6 +1441,18 @@ BuildKernel() {
mkdir -p $RPM_BUILD_ROOT/usr/src/kernels
mv $RPM_BUILD_ROOT/lib/modules/$KernelVer/build $RPM_BUILD_ROOT/$DevelDir
ln -sf ../../..$DevelDir $RPM_BUILD_ROOT/lib/modules/$KernelVer/build
+
+mkdir -p $RPM_BUILD_ROOT/etc/ld.so.conf.d
+rm -f $RPM_BUILD_ROOT/etc/ld.so.conf.d/kernelcap-$KernelVer.nosegneg.conf
+cat $RPM_BUILD_ROOT/etc/ld.so.conf.d/kernelcap-$KernelVer.nosegneg.conf
EOF
+# This directive teaches ldconfig to search in nosegneg subdirectories
+# and cache the DSOs there with extra bit 0 set in their hwcap match
+# fields. In Xen guest kernels, the vDSO tells the dynamic linker to
+# search in nosegneg subdirectories and to match this extra hwcap bit
+# in the ld.so.cache file.
+hwcap 0 nosegneg
+EOF
+chmod 444
$RPM_BUILD_ROOT/etc/ld.so.conf.d/kernelcap-$KernelVer.nosegneg.conf
}
###
@@ -1521,22 +1534,6 @@ BuildKernel vmlinux vmlinux kdump vmlinu
cd linux-%{kversion}.%{_target_cpu}
-%if %{includexen}
-%if %{with_xen}
-mkdir -p $RPM_BUILD_ROOT/etc/ld.so.conf.d
-rm -f $RPM_BUILD_ROOT/etc/ld.so.conf.d/kernelcap-%{KVERREL}.xen.conf
-cat $RPM_BUILD_ROOT/etc/ld.so.conf.d/kernelcap-%{KVERREL}.xen.conf \EOF
-# This directive teaches ldconfig to search in nosegneg subdirectories
-# and cache the DSOs there with extra bit 0 set in their hwcap match
-# fields. In Xen guest kernels, the vDSO tells the dynamic linker to
-# search in nosegneg subdirectories and to match this extra hwcap bit
-# in the ld.so.cache file.
-hwcap 0 nosegneg
-EOF
-chmod 444 $RPM_BUILD_ROOT/etc/ld.so.conf.d/kernelcap-%{KVERREL}.xen.conf
-%endif
-%endif
-
%if %{with_doc}
mkdir -p $RPM_BUILD_ROOT/usr/share/doc/kernel-doc-%{kversion}/Documentation
@@ -1745,6 +1742,7 @@ fi
/lib/modules/%{KVERREL}%{?2:.%{2}}/modules.networking\
/lib/modules/%{KVERREL}%{?2:.%{2}}/modules.order\
%ghost /boot/initrd-%{KVERREL}%{?2:.%{2}}.img\
+/etc/ld.so.conf.d/kernelcap-%{KVERREL}%{?2:.%{2}}.nosegneg.conf\
%{?-e:%{-e*}}\
%{expand:%%files %{?2:%{2}-}devel}\
%defattr(-,root,root)\
@@ -1777,7 +1775,7 @@ fi
%kernel_variant_files %{with_pae} PAE
%kernel_variant_files %{with_pae_debug} PAEdebug
%kernel_variant_files -k vmlinux %{with_kdump} kdump
-%kernel_variant_files -a /%{image_install_path}/xen*-%{KVERREL}.xen -e
/etc/ld.so.conf.d/kernelcap-%{KVERREL}.xen.conf %{with_xen} xen
+%kernel_variant_files -a /%{image_install_path}/xen*-%{KVERREL}.xen
%{with_xen} xen
%changelog
* Tue Jul 22 2008 Dave Jones [EMAIL PROTECTED]
--
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
[patch 6/7] Slightly re-org virt related configs
Get all OCD on virt related configs - bring them together, separate the host stuff from the guest stuff and make the x86_64 config look much more like the x86 config. Index: devel/config-x86-generic === --- devel.orig/config-x86-generic 2008-07-23 09:49:15.0 +0100 +++ devel.orig/config-x86-generic 2008-07-23 09:49:15.0 +0100 @@ -318,9 +318,6 @@ CONFIG_SONY_LAPTOP=m # CONFIG_SMSC37B787_WDT is not set CONFIG_W83697HF_WDT=m -CONFIG_PARAVIRT=y -# CONFIG_PARAVIRT_DEBUG is not set - CONFIG_RELOCATABLE=y CONFIG_PHYSICAL_ALIGN=0x40 CONFIG_PHYSICAL_START=0x40 @@ -331,12 +328,21 @@ CONFIG_CRYPTO_DEV_GEODE=m CONFIG_VIDEO_CAFE_CCIC=m +CONFIG_VIRTUALIZATION=y CONFIG_KVM=m CONFIG_KVM_INTEL=m CONFIG_KVM_AMD=m +CONFIG_KVM_TRACE=y +CONFIG_LGUEST=m + +CONFIG_PARAVIRT_GUEST=y +CONFIG_PARAVIRT=y +# CONFIG_PARAVIRT_DEBUG is not set CONFIG_KVM_CLOCK=y CONFIG_KVM_GUEST=y -CONFIG_KVM_TRACE=y +# CONFIG_XEN is not set +CONFIG_LGUEST_GUEST=y +CONFIG_VMI=y CONFIG_MTD_ESB2ROM=m CONFIG_MTD_CK804XROM=m @@ -360,14 +366,6 @@ CONFIG_DMIID=y CONFIG_ISCSI_IBFT_FIND=y CONFIG_ISCSI_IBFT=m -CONFIG_VIRTUALIZATION=y -CONFIG_PARAVIRT_GUEST=y -CONFIG_VMI=y -CONFIG_LGUEST=m -CONFIG_LGUEST_GUEST=y -# CONFIG_XEN is not set -# CONFIG_HVC_XEN is not set - CONFIG_DMADEVICES=y CONFIG_INTEL_IOATDMA=m Index: devel/config-x86_64-generic === --- devel.orig/config-x86_64-generic2008-07-23 09:49:15.0 +0100 +++ devel.orig/config-x86_64-generic2008-07-23 09:49:15.0 +0100 @@ -1,6 +1,5 @@ CONFIG_64BIT=y CONFIG_UID16=y -# CONFIG_XEN is not set # CONFIG_MK8 is not set # CONFIG_MPSC is not set CONFIG_GENERIC_CPU=y @@ -227,11 +226,6 @@ CONFIG_W83697HF_WDT=m # CONFIG_VIDEO_CAFE_CCIC is not set -CONFIG_KVM=m -CONFIG_KVM_INTEL=m -CONFIG_KVM_AMD=m -CONFIG_KVM_TRACE=y - CONFIG_MTD_ESB2ROM=m CONFIG_MTD_CK804XROM=m @@ -254,18 +248,23 @@ CONFIG_CPU_IDLE=y CONFIG_CPU_IDLE_GOV_MENU=y CONFIG_VIRTUALIZATION=y +CONFIG_KVM=m +CONFIG_KVM_INTEL=m +CONFIG_KVM_AMD=m +CONFIG_KVM_TRACE=y + +CONFIG_PARAVIRT_GUEST=y +CONFIG_PARAVIRT=y +# CONFIG_PARAVIRT_DEBUG is not set +CONFIG_KVM_CLOCK=y +CONFIG_KVM_GUEST=y +# CONFIG_XEN is not set CONFIG_DMADEVICES=y CONFIG_INTEL_IOATDMA=m CONFIG_SENSORS_I5K_AMB=m -CONFIG_PARAVIRT_GUEST=y -CONFIG_KVM_CLOCK=y -CONFIG_KVM_GUEST=y -CONFIG_PARAVIRT=y -# CONFIG_PARAVIRT_DEBUG is not set - # CONFIG_COMPAT_VDSO is not set CONFIG_PROVIDE_OHCI1394_DMA_INIT=y # CONFIG_DEBUG_PER_CPU_MAPS is not set -- ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: [patch 0/7] Enable pv_ops Xen; kill the kernel-xen RPM
On Wed, 2008-07-23 at 14:20 +0100, Mark McLoughlin wrote: I'm still doing a last bit of testing making sure that it all works fine, so don't apply yet ... but comments are very welcome. Okay, it seems to be in pretty good shape now. The only outstanding TODO item is to make kernel-PAE.i686 %post do: s/DEFAULTKERNEL=kernel-xen/DEFAULTKERNEL=kernel-PAE/ and kernel.x86_64 %post do: s/DEFAULTKERNEL=kernel-xen/DEFAULTKERNEL=kernel/ But I've had enough spec file pain for one day ... we can add this later :-) Cheers, Mark. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: [patch 4/7] Remove unneeded %kernel_variant_post args
On Wed, 2008-07-23 at 12:42 -0700, Roland McGrath wrote: Why bother? If it comes up in the future, the macro will be handy. The spec file is complex enough that I thought it better to remove anything that was only added for Xen. Needless to say, though, I don't care much either way ... Cheers, Mark. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: Please tag kernel-xen-2.6-2.6.25-0.22.rc9.fc9
On Tue, 2008-04-15 at 10:35 -0400, Bill Nottingham wrote: Jesse Keating ([EMAIL PROTECTED]) said: Please tag kernel-xen-2.6-2.6.25-0.22.rc9.fc9 +1 Tagged. Are we going to be able to get to a point where this is built as a 'normal' subpackage of the kernel? Yes. That's very, very much the goal. To that end, the kernel-xen RPM is as close as possible to kernel/devel e.g. see: http://git.et.redhat.com/?p=kernel-xen-rpm.git;a=shortlog But right now, the x86_64 patch set is still probably a bit too large to carry in kernel/devel. If we get that cleaned up more, though, then I think we could merge it back early on in F-10. And, obviously, we're very focused on pushing stuff upstream too. The trade-off is between the pain of having a separate kernel-xen RPM and the pain of having to continually re-base a huge patch. Cheers, Mark. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: kernel-xen f9 spec update
On Tue, 2008-04-01 at 12:26 -0400, Jarod Wilson wrote:
On Tuesday 01 April 2008 10:09:17 am Mark McLoughlin wrote:
On Mon, 2008-03-31 at 09:52 +0200, Mark McLoughlin wrote:
On Sat, 2008-03-29 at 15:19 -0400, Jarod Wilson wrote:
We recently tweaked the main kernel package's spec file such that we
now
include arch in uname -r output, and have standardized a bunch of path
names
to match. Completely forgot about kernel-xen in the process, until
yesterday,
when I started porting everything over the the kernel-xen-2.6/devel
spec.
The attached spec patch has been build-tested, with some manual
inspection of
the resulting packages, but hasn't yet been run-time tested for
possible
issues (none expected, but you never know...). I'll happily help out
with any
possible issues if you guys could give this a spin.
Definitely want this in ASAP so the kernel and kernel-xen bits stay
mostly in
sync (speaking of which, there's also some rpmposttrans stuff -- dkms
hooks -- which went into the main kernel spec a bit ago that I don't
see in
the kernel-xen-2.6 spec
Thanks for the heads-up and the patch. I'm planning on rebasing
kernel-xen-2.6/devel to the latest kernel/devel sometime this week, so
we'll pick up all this stuff.
Okay, kernel-xen in rawhide is rebased to 2.6.25-0.182.rc7.git6 if you
want to take a look.
Apologies if this is a dupe, X is being a tad crashy on me today...
Looks much better, but a few places where %{KVERREL}xen should be
changed to %{KVERREL}.xen to be consistent with the other flavoured
kernels.
Thanks, applied.
Cheers,
Mark.
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: kernel posttrans and preun hooks for other packages
On Mon, 2008-02-18 at 09:49 -0600, Matt Domsch wrote:
ok, new-kernel-pkg grows a --rpmposttrans mode then to call these
hooks, and we add a %posttrans to each kernel RPM.
This looks to be working fine, but let me see if I've got this
straight ...
+%define kernel_variant_posttrans(s:r:v:) \
+%{expand:%%posttrans %{?-v*}}\
...
%define kernel_variant_post(s:r:v:) \
%{expand:%%kernel_devel_post %{?-v*}}\
+%{expand:%%kernel_variant_posttrans %{?-v*}}\
in this case, %{?-v*} doesn't just expand to the argument to -v, but
also passes the -v to %kernel_variant_posttrans ?
i.e. I'd expect it to be something like:
%{expand:%%kernel_variant_posttrans %{?-v:-v %{-v*}}}\
I know spec file syntax is bizarre, but does anyone have a sensible
explanation for this behaviour?
Cheers,
Mark.
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: kernel-xen f9 spec update
Hi Jarod, (Copying fedora-kernel-list so other folks know what we're at) On Sat, 2008-03-29 at 15:19 -0400, Jarod Wilson wrote: We recently tweaked the main kernel package's spec file such that we now include arch in uname -r output, and have standardized a bunch of path names to match. Completely forgot about kernel-xen in the process, until yesterday, when I started porting everything over the the kernel-xen-2.6/devel spec. The attached spec patch has been build-tested, with some manual inspection of the resulting packages, but hasn't yet been run-time tested for possible issues (none expected, but you never know...). I'll happily help out with any possible issues if you guys could give this a spin. Definitely want this in ASAP so the kernel and kernel-xen bits stay mostly in sync (speaking of which, there's also some rpmposttrans stuff -- dkms hooks -- which went into the main kernel spec a bit ago that I don't see in the kernel-xen-2.6 spec Thanks for the heads-up and the patch. I'm planning on rebasing kernel-xen-2.6/devel to the latest kernel/devel sometime this week, so we'll pick up all this stuff. We eventually plan to get rid of the separate kernel-xen RPM altogether, but that will probably have to wait until we get most of the x86_64 and dom0 work upstream. In the meantime, we do intend to keep closely in sync with the latest stock kernel, and we're currently doing that using two git trees: a) http://git.et.redhat.com/?p=linux-2.6-fedora-pvops.git b) http://git.et.redhat.com/?p=kernel-xen-rpm.git If you look at e.g. the kernel-xen-2_6-2_6_25-0_6_rc4_fc9 tag for each of those you'll see a (a) a bunch of commits on top of the fedora kernel source tree and (b) a bunch of commits on top of kernel/devel from CVS. Each time we sync up with a new kernel version, we import a make prep tree into (a) and the corresponding kernel/devel tag from CVS into (b) and then use git to rebase the commits from the last kernel-xen tag for both of these. The easier we can make this rebasing process, the more frequent we'll rebase. Right now, I've got a few lame scripts to: 1) Import the result of make prep into (a) 2) Import a kernel/devel CVS tag into (b) 3) Export the xen patches from (a) and include them into the spec file in (b) 4) Copy everything from (b) to kernel-xen-2.6/devel but it's all still quite manual and error prone. Cheers, Mark. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
[PATCH 2/5] Fix use of %{version} instead of %{kversion}
Signed-off-by: Mark McLoughlin [EMAIL PROTECTED]
---
kernel.spec |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/kernel.spec b/kernel.spec
index 279326e..1fff49a 100644
--- a/kernel.spec
+++ b/kernel.spec
@@ -1220,7 +1220,7 @@ cp %{SOURCE2} .
if [ -d xen ]; then
rm -rf xen
fi
-%setup -D -T -q -n kernel-%{version} -a1
+%setup -D -T -q -n kernel-%{kversion} -a1
cd xen
# Any necessary hypervisor patches go here
--
1.5.4.1
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
[PATCH 3/5] Use correct %kernel_variant_post macro arguments for the Xen variant
From: Eduardo Habkost [EMAIL PROTECTED]
Signed-off-by: Eduardo Habkost [EMAIL PROTECTED]
Signed-off-by: Mark McLoughlin [EMAIL PROTECTED]
---
kernel.spec |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/kernel.spec b/kernel.spec
index 1fff49a..a82200d 100644
--- a/kernel.spec
+++ b/kernel.spec
@@ -1655,7 +1655,7 @@ fi}\
%kernel_variant_preun PAEdebug
%kernel_variant_preun xen
-%kernel_variant_post xen -v xen -s kernel-xen[0U] -r kernel-xen -- `[ -d
/proc/xen -a ! -e /proc/xen/xsd_kva ] || echo
--multiboot=/%{image_install_path}/xen.gz-%{KVERREL}`
+%kernel_variant_post -v xen -s kernel-xen[0U] -r kernel-xen -- `[ -d /proc/xen
-a ! -e /proc/xen/xsd_kva ] || echo
--multiboot=/%{image_install_path}/xen.gz-%{KVERREL}`
if [ -x /sbin/ldconfig ]
then
/sbin/ldconfig -X || exit $?
--
1.5.4.1
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
[PATCH 5/5] Support Provides on kernel_reqprovconf macro
From: Eduardo Habkost [EMAIL PROTECTED]
Signed-off-by: Eduardo Habkost [EMAIL PROTECTED]
Signed-off-by: Mark McLoughlin [EMAIL PROTECTED]
---
kernel.spec |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/kernel.spec b/kernel.spec
index 617a27f..1881836 100644
--- a/kernel.spec
+++ b/kernel.spec
@@ -430,6 +430,7 @@ Conflicts: %{kernel_dot_org_conflicts}\
Conflicts: %{package_conflicts}\
%{?1:%{expand:%%{?kernel_%{1}_conflicts:Conflicts:
%%{kernel_%{1}_conflicts\
%{?1:%{expand:%%{?kernel_%{1}_obsoletes:Obsoletes:
%%{kernel_%{1}_obsoletes\
+%{?1:%{expand:%%{?kernel_%{1}_provides:Provides: %%{kernel_%{1}_provides\
# We can't let RPM do the dependencies automatic because it'll then pick up\
# a correct but undesirable perl dependency from the module headers which\
# isn't required for the kernel proper to function\
--
1.5.4.1
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: UVESAFB in kernel 2.6.24
To execute.. Quote from [1]: add video=uvesafb:1024x768-32,mtrr:3,ywrap (or similar) to your kernel command line Right, but how does that work if built-in static? Is it relying on initialization order vs. initramfs unpacking to find its userspace component? Is it just spinning waiting for userspace? The readme says: 4. Installation Usage --- To configure, build and install v86d with the default settings, run: # ./configure --default # make # make install v86d isn't meant to be used in an interactive way. It should be started and called by the kernel. If you want to see it in action, build and load the uvesafb kernel module. If you want to include v86d into an initramfs image, misc/initramfs provides a minimal config parsable by gen_init_cpio. misc/initramfs says: dir /dev 0755 0 0 nod /dev/console 0600 0 0 c 5 1 nod /dev/tty1 0600 0 0 c 4 1 nod /dev/zero 0600 0 0 c 1 5 nod /dev/mem 0600 0 0 c 1 1 dir /root 0700 0 0 dir /sbin 0755 0 0 file /sbin/v86d /sbin/v86d 0755 0 0 I think the module simply has to be included with initramfs In general i'm not sure how this is supposed to work. only that it solves my widescreen issue and that it's less difficult to use than just vesafb (because that uses codes for the resolution while this one uses a readable text (like 1280x800)) ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
