similar to: [patch 1/9] lguest: export symbols for lguest as a module

Because of legacy-induced blindness, I insisted on separately building the hypervisor.S switcher code (which is mapped at 0xFFC0000 in host and guest). However, the lguest64 patches showed the error of my ways: it has no relocations, so it can be linked into the module like normal then remapped. The only downside is that we can no longer use sizeof(hypervisor_blob), so we need to allocate our

Because of legacy-induced blindness, I insisted on separately building the hypervisor.S switcher code (which is mapped at 0xFFC0000 in host and guest). However, the lguest64 patches showed the error of my ways: it has no relocations, so it can be linked into the module like normal then remapped. The only downside is that we can no longer use sizeof(hypervisor_blob), so we need to allocate our

The assumption that we have an overall irqs_pending flags, and a one-to-one lguest <-> task mapping fails to hold on x86_64, where we can have multiple puppies, aka vcpus. Although ifdefs could be used, it makes the code much more unreadable, and other ports are on the way, anyway. So some sort of acessor is preferred anyway. Signed-off-by: Glauber de Oliveira Costa

The assumption that we have an overall irqs_pending flags, and a one-to-one lguest <-> task mapping fails to hold on x86_64, where we can have multiple puppies, aka vcpus. Although ifdefs could be used, it makes the code much more unreadable, and other ports are on the way, anyway. So some sort of acessor is preferred anyway. Signed-off-by: Glauber de Oliveira Costa

plain text document attachment (hvvm-mm-export.patch) I would like to have the HV VM code in the kernel proper, but until then, it needs to get at some of the memory page table utils (pud_alloc and friends). So as a module, we export this. I probably can change HV VM to just be compiled in the kernel like some of the other lguest stuff too. Signed-off-by: Steven Rostedt

plain text document attachment (hvvm-mm-export.patch) I would like to have the HV VM code in the kernel proper, but until then, it needs to get at some of the memory page table utils (pud_alloc and friends). So as a module, we export this. I probably can change HV VM to just be compiled in the kernel like some of the other lguest stuff too. Signed-off-by: Steven Rostedt

lguest needs to hold a reference to its task in case it exits while another Guest is sending it I/O. Otherwise we can oops in access_process_vm->get_task_mm->task_lock(). Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> --- drivers/lguest/lguest_user.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) ===================================================================

plain text document attachment (lguest64-device.patch) We started working a little bit on the devices for lguest64. This is still very much a work-in-progress and needs much more work. Signed-off-by: Steven Rostedt <srostedt@redhat.com> Signed-off-by: Glauber de Oliveira Costa <glommer@gmail.com> Cc: Chris Wright <chrisw@sous-sol.org> Index:

plain text document attachment (lguest64-device.patch) We started working a little bit on the devices for lguest64. This is still very much a work-in-progress and needs much more work. Signed-off-by: Steven Rostedt <srostedt@redhat.com> Signed-off-by: Glauber de Oliveira Costa <glommer@gmail.com> Cc: Chris Wright <chrisw@sous-sol.org> Index:

From: Rusty Russell <rusty@rustcorp.com.au> This is the code for the "lg.ko" module, which allows lguest guests to be launched. [akpm@linux-foundation.org: update for futex-new-private-futexes] Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Cc: Andi Kleen <ak@suse.de> Cc: Eric Dumazet <dada1@cosmosbay.com> Signed-off-by: Andrew Morton

From: Rusty Russell <rusty@rustcorp.com.au> This is the code for the "lg.ko" module, which allows lguest guests to be launched. [akpm@linux-foundation.org: update for futex-new-private-futexes] Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Cc: Andi Kleen <ak@suse.de> Cc: Eric Dumazet <dada1@cosmosbay.com> Signed-off-by: Andrew Morton

Hi, we''re using Xen 3.3.0 on Debian Etch with 2.6.18.8 kernel from xen.org on dom0. We have problems starting Intrepid domU (using Intrepid''s kernel 2.6.27-7-server) if we give more than 4GB of memory to this domain. Using memory = ''4096'' works perfectly, but changing it to ''4097'' already gives an error. Can anyone put some light on this?

Also remove unused xenbus_{,un}map_ring(), adjust types, and clean up header inclusion. Signed-off-by: Jan Beulich <jbeulich@novell.com> --- a/drivers/xen/blkback/blkback.c +++ b/drivers/xen/blkback/blkback.c @@ -41,6 +41,8 @@ #include <linux/list.h> #include <linux/delay.h> #include <xen/balloon.h> +#include <xen/evtchn.h> +#include <xen/gnttab.h>

On 08/31/2017 07:50 AM, PJ Welsh wrote: > A recently created and fully functional CentOS 7.3 VM fails to boot > after applying CR updates: <snip> > Server OS is CentOS 7.3 using Xen (no CR updates): > rpm -qa xen\* > xen-hypervisor-4.6.3-15.el7.x86_64 > xen-4.6.3-15.el7.x86_64 > xen-licenses-4.6.3-15.el7.x86_64 > xen-libs-4.6.3-15.el7.x86_64 >

On 09/02/2017 08:11 AM, Johnny Hughes wrote: > On 09/01/2017 02:41 PM, Kevin Stange wrote: >> On 08/31/2017 07:50 AM, PJ Welsh wrote: >>> A recently created and fully functional CentOS 7.3 VM fails to boot >>> after applying CR updates: >> <snip> >>> Server OS is CentOS 7.3 using Xen (no CR updates): >>> rpm -qa xen\* >>>

On 09/04/2017 05:27 PM, Johnny Hughes wrote: > On 09/04/2017 03:59 PM, Kevin Stange wrote: >> On 09/02/2017 08:11 AM, Johnny Hughes wrote: >>> On 09/01/2017 02:41 PM, Kevin Stange wrote: >>>> On 08/31/2017 07:50 AM, PJ Welsh wrote: >>>>> A recently created and fully functional CentOS 7.3 VM fails to boot >>>>> after applying CR updates:

Hi. We have several Centos 5 firewalls in our company - they are all in bridging mode. We updated them to the latest Centos 5.x last night. 4 hours later there was a crash.. (previously it had never crashed - and had been running for at least 1.5 yrs) The crash occurred when someone added a rule, after rebooting it was fine - the thing is it can't have been a bad rule as the first thing

IA-32 linear address translation is loads of fun. While cleaning up the LDT code, I noticed that kprobes code was very bogus with respect to segment handling. Many, many bugs are fixed here. I chose to combine the three separate functions that try to do linear address conversion into one, nice and working functions. All of the versions had bugs. 1) Taking an int3 from v8086 mode could cause

IA-32 linear address translation is loads of fun. While cleaning up the LDT code, I noticed that kprobes code was very bogus with respect to segment handling. Many, many bugs are fixed here. I chose to combine the three separate functions that try to do linear address conversion into one, nice and working functions. All of the versions had bugs. 1) Taking an int3 from v8086 mode could cause

Hi Linus, The following changes since commit 540ad6b62b3a188a53b51cac81d8a60d40e29fbd: Merge branch 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jwessel/linux-2.6-kgdb (2010-07-28 20:01:26 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git x86-mm-for-linus Andres Salomon (1): x86, mm: Create