RE: [patch 14/21] Xen-paravirt: Add XEN config options and disableunsupported config options.
Jeremy Fitzhardinge wrote: > Andrew Morton wrote: > > On Thu, 15 Feb 2007 22:14:45 -0800 Dan Hecht > <[EMAIL PROTECTED]> wrote: > > > > > >>> config PREEMPT > >>> bool "Preemptible Kernel (Low-Latency Desktop)" > >>> + depends on !XEN > >>> help > >>> This option reduces the latency of the kernel by making > >>> all kernel code (that is not executing in a critical section) > >>> > >>> > > > > Oh, so that's why it doesn't break when CONFIG_PREEMPT=y. > In which case > > that preempt_disable() I spotted is wrong-and-unneeded. > > > > Why doesn't Xen work with preemption?? > > > > I've forgotten the details. Ian? Keir? Steven? Maybe it > can be done. With CONFIG_PREEMPT, we can have preempted threads reference machine addresses across save/restore. After restore, these machine addresses will be incorrect. Christian - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [patch 14/21] Xen-paravirt: Add XEN config options and disableunsupported config options.
Jeremy Fitzhardinge wrote: Andrew Morton wrote: On Thu, 15 Feb 2007 22:14:45 -0800 Dan Hecht [EMAIL PROTECTED] wrote: config PREEMPT bool Preemptible Kernel (Low-Latency Desktop) + depends on !XEN help This option reduces the latency of the kernel by making all kernel code (that is not executing in a critical section) Oh, so that's why it doesn't break when CONFIG_PREEMPT=y. In which case that preempt_disable() I spotted is wrong-and-unneeded. Why doesn't Xen work with preemption?? I've forgotten the details. Ian? Keir? Steven? Maybe it can be done. With CONFIG_PREEMPT, we can have preempted threads reference machine addresses across save/restore. After restore, these machine addresses will be incorrect. Christian - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Xen/i386 cleanups - AGP bus/phys cleanups
On Sat, Mar 19, 2005 at 03:07:18AM -0700, Eric W. Biederman wrote: > For this specific case there may be another resolution but could > you please, please look at marking the missing pages PG_reserved > and not hacking phys_to_virt. > > At this point anything short of explicitly introducing an intermediate > step say virt_to_logical() logical_to_virt() will be extremely > confusing and lead to very hard to spot bugs. Silently changing > the semantics of functions is bad. We also use the additional level of indirection to implement suspend/ resume and relocation of virtual machines between physical machines -- you won't get the same sparse allocation of memory on the target machine. Also, this will make it much easier to support hot plug memory at the hypervisor level since it will be able to substitute memory with very little support from the OS running in the virtual machine. I agree that adding an additional step would make this much cleaner. christian - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Xen/i386 cleanups - AGP bus/phys cleanups
On Sat, Mar 19, 2005 at 03:07:18AM -0700, Eric W. Biederman wrote: For this specific case there may be another resolution but could you please, please look at marking the missing pages PG_reserved and not hacking phys_to_virt. At this point anything short of explicitly introducing an intermediate step say virt_to_logical() logical_to_virt() will be extremely confusing and lead to very hard to spot bugs. Silently changing the semantics of functions is bad. We also use the additional level of indirection to implement suspend/ resume and relocation of virtual machines between physical machines -- you won't get the same sparse allocation of memory on the target machine. Also, this will make it much easier to support hot plug memory at the hypervisor level since it will be able to substitute memory with very little support from the OS running in the virtual machine. I agree that adding an additional step would make this much cleaner. christian - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
