similar to: Coverity + XenProject + Process?

From: Matt Wilson <msw@amazon.com> Commit f62805f1 introduced a bug where lazy MMU mode isn''t exited if a m2p_add/remove_override call fails. Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com> Cc: David Vrabel <david.vrabel@citrix.com> Cc: Anthony

Add a note to the public headers regarding how to get the VCPU ID for HVM guests (on x86). Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> Cc: Jan Beulich <jbeulich@suse.com> Cc: Keir Fraser <keir@xen.org> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Cc: Matt Wilson <msw@amazon.com> --- This is what Linux PVHVM does AFAIK, and also what I've been

I am working on some other bugs and perf issues - and while working I noticed that both sparse and Coverity have reported some issues with Xen drivers. Please see attached various bug-fixes that I am proposing for 3.6.

Add a note to the public headers regarding how to get the VCPU ID for HVM guests (on x86). Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> Acked-by: Matt Wilson <msw@amazon.com> Cc: Jan Beulich <jbeulich@suse.com> Cc: Keir Fraser <keir@xen.org> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Cc: Matt Wilson <msw@amazon.com> --- This is what Linux PVHVM

After concluding our poll [1] about changes to the security discussion, we determined that "Pre-disclosure to software vendors and a wide set of users" was probably the best fit for the community. A set of concrete changes to the policy have now been discussed on xen-devel [2] [3], and we seem to have converged on something everyone finds acceptable. We are now presenting these changes

After concluding our poll [1] about changes to the security discussion, we determined that "Pre-disclosure to software vendors and a wide set of users" was probably the best fit for the community. A set of concrete changes to the policy have now been discussed on xen-devel [2] [3], and we seem to have converged on something everyone finds acceptable. We are now presenting these changes

And also put my name behind the mainternship. Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> --- MAINTAINERS | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 0358a3e..e2252fc 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -193,8 +193,9 @@ F: xen/include/xen/iommu.h LINUX (PV_OPS) M: Jeremy Fitzhardinge

Three of the patches could be squashed in one, but it makes more sense to review them as three. These patches fix the case of an PVHVM guest not being able to resume propely b/c of hitting: 142 BUG_ON(info->type != IRQT_UNBOUND && info->type != type); (in events.c) and also adds a WARN to catch situations like these. The reason for this is that the Xen python toolstack

The attached patches allow the pciback module to perform a reset whenever a PCI device is: - attached to the pciback module, as so: echo "0000:01.07.0" > /sys/bus/pci/devices/pciback/bind - detached from the pciback module, as so: echo "0000:01.07.0" > /sys/bus/pci/devices/pciback/unbind - and when the guest is done with (internally when the guest is not using

These two patches provide the neccessary infrastructure changes for the processor-passthru driver [www.spinics.net/lists/linux-acpi/msg34655.html] to properly function. The first one is quite easy - we just modprobe the processor-passthru driver. The second allows it to work under AMD machines by exposing the PM RDMSR to dom0. It has been tested with 2.6.32 kernel as well to make sure it does

Patches that were posted last week - with review comments addressed.

Does upstream dom0 support superpage? best regards yang

Hey Stefano, I setup a cross ARM build system so that the generic changes won''t cause build issues on ARM (and actually caught a bug with fallback.o being enabled there - I''ve a fix for that). But more interestingly the build system I do also makes a variations of config entries. So there is the allmodules, allyes, allyes, but all Xen drivers are modules, etc. I found out that

Hello, The following patches are a solution to a problem we have encountered when using the Xen hypervisor: - Need Pxx/Cxx states to save on power consumption when using Xen (we do want those datacenters to consume less power!), - Also need to figure out the Turbo mode so that the scheduler can properly boost a core for CPU bound guests. In essence the Xen hypervisor requires that

I am proposing these two patches for 3.2. They allow the backend to process the REQ_FUA request as well. Previous to these patches it only did REQ_FLUSH. There is also a bug-fix for the logic of how barrier/flushes were handled. The patches are based on a branch which also has ''feature-discard'' patches, so they won''t apply nativly on top of 3.1-rc5. Please review and

Hey Ian and Stefano, Please see this thread: http://lists.xen.org/archives/html/xen-devel/2013-05/msg01053.html for the debug patches and some of the discussion. These three patches fix an race that has been in QEMU traditional for a long time. The guts of the bug is that if you have a guest with these options: vcpus=1 maxvcpus=32 and do ''xl vcpu-set <guest> 32'' the

>.. And KMS modesetting works properly now in Xen dom0! My onboard ATI Radeon is the following: > # lspci -v | grep VGA  11:04.0 VGA compatible controller: ATI Technologies Inc ES1000 (rev 02) (prog-if 00   [VGA controller]) Environment :  Xen 4.0.1-rc6 & 2.6.32.19 on top of F13 ( .config attached) [root@fedora13 ~]# lspci -v | grep VGA 01:00.0 VGA compatible controller: ATI

fyi if you are using an Xen + v3.10 + with i915. ----- Forwarded message from Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> ----- Date: Mon, 24 Jun 2013 11:47:48 -0400 From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> To: dri-devel@lists.freedesktop.org, chris@chris-wilson.co.uk, imre.deak@intel.com, daniel.vetter@ffwll.ch, airlied@linux.ie, airlied@gmail.com Cc:

First, maintainer''s addresses (Ryan Wilson <hap9@epoch.ncsc.mil>, Chris Bookholt <hap10@epoch.ncsc.mil>) are wrong (users unknown to remote mailsystem), so posting to you: PCI bus format strings are wrong. "%04x:%02x:%02x.%d" should be used instead of "%04x:%02x:%02x.%1x" (in many places of linux+v3.2.1/drivers/xen/xen-pciback/pci_stub.c) --

Are you expecting improvement after  09/15/2009 new-swiotlb commits ? 4097,6144, "No_dom0_mem_specified" don''t look to me to have any. Boris.   _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel