similar to: OLS BoF? Mainline Virtualization API status?

Folks, Regarding the Virtualization BoF, Ted Tso clarified that the remaining BoF sessons would just be scheduled on paper at OLS. We only need to use a scheduled BoF slot if we want to use a room there, I guess, else we can schedule at any free time and use a corridor or pub. Available BoF slots are only Friday evening, note. Since I don't believe the Xen team is available Friday evening,

I recently noticed that after starting xend ethtool no longer work for my e1000 card. In my 2.X box which is a P4, ethtool is working after xend start. Same version of e1000 on both boxes. The unstable box is a Tyan 2462 SMP, FC4 dom0 The 2.X box is Dell P330 UP, Centos 4.1 domO Until xend start ethtool is fine, in both setups I am using the e1000 as eth0. Regards, Ted

Looks to me like the first series of patches should be OK to post now. I propose that: 001-apply-to-page-range.patch 001a-reboot-use-struct.patch 002-sync-bitops.patch 003-remove-ring0-assumptions.patch 004-abstract-asm.patch 005-cpuid-cleanup.patch unfix-fixmap.patch fixmap-bootparam.patch remove-read-hazard-from-cow.patch pte-clear-not-present.patch

Rusty Russell wrote: > Chris: [RFC PATCH 12/33] Change __FIXADDR_TOP to leave room for the hypervisor. > - Replace with dynamic (Geerd) patch, put in paravirt_ops structure. > I'm looking at this, and I'm not sure that there needs to be a void (*set_fixmap_top)(unsigned long top) entry in paravirt ops. It seems to me that the hypervisor's init code can call the

Hi, I have seen many posts regarding this but have not found the soultion. So please cna someone shed some light on this Thanks - padma I get this error when I do try to create a domU guest (xen 3.0.0, 2.6.12.6). The vif is set to vif = [ '' mac=aa:00:00:00:11, bridge=xenbr0'' ] and a "brctl show" shows xenbr0 8000,fefffffff interfaces vif0.0 peth0 Xend.log

Guys currently I am horrified by the ease at which I can find bugs in the pending paravirtualization patches. I have barely even looked at arch/i386 in the -mm tree and it feels like I am tripping over significant bugs left and right. Because no one has heeded my advice and put in a proper platform layer on arch/i386 and we are instead doing a half baked job with paravirt_ops it is still

Guys currently I am horrified by the ease at which I can find bugs in the pending paravirtualization patches. I have barely even looked at arch/i386 in the -mm tree and it feels like I am tripping over significant bugs left and right. Because no one has heeded my advice and put in a proper platform layer on arch/i386 and we are instead doing a half baked job with paravirt_ops it is still

Hi Folks, I thought I''d heard several months back that Xen compatibility patches were going to be rolled into the mainstream linux kernel source trees, so that in future Xen would be just another architecture one could select under make config -- not requiring a special, patched kernel. But this doesn''t seem to be the case yet. Did I misunderstand what the plans were, or is it

Hi Andi, This series of patches updates paravirt_ops in various ways. Some of the changes are plain cleanups and improvements, and some add some interfaces necessary for Xen. The brief overview: add-MAINTAINERS.patch - obvious remove-CONFIG_DEBUG_PARAVIRT.patch - no longer needed paravirt-nop.patch - mark nop operations consistently paravirt-pte-accessors.patch - operations to pack/unpack

Hi Andi, This series of patches updates paravirt_ops in various ways. Some of the changes are plain cleanups and improvements, and some add some interfaces necessary for Xen. The brief overview: add-MAINTAINERS.patch - obvious remove-CONFIG_DEBUG_PARAVIRT.patch - no longer needed paravirt-nop.patch - mark nop operations consistently paravirt-pte-accessors.patch - operations to pack/unpack

Hi Andi, Here's a repost of the paravirt_ops update series I posted the other day. Since then, I found a few potential bugs with patching clobbering, cleaned up and documented paravirt.h and the patching machinery. Overview: add-MAINTAINERS.patch obvious remove-CONFIG_DEBUG_PARAVIRT.patch No longer meaningful or needed. paravirt-nop.patch Clean up nop paravirt_ops functions, mainly to

Hi Andi, Here's a repost of the paravirt_ops update series I posted the other day. Since then, I found a few potential bugs with patching clobbering, cleaned up and documented paravirt.h and the patching machinery. Overview: add-MAINTAINERS.patch obvious remove-CONFIG_DEBUG_PARAVIRT.patch No longer meaningful or needed. paravirt-nop.patch Clean up nop paravirt_ops functions, mainly to

Well, it seems to be about time to have this conversation again. A rough overview of the previous thread and requirements is: 1. bzImage would not be a bare ELF file, but it would contain an ELF header+file within it 2. We need some way to add extra ELF notes into that ELF file 3. We use a "paravirtualized" bootloader type, with some other field to determine which

Well, it seems to be about time to have this conversation again. A rough overview of the previous thread and requirements is: 1. bzImage would not be a bare ELF file, but it would contain an ELF header+file within it 2. We need some way to add extra ELF notes into that ELF file 3. We use a "paravirtualized" bootloader type, with some other field to determine which

Hi Andi, This is a set of updates for the firstfloor patch queue. Quick rundown: revert-mm-x86_64-mm-account-for-module-percpu-space-separately-from-kernel-percpu.patch separate-module-percpu-space.patch Update the module percpu accounting patch fix-ff-allow-percpu-variables-to-be-page-aligned.patch Make sure the percpu memory allocation is page-aligned

Hi Andi, This is a set of updates for the firstfloor patch queue. Quick rundown: revert-mm-x86_64-mm-account-for-module-percpu-space-separately-from-kernel-percpu.patch separate-module-percpu-space.patch Update the module percpu accounting patch fix-ff-allow-percpu-variables-to-be-page-aligned.patch Make sure the percpu memory allocation is page-aligned

Hi all, The next obvious step for paravirt_ops seems to me to be higher-level mmu operations: from reading the VMI patches it seems to do flushing, whereas Xen opts for batching. In the spirit of ops structures, this would be done by putting higher-level operations into the ops structure, and batching done by the op itself (perhaps with a default implementation for those too lazy to implement

Hi all, The next obvious step for paravirt_ops seems to me to be higher-level mmu operations: from reading the VMI patches it seems to do flushing, whereas Xen opts for batching. In the spirit of ops structures, this would be done by putting higher-level operations into the ops structure, and batching done by the op itself (perhaps with a default implementation for those too lazy to implement

This series contain fixes to make the paravirt_ops code compile and boot on x86_64. This is a follow-up for the previous series from Glauber.

This series contain fixes to make the paravirt_ops code compile and boot on x86_64. This is a follow-up for the previous series from Glauber.