Re: [Xen-devel] Inplace upgrading 4.4.x - 4.5.0
Monday, February 9, 2015, 9:35:33 AM, you wrote: Hello Steven, upgrades from Xen 4.4 to 4.5 are supposed to work out of the box. Please post more details and we'll try to help you figure out what's wrong. Cheers, Stefano On Sun, 8 Feb 2015, Steven Haigh wrote: Hi all, I was under the impression that you should be able to do in-place upgrades from Xen 4.4 to 4.5 on a system without losing the ability to manage DomUs... This would support upgrades from running systems from Xen 4.4.x to 4.5.0 - only requiring a reboot to boot into the 4.5.0 hypervisor. When I try this in practice, I get a whole heap of permission denied errors and lose control of any running DomUs. Is there some secret sauce that will allow this to work? -- Steven Haigh Email: net...@crc.id.au Web: http://www.crc.id.au Phone: (03) 9001 6090 - 0412 935 897 You are probably running into a mismatch between the running hypervisor (4.4) and the now installed toolstack (4.5) .. for instance when trying to shutdown the VM's to do the reboot. (Since the newly installed hypervisor parts are only loaded and run on the next boot). -- Sander ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC 7/7] libxl: Wait for QEMU startup in stubdomain
On Fri, 2015-02-06 at 17:23 +, Stefano Stabellini wrote: One of the main issues outstanding from when Anthony originally posted his patches is how we want to go about building this? I honestly do not know how well the current dracut-based approach to building the root image will work across various Linux distributions; perhaps it will be OK, since all of the libraries that dracut will siphon in will have to be in place to meet the build requirements for QEMU to begin with. However, I have zero knowledge about ARM-based Xen or where NetBSD is used for dom0, and how they might affect the decisionmaking. I also do not know what lessons have been learned from building other stubdoms, rumpkernel, or Mirage that might inform these decisions. In other words, what do you see as a sensible build scheme? The approach taken in the patches strikes me as too hacky for release quality, but maybe it is OK... It looks OK to me but I am not an expert in this kind of things. I'll let Ian Campbell and Ian Jackson (CC'ed) comment on it. I'm not at all keen on things like the use of dracut (or mkinitramfs or similar) in Xen's build since they are inherently/inevitably specific to the Linux distro they came from, so they often don't work (or aren't even available on) other Linux distros and are an even bigger problem for *BSD. I've yet to see a solution for this which seemed satisfactory enough to be included in Xen's system. Mirage, minios stubdoms, rumpkernels etc all avoid this by not having a need for a rootfs. But, it's not necessarily the case that the Xen project has to produce the Linux stubdom binary as part of its build output. IMHO it would be sufficient (for tech preview at least) if the tools would detect and use a stubdom binary if it were present at some well defined path so long as the for the runes to build the image were documented somewhere (e.g.in the wiki, in docs/misc, in some script, etc). Then the problems of them being distro/kernel specific are somewhat mitigated (e.g. a Fedora fan can write dracut instructions, a Debian fan can write mkinitramfs ones and a BSD fan can make it work with a BSD kernel etc etc) and we avoid having to have rootfs construction code in Xen's build. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC 4/7] libxl: Add stubdomain_version to domain_build_info.
On Tue, 2015-02-03 at 23:06 -0500, Eric Shelton wrote: This enum gives the ability to select between a MiniOS-based QEMU traditional stub domain and a Linux-based QEMU upstream stub domain. To use the Linux-based stubdomain, the following two lines should be included in the appropriate xl.cfg file: device_model_version=qemu-xen device_model_stubdomain_override=1 To use the MiniOS-based stubdomain, the following is used instead: device_model_version=qemu-xen-traditional device_model_stubdomain_override=1 This doesn't seem to use this new stubdom_version option and I'm not really sure what it is for. Perhaps you meant this new thing to be a libxl internal Enum, rather than exposed to the application which is using libxl? I'm not sure wy the user would need to be given the choice -- it should be inherent in the device-model version and stubdom boolean selection. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC 7/7] libxl: Wait for QEMU startup in stubdomain
On Mon, 9 Feb 2015, Ian Campbell wrote: On Fri, 2015-02-06 at 17:23 +, Stefano Stabellini wrote: One of the main issues outstanding from when Anthony originally posted his patches is how we want to go about building this? I honestly do not know how well the current dracut-based approach to building the root image will work across various Linux distributions; perhaps it will be OK, since all of the libraries that dracut will siphon in will have to be in place to meet the build requirements for QEMU to begin with. However, I have zero knowledge about ARM-based Xen or where NetBSD is used for dom0, and how they might affect the decisionmaking. I also do not know what lessons have been learned from building other stubdoms, rumpkernel, or Mirage that might inform these decisions. In other words, what do you see as a sensible build scheme? The approach taken in the patches strikes me as too hacky for release quality, but maybe it is OK... It looks OK to me but I am not an expert in this kind of things. I'll let Ian Campbell and Ian Jackson (CC'ed) comment on it. I'm not at all keen on things like the use of dracut (or mkinitramfs or similar) in Xen's build since they are inherently/inevitably specific to the Linux distro they came from, so they often don't work (or aren't even available on) other Linux distros and are an even bigger problem for *BSD. I've yet to see a solution for this which seemed satisfactory enough to be included in Xen's system. Mirage, minios stubdoms, rumpkernels etc all avoid this by not having a need for a rootfs. But, it's not necessarily the case that the Xen project has to produce the Linux stubdom binary as part of its build output. IMHO it would be sufficient (for tech preview at least) if the tools would detect and use a stubdom binary if it were present at some well defined path so long as the for the runes to build the image were documented somewhere (e.g.in the wiki, in docs/misc, in some script, etc). Then the problems of them being distro/kernel specific are somewhat mitigated (e.g. a Fedora fan can write dracut instructions, a Debian fan can write mkinitramfs ones and a BSD fan can make it work with a BSD kernel etc etc) and we avoid having to have rootfs construction code in Xen's build. I don't have an opinion on whether the stubdom build system should be in tree or out of tree, as long it can be used in OSSTest. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC 2/7] linux-stubdomain: Compile Linux
On Fri, 2015-02-06 at 17:45 +, Stefano Stabellini wrote: That's a good point. I think git clone would be more inline with any other external project that we use. However I'll let the other maintainers decide on this. If anything it should be a clone of a push-gated Linux git tree on xenbits.xen.org. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Inplace upgrading 4.4.x - 4.5.0
On 9/02/2015 7:59 PM, Sander Eikelenboom wrote: Monday, February 9, 2015, 9:35:33 AM, you wrote: Hello Steven, upgrades from Xen 4.4 to 4.5 are supposed to work out of the box. Please post more details and we'll try to help you figure out what's wrong. Cheers, Stefano On Sun, 8 Feb 2015, Steven Haigh wrote: Hi all, I was under the impression that you should be able to do in-place upgrades from Xen 4.4 to 4.5 on a system without losing the ability to manage DomUs... This would support upgrades from running systems from Xen 4.4.x to 4.5.0 - only requiring a reboot to boot into the 4.5.0 hypervisor. When I try this in practice, I get a whole heap of permission denied errors and lose control of any running DomUs. Is there some secret sauce that will allow this to work? You are probably running into a mismatch between the running hypervisor (4.4) and the now installed toolstack (4.5) .. for instance when trying to shutdown the VM's to do the reboot. (Since the newly installed hypervisor parts are only loaded and run on the next boot). Correct - It is the 4.4 Hypervisor with 4.5 toolstack. After a reboot, all is good. However this causes the problem - once you update the packages from 4.4 - 4.5, you lose the ability to manage any running DomUs. This is problematic - if only for the fact that you can't shut down running DomUs for the Dom0 reboot. I understand that large jumps in versions isn't supported - but I believe that point versions should be supported using the same toolset. ie 4.2 - 4.3, 4.4 - 4.5 etc. I'm just about to gather some data for it - and I'll make a new thread with what I can gather. -- Steven Haigh Email: net...@crc.id.au Web: http://www.crc.id.au Phone: (03) 9001 6090 - 0412 935 897 signature.asc Description: OpenPGP digital signature ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Inplace upgrading 4.4.x - 4.5.0
On 09/02/2015 09:09, Steven Haigh wrote: On 9/02/2015 7:59 PM, Sander Eikelenboom wrote: Monday, February 9, 2015, 9:35:33 AM, you wrote: Hello Steven, upgrades from Xen 4.4 to 4.5 are supposed to work out of the box. Please post more details and we'll try to help you figure out what's wrong. Cheers, Stefano On Sun, 8 Feb 2015, Steven Haigh wrote: Hi all, I was under the impression that you should be able to do in-place upgrades from Xen 4.4 to 4.5 on a system without losing the ability to manage DomUs... This would support upgrades from running systems from Xen 4.4.x to 4.5.0 - only requiring a reboot to boot into the 4.5.0 hypervisor. When I try this in practice, I get a whole heap of permission denied errors and lose control of any running DomUs. Is there some secret sauce that will allow this to work? You are probably running into a mismatch between the running hypervisor (4.4) and the now installed toolstack (4.5) .. for instance when trying to shutdown the VM's to do the reboot. (Since the newly installed hypervisor parts are only loaded and run on the next boot). Correct - It is the 4.4 Hypervisor with 4.5 toolstack. After a reboot, all is good. However this causes the problem - once you update the packages from 4.4 - 4.5, you lose the ability to manage any running DomUs. This is problematic - if only for the fact that you can't shut down running DomUs for the Dom0 reboot. I understand that large jumps in versions isn't supported - but I believe that point versions should be supported using the same toolset. ie 4.2 - 4.3, 4.4 - 4.5 etc. I'm just about to gather some data for it - and I'll make a new thread with what I can gather. This is because of the removal of Xend. In the past, Xend was a daemon process and would have continued to use the old libraries it loaded when it started. With xl and libxl, the new process will fall over an EACCES from Xen (mismatched tools and hypervisor) before it can identify the correct daemonised libxl process to talk to to shut the VMs down. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Booting dom0, various issues since v3.16 kernels
On 05.02.2015 15:47, Sander Eikelenboom wrote:
Thursday, February 5, 2015, 3:22:49 PM, you wrote:
Hey David,
after just being in that pain, I thought I might as well give a summary to
you/the list. Maybe helpful to not forget which piece should go to which
stable...
So:
v3.16...v3.17.8: Somewhen in between those, the acpi irq seems to have
broken.
I have not yet verified that, but at least three changes in
3.19-rc6 seem to look related:
* x86/xen: Treat SCI interrupt as normal GSI interrupt,
* ACPI: pci: Do not clear pci_dev-irq in acpi_pci_irq_disable(), and
* x86/xen: Override ACPI IRQ management callback __acpi_unregister_gsi
Yes Jiang Liu fixed those and said he would backport the required fixes once
they where accepted in mainline, put perhaps a polite ping is necessary there.
v3.17.8...v3.18.4: Beside the acpi interrupt, no USB devices (beyond the
hubs) get initialized. Not sure what fixed it, but it
looks ok in v3.19-rc7.
Beside that, there also was a regression in swiotlb
that I think was passed on to some stable maintainers:
Probably the same issue as above (for me it fixed a powerbutton issue and some
pci-passthrough problems).
And there seems to be more refactoring coming for 3.20 .. so fingerscrossed.
--
Sander
Hi Sander,
sorry, I know you did the ping somewhere in another thread. The one which I
cannot find again right now. :/ Maybe you can forward the following two patches
which would be my backport to 3.18. I hope things are correct. I dropped the
middle patch as it did not seem to be needed and mushed around the other two.
At least things seemed to be fixed up on a quick test-boot.
-Stefan
* Revert swiotlb-xen: pass dev_addr to swiotlb_tbl_unmap_single
v3.18.4..v3.19-rc7: The issues above look to be fixed. Only some Haswell
based box now crashed on boot as dom0 while parsing
some ACPI tables (will send more detail seperately).
This happens only on that host and only when running
as dom0. Bare-metal is ok and an Opteron based different
host is also fine.
-Stefan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
From 8b5b328b62248d95743ca9af7aa71c06dd808dfe Mon Sep 17 00:00:00 2001
From: Jiang Liu jiang@linux.intel.com
Date: Tue, 20 Jan 2015 10:21:05 +0800
Subject: [PATCH 1/2] x86/xen: Treat SCI interrupt as normal GSI interrupt
Currently Xen Domain0 has special treatment for ACPI SCI interrupt,
that is initialize irq for ACPI SCI at early stage in a special way as:
xen_init_IRQ()
-pci_xen_initial_domain()
-xen_setup_acpi_sci()
Allocate and initialize irq for ACPI SCI
Function xen_setup_acpi_sci() calls acpi_gsi_to_irq() to get an irq
number for ACPI SCI. But unfortunately acpi_gsi_to_irq() depends on
IOAPIC irqdomains through following path
acpi_gsi_to_irq()
-mp_map_gsi_to_irq()
-mp_map_pin_to_irq()
-check IOAPIC irqdomain
For PV domains, it uses Xen event based interrupt manangement and
doesn't make uses of native IOAPIC, so no irqdomains created for IOAPIC.
This causes Xen domain0 fail to install interrupt handler for ACPI SCI
and all ACPI events will be lost. Please refer to:
https://lkml.org/lkml/2014/12/19/178
So the fix is to get rid of special treatment for ACPI SCI, just treat
ACPI SCI as normal GSI interrupt as:
acpi_gsi_to_irq()
-acpi_register_gsi()
-acpi_register_gsi_xen()
-xen_register_gsi()
With above change, there's no need for xen_setup_acpi_sci() anymore.
The above change also works with bare metal kernel too.
Signed-off-by: Jiang Liu jiang@linux.intel.com
Tested-by: Sander Eikelenboom li...@eikelenboom.it
Cc: Tony Luck tony.l...@intel.com
Cc: xen-de...@lists.xenproject.org
Cc: Konrad Rzeszutek Wilk konrad.w...@oracle.com
Cc: David Vrabel david.vra...@citrix.com
Cc: Rafael J. Wysocki r...@rjwysocki.net
Cc: Len Brown len.br...@intel.com
Cc: Pavel Machek pa...@ucw.cz
Cc: Bjorn Helgaas bhelg...@google.com
Link: http://lkml.kernel.org/r/1421720467-7709-2-git-send-email-jiang@linux.intel.com
Signed-off-by: Thomas Gleixner t...@linutronix.de
Signed-off-by: Stefan Bader stefan.ba...@canonical.com
---
arch/x86/kernel/acpi/boot.c | 23 +++---
arch/x86/pci/xen.c | 47 -
2 files changed, 12 insertions(+), 58 deletions(-)
diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
index a142e77..460f498 100644
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -604,18 +604,19 @@ void __init acpi_pic_sci_set_trigger(unsigned int irq, u16 trigger)
int acpi_gsi_to_irq(u32 gsi, unsigned int *irqp)
{
- int irq;
-
- if (acpi_irq_model == ACPI_IRQ_MODEL_PIC) {
- *irqp = gsi;
- } else {
-
Re: [Xen-devel] Booting dom0, various issues since v3.16 kernels
Monday, February 9, 2015, 10:31:15 AM, you wrote: On 05.02.2015 15:47, Sander Eikelenboom wrote: Thursday, February 5, 2015, 3:22:49 PM, you wrote: Hey David, after just being in that pain, I thought I might as well give a summary to you/the list. Maybe helpful to not forget which piece should go to which stable... So: v3.16...v3.17.8: Somewhen in between those, the acpi irq seems to have broken. I have not yet verified that, but at least three changes in 3.19-rc6 seem to look related: * x86/xen: Treat SCI interrupt as normal GSI interrupt, * ACPI: pci: Do not clear pci_dev-irq in acpi_pci_irq_disable(), and * x86/xen: Override ACPI IRQ management callback __acpi_unregister_gsi Yes Jiang Liu fixed those and said he would backport the required fixes once they where accepted in mainline, put perhaps a polite ping is necessary there. v3.17.8...v3.18.4: Beside the acpi interrupt, no USB devices (beyond the hubs) get initialized. Not sure what fixed it, but it looks ok in v3.19-rc7. Beside that, there also was a regression in swiotlb that I think was passed on to some stable maintainers: Probably the same issue as above (for me it fixed a powerbutton issue and some pci-passthrough problems). And there seems to be more refactoring coming for 3.20 .. so fingerscrossed. -- Sander Hi Sander, sorry, I know you did the ping somewhere in another thread. The one which I cannot find again right now. :/ Maybe you can forward the following two patches which would be my backport to 3.18. I hope things are correct. I dropped the middle patch as it did not seem to be needed and mushed around the other two. At least things seemed to be fixed up on a quick test-boot. -Stefan Hi Stefan, I will also do a short test to see if it also fixes the problems i was seeing, and report back to you and/or forward your patches. Thanks for the effort ! -- Sander * Revert swiotlb-xen: pass dev_addr to swiotlb_tbl_unmap_single v3.18.4..v3.19-rc7: The issues above look to be fixed. Only some Haswell based box now crashed on boot as dom0 while parsing some ACPI tables (will send more detail seperately). This happens only on that host and only when running as dom0. Bare-metal is ok and an Opteron based different host is also fine. -Stefan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Inplace upgrading 4.4.x - 4.5.0
On 9/02/2015 8:16 PM, Ian Campbell wrote: On Mon, 2015-02-09 at 20:09 +1100, Steven Haigh wrote: On 9/02/2015 7:59 PM, Sander Eikelenboom wrote: Monday, February 9, 2015, 9:35:33 AM, you wrote: Hello Steven, upgrades from Xen 4.4 to 4.5 are supposed to work out of the box. Please post more details and we'll try to help you figure out what's wrong. Cheers, Stefano On Sun, 8 Feb 2015, Steven Haigh wrote: Hi all, I was under the impression that you should be able to do in-place upgrades from Xen 4.4 to 4.5 on a system without losing the ability to manage DomUs... This would support upgrades from running systems from Xen 4.4.x to 4.5.0 - only requiring a reboot to boot into the 4.5.0 hypervisor. When I try this in practice, I get a whole heap of permission denied errors and lose control of any running DomUs. Is there some secret sauce that will allow this to work? You are probably running into a mismatch between the running hypervisor (4.4) and the now installed toolstack (4.5) .. for instance when trying to shutdown the VM's to do the reboot. (Since the newly installed hypervisor parts are only loaded and run on the next boot). Correct - It is the 4.4 Hypervisor with 4.5 toolstack. After a reboot, all is good. However this causes the problem - once you update the packages from 4.4 - 4.5, you lose the ability to manage any running DomUs. This sounds like a packaging issue -- Debian's packages for example jump through some hoops to make sure multiple tools packages can be installed in parallel and the correct ones selected for the currently running hypervisor. Hmmm - that sounds very hacky :\ Otherwise I think the upgrade path is: * shutdown all VMs (or migrate them away) * install new Xen + tools * reboot * restart domains with new tools. I'm afraid that using old tools on a new Xen is not something which is supported, even in the midst of an upgrade and AFAIK never has been. The N-N+1-N+2 statement is normally with reference to live migration (i.e. you can live migrate from a 4.4 system to a 4.5 one). Hmmm Andrew is correct, the errors are all: = xl info == libxl: error: libxl.c:5044:libxl_get_physinfo: getting physinfo: Permission denied libxl_physinfo failed. libxl: error: libxl.c:5534:libxl_get_scheduler: getting domain info list: Permission denied host : xenhost release: 3.14.32-1.el6xen.x86_64 version: #1 SMP Sun Feb 8 15:41:07 AEDT 2015 machine: x86_64 xen_major : 4 xen_minor : 4 xen_extra : .1 xen_version: 4.4.1 xen_caps : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64 xen_scheduler : (null) xen_pagesize : 4096 platform_params: virt_start=0x8000 xen_changeset : xen_commandline: dom0_mem=1024M cpufreq=xen dom0_max_vcpus=1 dom0_vcpus_pin console=tty0 console=com1 com1=115200,8n1 cc_compiler: gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-11) cc_compile_by : mockbuild cc_compile_domain : crc.id.au cc_compile_date: Thu Jan 1 18:19:30 AEDT 2015 xend_config_format : 4 = xl list == libxl: error: libxl.c:669:libxl_list_domain: getting domain info list: Permission denied libxl_list_domain failed. = xl dmesg == libxl: error: libxl.c:6061:libxl_xen_console_read_line: reading console ring buffer: Permission denied So, this leads me to wonder - as I'm sure MANY people get bitten by this - how to control (at least to shutdown) DomUs after an in-place upgrade? Even if no other functions are implemented other than shutdown, I would call that an acceptable functionality. At least this way, you're not hard killing running VMs on reboot. -- Steven Haigh Email: net...@crc.id.au Web: http://www.crc.id.au Phone: (03) 9001 6090 - 0412 935 897 signature.asc Description: OpenPGP digital signature ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [linux-linus test] 34299: regressions - FAIL
flight 34299 linux-linus real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/34299/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-libvirt 12 guest-start.2 fail REGR. vs. 34227 test-amd64-amd64-libvirt 9 guest-start fail REGR. vs. 34227 Regressions which are regarded as allowable (not blocking): test-amd64-i386-libvirt 9 guest-start fail like 34227 test-amd64-i386-freebsd10-i386 7 freebsd-install fail like 34227 test-amd64-i386-freebsd10-amd64 7 freebsd-install fail like 34227 test-amd64-i386-pair17 guest-migrate/src_host/dst_host fail like 34227 test-amd64-amd64-xl-qemuu-winxpsp3 7 windows-install fail like 34227 Tests which did not succeed, but are not blocking: test-armhf-armhf-xl-sedf 10 migrate-support-checkfail never pass test-amd64-amd64-xl-pvh-intel 9 guest-start fail never pass test-armhf-armhf-xl-multivcpu 10 migrate-support-checkfail never pass test-armhf-armhf-xl 10 migrate-support-checkfail never pass test-armhf-armhf-xl-sedf-pin 10 migrate-support-checkfail never pass test-armhf-armhf-xl-midway 10 migrate-support-checkfail never pass test-amd64-amd64-xl-pvh-amd 9 guest-start fail never pass test-armhf-armhf-libvirt 10 migrate-support-checkfail never pass test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-armhf-armhf-xl-credit2 5 xen-boot fail never pass test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stopfail never pass test-amd64-amd64-xl-winxpsp3 14 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop fail never pass test-amd64-amd64-xl-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 14 guest-stop fail never pass test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-i386-xl-winxpsp3 14 guest-stop fail never pass test-amd64-i386-xl-qemut-winxpsp3 14 guest-stopfail never pass version targeted for testing: linux26cdd1f76a889a21faa851bcb260782db2c7f0a9 baseline version: linux9d82f5eb3376cbae96ad36a063a9390de1694546 People who touched revisions under test: Aaro Koskinen aaro.koski...@iki.fi Andrew Morton a...@linux-foundation.org Arnd Bergmann a...@arndb.de Baruch Siach bar...@tkos.co.il Bo Shen voice.s...@atmel.com Boris Ostrovsky boris.ostrov...@oracle.com Borislav Petkov b...@suse.de Brian Norris computersforpe...@gmail.com Charles Keepax ckee...@opensource.wolfsonmicro.com David Daney david.da...@cavium.com David Rientjes rient...@google.com Ed Swierk eswi...@skyportsystems.com Eric Nelson eric.nel...@boundarydevices.com Felix Fietkau n...@openwrt.org Filip Brozovic fbrozo...@gmail.com Greg Ungerer g...@uclinux.org Hemmo Nieminen hemmo.niemi...@iki.fi Hugh Dickins hu...@google.com Ingo Molnar mi...@kernel.org James Cowgill james.cowg...@imgtec.com James Hogan james.ho...@imgtec.com Jan Beulich jbeul...@suse.com Jarkko Nikula jarkko.nik...@linux.intel.com Jaroslav Kysela pe...@perex.cz Jie Yang yang@intel.com Johannes Weiner han...@cmpxchg.org John Stultz john.stu...@linaro.org Joonsoo Kim iamjoonsoo@lge.com Juri Lelli juri.le...@arm.com Kevin Strasser kevin.stras...@linux.intel.com Kim Phillips kim.phill...@freescale.com Konstantin Khlebnikov koc...@gmail.com Lai Jiangshan la...@cn.fujitsu.com Lars Persson lar...@axis.com Lars Persson lars.pers...@axis.com Lars-Peter Clausen l...@metafoo.de Liam Girdwood lgirdw...@gmail.com Linus Torvalds torva...@linux-foundation.org Luca Abeni luca.ab...@unitn.it Manuel Lauss manuel.la...@gmail.com Mark Brown broo...@kernel.org Markos Chandras markos.chand...@imgtec.com Michal Hocko mho...@suse.cz Mike Galbraith umgwanakikb...@gmail.com Mikulas Patocka mpato...@redhat.com Naoya Horiguchi n-horigu...@ah.jp.nec.com Pavel Hofman pavel.hof...@ivitera.com Peter Ujfalusi peter.ujfal...@ti.com Peter Zijlstra (Intel) pet...@infradead.org Peter Zijlstra pet...@infradead.org Ralf Baechle r...@linux-mips.org
Re: [Xen-devel] dom0 kernel - irq nobody cared ... the continuing saga ..
On 09/02/15 15:03, Sander Eikelenboom wrote: Hi Jan / David / Konrad, I was just testing a 3.19 kernel on my intel machine and again ran into the sporadically appearing irq nobody cared on the dom0 kernel. This occurs now for quite some kernel versions (running xen-unstable now, but it also appeared in the past with builds that are now xen-4.5). I wouldn't suspect anything Xen related here. IRQ #18 is a shared line-level interrupt so other driver/device that was/is sharing than line is misbehaving. I'd recommend seeing if your BIOS has a option to put the disk controllers into AHCI mode which would allow them to use MSIs (I think). David ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 0/2] libxl: fix handling of fd and timer registrations
Anthony PERARD wrote: On Mon, Feb 02, 2015 at 05:00:34PM -0700, Jim Fehlig wrote: This small series fixes some assertions we occasionally see in the libxl driver when running libvirt-TCK. The assertions were due to races between destroying per-domain libxl_ctx and receiving fd and timer callbacks associated with them. The races are masked by setting DEBUG loglevel in libvirtd.conf, so often missed by automated test setups that want DEBUG loglevel. Patch 1 actually fixes the assertions. Patch2 fixes a stupid mistake. See the commit messages for details. Jim Fehlig (2): libxl: fix fd and timer event handling libxl: Move setup of child processing code to driver initialization src/libxl/libxl_domain.c | 244 +-- src/libxl/libxl_driver.c | 212 +++- 2 files changed, 212 insertions(+), 244 deletions(-) Hi Jim, I gave a try to those two patches with OpenStack. Assuming I haven't make any mistake, it make things worse. Thanks Anthony. I've cooked up a simpler reproducer and will investigate. I do think these patches are an improvement, but they've obviously uncovered a locking issue in the driver. Regards, Jim Environment: Ubuntu 14.04 with Xen package install (xen 4.4) libvirt: master (47dd6c4) Installed OpenStack via DevStack Test: ./run_tempest.sh tempest.api.compute Result: without the patches, the tests run fine, they all succeed. with the patches, the tests fail AND libvirt became unresponsible. Running `virsh -c xen: list` does not return. (or any virsh command) I have attach a backtrace, if that can help. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [qemu-upstream-unstable test] 34319: regressions - FAIL
flight 34319 qemu-upstream-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/34319/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-freebsd10-i386 11 guest-localmigrate fail REGR. vs. 33488 test-amd64-i386-freebsd10-amd64 11 guest-localmigrate fail REGR. vs. 33488 test-amd64-i386-xl-win7-amd64 10 guest-localmigrate fail REGR. vs. 33488 test-amd64-amd64-xl-winxpsp3 10 guest-localmigratefail REGR. vs. 33488 test-amd64-amd64-xl-win7-amd64 10 guest-localmigrate fail REGR. vs. 33488 test-amd64-i386-xl-winxpsp3-vcpus1 10 guest-localmigrate fail REGR. vs. 33488 test-amd64-i386-xl-winxpsp3 10 guest-localmigratefail REGR. vs. 33488 test-amd64-i386-rhel6hvm-amd 6 leak-check/basis(6) running in 34247 [st=running!] Tests which are failing intermittently (not blocking): test-amd64-i386-pair 17 guest-migrate/src_host/dst_host fail pass in 34247 Regressions which are regarded as allowable (not blocking): test-amd64-i386-libvirt 9 guest-start fail like 33488 test-amd64-i386-xl-qemuu-debianhvm-amd64 10 guest-localmigrate fail REGR. vs. 33488 test-amd64-amd64-xl-qemuu-debianhvm-amd64 10 guest-localmigrate fail REGR. vs. 33488 test-amd64-amd64-xl-qemuu-ovmf-amd64 10 guest-localmigrate fail REGR. vs. 33488 test-amd64-i386-xl-qemuu-win7-amd64 10 guest-localmigrate fail REGR. vs. 33488 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 10 guest-localmigrate fail REGR. vs. 33488 test-amd64-i386-xl-qemuu-winxpsp3 10 guest-localmigrate fail REGR. vs. 33488 test-amd64-i386-xl-qemuu-ovmf-amd64 10 guest-localmigrate fail REGR. vs. 33488 test-amd64-amd64-xl-qemuu-win7-amd64 10 guest-localmigrate fail REGR. vs. 33488 test-amd64-amd64-xl-qemuu-winxpsp3 10 guest-localmigrate fail REGR. vs. 33488 test-armhf-armhf-xl-multivcpu 14 leak-check/check fail in 34247 blocked in 33488 test-armhf-armhf-libvirt 13 guest-destroy fail in 34247 blocked in 33488 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pvh-intel 9 guest-start fail never pass test-armhf-armhf-xl-sedf-pin 10 migrate-support-checkfail never pass test-armhf-armhf-xl-sedf 10 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 10 migrate-support-checkfail never pass test-armhf-armhf-xl 10 migrate-support-checkfail never pass test-armhf-armhf-libvirt 10 migrate-support-checkfail never pass test-amd64-amd64-xl-pvh-amd 9 guest-start fail never pass test-armhf-armhf-xl-midway 10 migrate-support-checkfail never pass test-amd64-amd64-libvirt 10 migrate-support-checkfail never pass test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-armhf-armhf-xl-credit2 5 xen-boot fail never pass test-amd64-i386-xl-qemut-winxpsp3 14 guest-stopfail never pass test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop fail never pass version targeted for testing: qemuube11dc1e9172f91e798a8f831b30c14b479e08e8 baseline version: qemuu0d37748342e29854db7c9f6c47d7f58c6cfba6b2 People who touched revisions under test: Don Slutz dsl...@verizon.com Paul Durrant paul.durr...@citrix.com Stefano Stabellini stefano.stabell...@eu.citrix.com jobs: build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-amd64-xl-pvh-amd fail test-amd64-i386-rhel6hvm-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass
Re: [Xen-devel] [PATCH 3/4] libxl: event handling: ao_inprogress does waits while reports outstanding
On Mon, Feb 09, 2015 at 03:51:11PM +, Ian Jackson wrote:
libxl__ao_inprogress needs to check (like
libxl__ao_complete_check_progress_reports) that there are no
oustanding progress callbacks.
Otherwise it might happen that we would destroy the ao while another
thread has an outstanding callback its egc report queue. The other
thread would then, in its egc_run_callbacks, touch the destroyed ao.
Instead, when this happens in libxl__ao_inprogress, simply run round
the event loop again. The thread which eventually makes the callback
will spot our poller in the ao, and notify the poller, waking us up.
This fixes an assertion failure race seen with libvirt:
libvirtd: libxl_event.c:1792: libxl__ao_complete_check_progress_reports:
Assertion `ao-in_initiator' failed.
or (after Add an assert to egc_run_callbacks)
libvirtd: libxl_event.c:1338: egc_run_callbacks: Assertion `aop-ao-magic
== 0xA0FACE00ul' failed.
Signed-off-by: Ian Jackson ian.jack...@eu.citrix.com
CC: Ian Campbell ian.campb...@citrix.com
CC: Wei Liu wei.l...@citrix.com
CC: Jim Fehlig jfeh...@suse.com
Acked-by: Wei Liu wei.l...@citrix.com
---
tools/libxl/libxl_event.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index 89ca6d2..595da2b 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -1878,7 +1878,7 @@ int libxl__ao_inprogress(libxl__ao *ao,
for (;;) {
assert(ao-magic == LIBXL__AO_MAGIC);
-if (ao-complete) {
+if (!ao_work_outstanding(ao)) {
rc = ao-rc;
ao-notified = 1;
break;
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V2] x86 spinlock: Fix memory corruption on completing completions
Ccing Davidlohr, (sorry that I got confused with similar address in cc
list).
On 02/09/2015 08:44 PM, Oleg Nesterov wrote:
On 02/09, Raghavendra K T wrote:
+static inline void __ticket_check_and_clear_slowpath(arch_spinlock_t *lock)
+{
+ arch_spinlock_t old, new;
+ __ticket_t diff;
+
+ old.tickets = READ_ONCE(lock-tickets);
+ diff = (old.tickets.tail ~TICKET_SLOWPATH_FLAG) - old.tickets.head;
+
+ /* try to clear slowpath flag when there are no contenders */
+ if ((old.tickets.tail TICKET_SLOWPATH_FLAG)
+ (diff == TICKET_LOCK_INC)) {
+ new = old;
+ new.tickets.tail = ~TICKET_SLOWPATH_FLAG;
+ cmpxchg(lock-head_tail, old.head_tail, new.head_tail);
+ }
+}
Can't we simplify it? We own .head, and we already know it. We only need
to clear TICKET_SLOWPATH_FLAG in .tail atomically?
IOW,
static inline void __ticket_check_and_clear_slowpath(arch_spinlock_t
*lock, __ticket_t head)
{
__ticket_t old_tail, new_tail;
new_tail = head + TICKET_LOCK_INC;
old_tail = new_tail | TICKET_SLOWPATH_FLAG;
if (READ_ONCE(lock-tickets.tail) == old_tail)
cmpxchg(lock-tickets.tail, old_tail, new_tail);
}
Plus
- __ticket_check_and_clear_slowpath(lock);
+ __ticket_check_and_clear_slowpath(lock, inc.tail);
Or I missed something?
Thanks.. Perfect, 'll update with this change. (Jeremy had hinted
similar).
And I think it would be better to avoid ifdef(CONFIG_PARAVIRT_SPINLOCKS),
ww can just do
if (TICKET_SLOWPATH_FLAG)
__ticket_check_and_clear_slowpath();
Okay.
While at it, I think current arch_spin_unlock() has similar structure
and wanted to clean it up. considering we define
TICKET_SLOWPATH_FLAG 0 or 1, I think compiler would be smart enough
to generate appropriate code and we could avoid #ifdef.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] dom0 kernel - irq nobody cared ... the continuing saga ..
Hi Jan / David / Konrad, I was just testing a 3.19 kernel on my intel machine and again ran into the sporadically appearing irq nobody cared on the dom0 kernel. This occurs now for quite some kernel versions (running xen-unstable now, but it also appeared in the past with builds that are now xen-4.5). [ 1905.880200] irq 18: nobody cared (try booting with the irqpoll option) [ 1905.914838] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.19.0-creanuc-20150209-doflr+ #1 [ 1905.935473] Hardware name: /D53427RKE, BIOS RKPPT10H.86A.0017.2013.0425.1251 04/25/2013 [ 1905.956149] 8800596ae88c 81897311 8800596ae800 [ 1905.976929] 81081554 8800596ae800 [ 1905.997906] 81081961 0012 [ 1906.018751] Call Trace: [ 1906.039416] IRQ [81897311] ? dump_stack+0x40/0x50 [ 1906.060678] [81081554] ? __report_bad_irq+0x1e/0xbb [ 1906.081953] [81081961] ? note_interrupt+0x1a9/0x234 [ 1906.102733] [8107fac7] ? handle_irq_event_percpu+0xd7/0xf1 [ 1906.122995] [8107fb18] ? handle_irq_event+0x37/0x57 [ 1906.143275] [8108224a] ? handle_fasteoi_irq+0x74/0xcb [ 1906.163455] [8107f4b2] ? generic_handle_irq+0x15/0x20 [ 1906.182889] [813a6b0b] ? evtchn_fifo_handle_events+0x138/0x16f [ 1906.202356] [813a48c9] ? __xen_evtchn_do_upcall+0x39/0x69 [ 1906.222156] [813a5c41] ? xen_evtchn_do_upcall+0x27/0x36 [ 1906.241987] [818a015e] ? xen_do_hypervisor_callback+0x1e/0x30 [ 1906.261917] EOI [810013aa] ? xen_hypercall_sched_op+0xa/0x20 [ 1906.282116] [810013aa] ? xen_hypercall_sched_op+0xa/0x20 [ 1906.302364] [81007138] ? xen_safe_halt+0xc/0x13 [ 1906.322525] [81013ae1] ? default_idle+0x5/0x8 [ 1906.342592] [81078b8a] ? cpu_startup_entry+0x114/0x25e [ 1906.362771] [81efee9d] ? start_kernel+0x422/0x42d [ 1906.383029] [81efe880] ? set_init_arg+0x50/0x50 [ 1906.402921] [81f019a0] ? xen_start_kernel+0x4d3/0x4db [ 1906.422483] handlers: [ 1906.441717] [8155cd42] ata_bmdma_interrupt [ 1906.461174] Disabling IRQ #18 Is there any thing i could do / dump when this occurs or patch the kernel to auto dump something to hopefully find out where this sporadic issue comes from ? Because previous attempts didn't seem to deliver any useful data, but i can't trigger it, so probably i have to partly rely on hooking it up to the code that leads to the irq nobody cared message, but probably on far less then 20 iterations for it to contain something sensible. The funky part is that this time it's the ata device with on ssd attached, however i can still read and write normally (so it doesn't seem to need the irq ?) /proc/interrupts shows the high count: CPU0 CPU1 CPU2 CPU3 8: 0 0 0 0 xen-pirq-ioapic-edge rtc0 9: 1 0 0 0 xen-pirq-ioapic-level acpi 16: 29 0 0 0 xen-pirq-ioapic-level ehci_hcd:usb3 18: 20 0 0 0 xen-pirq-ioapic-level ata_generic 23: 23145 0 0 0 xen-pirq-ioapic-level ehci_hcd:usb4 24: 111697 0 0 0 xen-percpu-virq timer0 25: 0 0 0 0 xen-percpu-ipi spinlock0 26: 12989 0 0 0 xen-percpu-ipi resched0 27: 1123 0 0 0 xen-percpu-ipi callfunc0 28: 0 0 0 0 xen-percpu-virq debug0 29:330 0 0 0 xen-percpu-ipi callfuncsingle0 30: 1 0 0 0 xen-percpu-ipi irqwork0 31: 0 25012 0 0 xen-percpu-virq timer1 32: 0 1 0 0 xen-percpu-ipi spinlock1 33: 0 20107 0 0 xen-percpu-ipi resched1 34: 0 2232 0 0 xen-percpu-ipi callfunc1 35: 0 0 0 0 xen-percpu-virq debug1 36: 0426 0 0 xen-percpu-ipi callfuncsingle1 37: 0 0 0 0 xen-percpu-ipi irqwork1 38: 0 0 82595 0 xen-percpu-virq timer2 39: 0 0 0 0 xen-percpu-ipi spinlock2 40: 0 0 83192 0 xen-percpu-ipi resched2 41: 0 0 1295 0 xen-percpu-ipi callfunc2 42: 0 0 0 0 xen-percpu-virq debug2 43: 0 0372 0 xen-percpu-ipi callfuncsingle2 44: 0 0
Re: [Xen-devel] [PATCH 4/4] libxl: More probably detect reentry of destroyed ctx
On Mon, Feb 09, 2015 at 03:51:12PM +, Ian Jackson wrote:
In libxl_ctx_free:
1. Move the GC_INIT earlier, so that we can:
2. Take the lock around most of the work. This is technically
unnecessary since calling any other libxl entrypoint on a ctx being
passed to libxl_ctx_free risks undefined behaviour. But, taking
the lock allows us to much more usually spot this.
3. Increment osevent_in_hook by 1000. If we are reentered after
destroy, this will trip some of our entrypoints' asserts. It also
means that if we crash for some other reason relating to reentering
a destroyed ctx, the cause will be more obviously visible by
examining ctx-osevent_in_hook (assuming that the memory previously
used for the ctx hasn't been reused and overwritten).
4. Free the lock again. (pthread_mutex_destroy requires that the
mutex be unlocked.)
With this patch, I find that an occasional race previously reported
as:
libvirtd: libxl_internal.h:3265: libxl__ctx_unlock: Assertion `!r' failed.
is now reported as:
libvirtd: libxl_event.c:1236: libxl_osevent_occurred_fd: Assertion
`!libxl__gc_owner(gc)-osevent_in_hook' failed.
Examining the call trace with gdb shows this:
(gdb) bt
#0 0xb773f424 in __kernel_vsyscall ()
#1 0xb7022871 in raise () from /lib/i386-linux-gnu/i686/nosegneg/libc.so.6
#2 0xb7025d62 in abort () from /lib/i386-linux-gnu/i686/nosegneg/libc.so.6
#3 0xb701b958 in __assert_fail () from
/lib/i386-linux-gnu/i686/nosegneg/libc.so.6
#4 0xb6f00390 in libxl_osevent_occurred_fd (ctx=0xb84813a8,
for_libxl=0xb84d6848, fd=31, events_ign=0, revents_ign=1) at
libxl_event.c:1236
#5 0xb1b70464 in libxlDomainObjFDEventCallback () from
/usr/local/lib/libvirt/connection-driver/libvirt_driver_libxl.so
#6 0xb72163b1 in virEventPollDispatchHandles () from
/usr/local/lib/libvirt.so.0
#7 0xb7216be5 in virEventPollRunOnce () from /usr/local/lib/libvirt.so.0
#8 0xb7214a7e in virEventRunDefaultImpl () from /usr/local/lib/libvirt.so.0
#9 0xb77c7b98 in virNetServerRun ()
#10 0xb7771c63 in main ()
(gdb) print ctx-osevent_in_hook
$2 = 1000
(gdb)
which IMO demonstrates that libxl_osevent_occurred_fd is being called
on a destroyed ctx.
This is probably a symptom of the bug in libvirt fixed by these
patches:
https://www.redhat.com/archives/libvir-list/2015-February/msg00024.html
Signed-off-by: Ian Jackson ian.jack...@eu.citrix.com
CC: Ian Campbell ian.campb...@citrix.com
CC: Wei Liu wei.l...@citrix.com
CC: Jim Fehlig jfeh...@suse.com
Acked-by: Wei Liu wei.l...@citrix.com
---
tools/libxl/libxl.c |7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index cd6f42c..de75ac4 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -146,11 +146,13 @@ int libxl_ctx_free(libxl_ctx *ctx)
{
if (!ctx) return 0;
-assert(!ctx-osevent_in_hook);
-
int i;
GC_INIT(ctx);
+CTX_LOCK;
+assert(!ctx-osevent_in_hook);
+CTX-osevent_in_hook += 1000;
+
It would be good if you add comment here to say this is used to help
debugging.
Wei.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V2] x86 spinlock: Fix memory corruption on completing completions
On 02/09, Raghavendra K T wrote:
+static inline void __ticket_check_and_clear_slowpath(arch_spinlock_t *lock)
+{
+ arch_spinlock_t old, new;
+ __ticket_t diff;
+
+ old.tickets = READ_ONCE(lock-tickets);
+ diff = (old.tickets.tail ~TICKET_SLOWPATH_FLAG) - old.tickets.head;
+
+ /* try to clear slowpath flag when there are no contenders */
+ if ((old.tickets.tail TICKET_SLOWPATH_FLAG)
+ (diff == TICKET_LOCK_INC)) {
+ new = old;
+ new.tickets.tail = ~TICKET_SLOWPATH_FLAG;
+ cmpxchg(lock-head_tail, old.head_tail, new.head_tail);
+ }
+}
Can't we simplify it? We own .head, and we already know it. We only need
to clear TICKET_SLOWPATH_FLAG in .tail atomically?
IOW,
static inline void __ticket_check_and_clear_slowpath(arch_spinlock_t
*lock, __ticket_t head)
{
__ticket_t old_tail, new_tail;
new_tail = head + TICKET_LOCK_INC;
old_tail = new_tail | TICKET_SLOWPATH_FLAG;
if (READ_ONCE(lock-tickets.tail) == old_tail)
cmpxchg(lock-tickets.tail, old_tail, new_tail);
}
Plus
- __ticket_check_and_clear_slowpath(lock);
+ __ticket_check_and_clear_slowpath(lock, inc.tail);
Or I missed something?
And I think it would be better to avoid ifdef(CONFIG_PARAVIRT_SPINLOCKS),
ww can just do
if (TICKET_SLOWPATH_FLAG)
__ticket_check_and_clear_slowpath();
Oleg.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] dom0 kernel - irq nobody cared ... the continuing saga ..
Monday, February 9, 2015, 4:18:15 PM, you wrote: On 09/02/15 15:03, Sander Eikelenboom wrote: Hi Jan / David / Konrad, I was just testing a 3.19 kernel on my intel machine and again ran into the sporadically appearing irq nobody cared on the dom0 kernel. This occurs now for quite some kernel versions (running xen-unstable now, but it also appeared in the past with builds that are now xen-4.5). I wouldn't suspect anything Xen related here. IRQ #18 is a shared line-level interrupt so other driver/device that was/is sharing than line is misbehaving. I'd recommend seeing if your BIOS has a option to put the disk controllers into AHCI mode which would allow them to use MSIs (I think). David There seems to be an bios update so that's worth a shot. -- Sander ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/4] libxl: event handling: Add an assert to egc_run_callbacks
On Mon, Feb 09, 2015 at 03:51:09PM +, Ian Jackson wrote: Check that the ao is still live when we are about to running some of its callbacks. This reveals an existing bug in libxl which is exercised by libvirt, converting libvirtd: libxl_event.c:1792: libxl__ao_complete_check_progress_reports: Assertion `ao-in_initiator' failed. into libvirtd: libxl_event.c:1338: egc_run_callbacks: Assertion `aop-ao-magic == 0xA0FACE00ul' failed. Signed-off-by: Ian Jackson ian.jack...@eu.citrix.com CC: Ian Campbell ian.campb...@citrix.com CC: Wei Liu wei.l...@citrix.com CC: Jim Fehlig jfeh...@suse.com Acked-by: Wei Liu wei.l...@citrix.com --- tools/libxl/libxl_event.c |1 + 1 file changed, 1 insertion(+) diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c index 0d874d9..ae73728 100644 --- a/tools/libxl/libxl_event.c +++ b/tools/libxl/libxl_event.c @@ -1335,6 +1335,7 @@ static void egc_run_callbacks(libxl__egc *egc) aop-how-callback(CTX, aop-ev, aop-how-for_callback); CTX_LOCK; +assert(aop-ao-magic == LIBXL__AO_MAGIC); aop-ao-progress_reports_outstanding--; libxl__ao_complete_check_progress_reports(egc, aop-ao); CTX_UNLOCK; -- 1.7.10.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] dom0 kernel - irq nobody cared ... the continuing saga ..
On 09.02.15 at 16:18, david.vra...@citrix.com wrote: On 09/02/15 15:03, Sander Eikelenboom wrote: Hi Jan / David / Konrad, I was just testing a 3.19 kernel on my intel machine and again ran into the sporadically appearing irq nobody cared on the dom0 kernel. This occurs now for quite some kernel versions (running xen-unstable now, but it also appeared in the past with builds that are now xen-4.5). I wouldn't suspect anything Xen related here. IRQ #18 is a shared line-level interrupt so other driver/device that was/is sharing than line is misbehaving. I'd recommend seeing if your BIOS has a option to put the disk controllers into AHCI mode which would allow them to use MSIs (I think). But iirc previous instances weren't always pointing at a disk controller, and hence dealing with that as a special case won't make the underlying problem go away. Sander, this looking different from previous reports of yours - is this different (or differently configured) hardware now? In which case knowing what other devices sit on that same IRQ would (again) be necessary, including which of them you pass to guests. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 4/4] libxl: More probably detect reentry of destroyed ctx
In libxl_ctx_free:
1. Move the GC_INIT earlier, so that we can:
2. Take the lock around most of the work. This is technically
unnecessary since calling any other libxl entrypoint on a ctx being
passed to libxl_ctx_free risks undefined behaviour. But, taking
the lock allows us to much more usually spot this.
3. Increment osevent_in_hook by 1000. If we are reentered after
destroy, this will trip some of our entrypoints' asserts. It also
means that if we crash for some other reason relating to reentering
a destroyed ctx, the cause will be more obviously visible by
examining ctx-osevent_in_hook (assuming that the memory previously
used for the ctx hasn't been reused and overwritten).
4. Free the lock again. (pthread_mutex_destroy requires that the
mutex be unlocked.)
With this patch, I find that an occasional race previously reported
as:
libvirtd: libxl_internal.h:3265: libxl__ctx_unlock: Assertion `!r' failed.
is now reported as:
libvirtd: libxl_event.c:1236: libxl_osevent_occurred_fd: Assertion
`!libxl__gc_owner(gc)-osevent_in_hook' failed.
Examining the call trace with gdb shows this:
(gdb) bt
#0 0xb773f424 in __kernel_vsyscall ()
#1 0xb7022871 in raise () from /lib/i386-linux-gnu/i686/nosegneg/libc.so.6
#2 0xb7025d62 in abort () from /lib/i386-linux-gnu/i686/nosegneg/libc.so.6
#3 0xb701b958 in __assert_fail () from
/lib/i386-linux-gnu/i686/nosegneg/libc.so.6
#4 0xb6f00390 in libxl_osevent_occurred_fd (ctx=0xb84813a8,
for_libxl=0xb84d6848, fd=31, events_ign=0, revents_ign=1) at libxl_event.c:1236
#5 0xb1b70464 in libxlDomainObjFDEventCallback () from
/usr/local/lib/libvirt/connection-driver/libvirt_driver_libxl.so
#6 0xb72163b1 in virEventPollDispatchHandles () from
/usr/local/lib/libvirt.so.0
#7 0xb7216be5 in virEventPollRunOnce () from /usr/local/lib/libvirt.so.0
#8 0xb7214a7e in virEventRunDefaultImpl () from /usr/local/lib/libvirt.so.0
#9 0xb77c7b98 in virNetServerRun ()
#10 0xb7771c63 in main ()
(gdb) print ctx-osevent_in_hook
$2 = 1000
(gdb)
which IMO demonstrates that libxl_osevent_occurred_fd is being called
on a destroyed ctx.
This is probably a symptom of the bug in libvirt fixed by these
patches:
https://www.redhat.com/archives/libvir-list/2015-February/msg00024.html
Signed-off-by: Ian Jackson ian.jack...@eu.citrix.com
CC: Ian Campbell ian.campb...@citrix.com
CC: Wei Liu wei.l...@citrix.com
CC: Jim Fehlig jfeh...@suse.com
---
tools/libxl/libxl.c |7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index cd6f42c..de75ac4 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -146,11 +146,13 @@ int libxl_ctx_free(libxl_ctx *ctx)
{
if (!ctx) return 0;
-assert(!ctx-osevent_in_hook);
-
int i;
GC_INIT(ctx);
+CTX_LOCK;
+assert(!ctx-osevent_in_hook);
+CTX-osevent_in_hook += 1000;
+
/* Deregister all libxl__ev_KINDs: */
free_disable_deaths(gc, CTX-death_list);
@@ -196,6 +198,7 @@ int libxl_ctx_free(libxl_ctx *ctx)
libxl__sigchld_notneeded(gc);
libxl__pipe_close(ctx-sigchld_selfpipe);
+CTX_UNLOCK;
pthread_mutex_destroy(ctx-lock);
GC_FREE;
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 1/4] libxl: event handling: Add an assert to egc_run_callbacks
Check that the ao is still live when we are about to running some of its callbacks. This reveals an existing bug in libxl which is exercised by libvirt, converting libvirtd: libxl_event.c:1792: libxl__ao_complete_check_progress_reports: Assertion `ao-in_initiator' failed. into libvirtd: libxl_event.c:1338: egc_run_callbacks: Assertion `aop-ao-magic == 0xA0FACE00ul' failed. Signed-off-by: Ian Jackson ian.jack...@eu.citrix.com CC: Ian Campbell ian.campb...@citrix.com CC: Wei Liu wei.l...@citrix.com CC: Jim Fehlig jfeh...@suse.com --- tools/libxl/libxl_event.c |1 + 1 file changed, 1 insertion(+) diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c index 0d874d9..ae73728 100644 --- a/tools/libxl/libxl_event.c +++ b/tools/libxl/libxl_event.c @@ -1335,6 +1335,7 @@ static void egc_run_callbacks(libxl__egc *egc) aop-how-callback(CTX, aop-ev, aop-how-for_callback); CTX_LOCK; +assert(aop-ao-magic == LIBXL__AO_MAGIC); aop-ao-progress_reports_outstanding--; libxl__ao_complete_check_progress_reports(egc, aop-ao); CTX_UNLOCK; -- 1.7.10.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 2/4] libxl: event handling: Break out ao_work_outstanding
Break out the test in libxl__ao_complete_check_progress_reports, into
ao_work_outstanding, which reports false if either (i) the ao is still
ongoing or (ii) there is a progress report (perhaps on a different
thread's callback queue) which has yet to be reported to the
application.
No functional change.
Signed-off-by: Ian Jackson ian.jack...@eu.citrix.com
CC: Ian Campbell ian.campb...@citrix.com
CC: Wei Liu wei.l...@citrix.com
CC: Jim Fehlig jfeh...@suse.com
---
tools/libxl/libxl_event.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index ae73728..89ca6d2 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -1773,19 +1773,25 @@ void libxl__ao_complete(libxl__egc *egc, libxl__ao *ao,
int rc)
libxl__ao_complete_check_progress_reports(egc, ao);
}
-void libxl__ao_complete_check_progress_reports(libxl__egc *egc, libxl__ao *ao)
+static bool ao_work_outstanding(libxl__ao *ao)
{
/*
* We don't consider an ao complete if it has any outstanding
* callbacks. These callbacks might be outstanding on other
* threads, queued up in the other threads' egc's. Those threads
* will, after making the callback, take out the lock again,
- * decrement progress_reports_outstanding, and call us again.
+ * decrement progress_reports_outstanding, and call
+ * libxl__ao_complete_check_progress_reports.
*/
+return !ao-complete || ao-progress_reports_outstanding;
+}
+
+void libxl__ao_complete_check_progress_reports(libxl__egc *egc, libxl__ao *ao)
+{
libxl_ctx *ctx = libxl__gc_owner(egc-gc);
assert(ao-progress_reports_outstanding = 0);
-if (!ao-complete || ao-progress_reports_outstanding)
+if (ao_work_outstanding(ao))
return;
if (ao-poller) {
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 3/4] libxl: event handling: ao_inprogress does waits while reports outstanding
libxl__ao_inprogress needs to check (like
libxl__ao_complete_check_progress_reports) that there are no
oustanding progress callbacks.
Otherwise it might happen that we would destroy the ao while another
thread has an outstanding callback its egc report queue. The other
thread would then, in its egc_run_callbacks, touch the destroyed ao.
Instead, when this happens in libxl__ao_inprogress, simply run round
the event loop again. The thread which eventually makes the callback
will spot our poller in the ao, and notify the poller, waking us up.
This fixes an assertion failure race seen with libvirt:
libvirtd: libxl_event.c:1792: libxl__ao_complete_check_progress_reports:
Assertion `ao-in_initiator' failed.
or (after Add an assert to egc_run_callbacks)
libvirtd: libxl_event.c:1338: egc_run_callbacks: Assertion `aop-ao-magic ==
0xA0FACE00ul' failed.
Signed-off-by: Ian Jackson ian.jack...@eu.citrix.com
CC: Ian Campbell ian.campb...@citrix.com
CC: Wei Liu wei.l...@citrix.com
CC: Jim Fehlig jfeh...@suse.com
---
tools/libxl/libxl_event.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index 89ca6d2..595da2b 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -1878,7 +1878,7 @@ int libxl__ao_inprogress(libxl__ao *ao,
for (;;) {
assert(ao-magic == LIBXL__AO_MAGIC);
-if (ao-complete) {
+if (!ao_work_outstanding(ao)) {
rc = ao-rc;
ao-notified = 1;
break;
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [libvirt test] 34168: tolerable all pass - PUSHED
Ian Campbell wrote:
Jim,
Thought you might like to know that we are now testing actually starting
a guest with libvirt in osstest and this is the first pass.
Nice! I'll keep an eye out for any regressions.
Currently we don't test migration (which is why that appears to have
failed), but Wei is working on addressing that.
Thanks. Let me know if you encounter any issues.
Regards,
Jim
Ian.
On Thu, 2015-02-05 at 14:40 +, xen.org wrote:
flight 34168 libvirt real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/34168/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-libvirt 10 migrate-support-checkfail never
pass
test-armhf-armhf-libvirt 10 migrate-support-checkfail never
pass
test-amd64-amd64-libvirt 10 migrate-support-checkfail never
pass
version targeted for testing:
libvirt fdb80ed4f6563928b9942a0d1450e0c725aa6c06
baseline version:
libvirt b38da58423f44035e259e18a35853c16267ec83a
People who touched revisions under test:
Chen Hanxiao chenhanx...@cn.fujitsu.com
Luyao Huang lhu...@redhat.com
Pavel Hrdina phrd...@redhat.com
Peter Krempa pkre...@redhat.com
jobs:
build-amd64 pass
build-armhf pass
build-i386 pass
build-amd64-libvirt pass
build-armhf-libvirt pass
build-i386-libvirt pass
build-amd64-pvopspass
build-armhf-pvopspass
build-i386-pvops pass
test-amd64-amd64-libvirt pass
test-armhf-armhf-libvirt pass
test-amd64-i386-libvirt pass
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images
Logs, config files, etc. are available at
http://www.chiark.greenend.org.uk/~xensrcts/logs
Test harness code can be found at
http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary
Pushing revision :
+ branch=libvirt
+ revision=fdb80ed4f6563928b9942a0d1450e0c725aa6c06
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{Repos} or die $!;
'
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push libvirt
fdb80ed4f6563928b9942a0d1450e0c725aa6c06
+ branch=libvirt
+ revision=fdb80ed4f6563928b9942a0d1450e0c725aa6c06
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{Repos} or die $!;
'
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!='
x/export/home/osstest/repos/lock ']'
+ . cri-common
++ . cri-getconfig
++ umask 002
+ select_xenbranch
+ case $branch in
+ tree=libvirt
+ xenbranch=xen-unstable
+ '[' xlibvirt = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ : tested/2.6.39.x
+ . ap-common
++ : osst...@xenbits.xensource.com
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xensource.com:/home/xen/git/xen.git
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://libvirt.org/libvirt.git
++ : osst...@xenbits.xensource.com:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
getconfig GitCacheProxy
perl -e '
use Osstest;
Re: [Xen-devel] [PATCH v3 13/13] xen/iommu: smmu: Advertise when the SMMU support coherent table walk
On 10/02/2015 09:36, Julien Grall wrote:
Hi Stefano,
On 06/02/2015 22:06, Stefano Stabellini wrote:
On Fri, 30 Jan 2015, Julien Grall wrote:
When SMMU doesn't support coherent table walk, Xen may need to clean
updated PT (see commit 4c5f4cb xen/arm: p2m: Clean cache PT when the
IOMMU doesn't support coherent walk).
If one SMMU of the platform doesn't support coherent table walk, the
feature is disabled for the whole platform. This is because device is
assigned to a domain after the page table are populated.
This could impact performance on domain which doesn't use device
passthrough. But, as the spec strongly recommends the support of this
feature for maintstream platform, I expect server will always have SMMUs
supporting coherent table walk. If not, we may need to enable this
feature
per-domain.
Signed-off-by: Julien Grall julien.gr...@linaro.org
---
I've just noticed that the support on the previous driver (i.e in
Xen 4.5) may incorrectly expose this feature when all the SMMUs is
not supporting coherent table walk.
I'm not sure, if I should send a patch for it.
Also I didn't squash this patch into xen/iommu: smmu: Add Xen
specific
code to be able to use the driver to help for review and to catch
possible error in this patch.
Changes in v3:
- Patch added
---
xen/drivers/passthrough/arm/smmu.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/xen/drivers/passthrough/arm/smmu.c
b/xen/drivers/passthrough/arm/smmu.c
index 373eee8..f4c7e49 100644
--- a/xen/drivers/passthrough/arm/smmu.c
+++ b/xen/drivers/passthrough/arm/smmu.c
@@ -577,6 +577,13 @@ struct arm_smmu_domain {
spinlock_tlock;
};
+/*
+ * Xen: Platform features. It indicates the list of features support
by all the
+ * SMMUs.
+ * Actually we only care about coherent table walk.
+ */
+static u32 platform_features = ARM_SMMU_FEAT_COHERENT_WALK;
+
/* Xen: Dummy iommu_domain */
struct iommu_domain
{
@@ -2810,6 +2817,13 @@ static int arm_smmu_iommu_domain_init(struct
domain *d)
domain_hvm_iommu(d)-arch.priv = xen_domain;
+/*
+ * The feature coherent walk can be enabled only when all SMMUs
+ * support it.
+ */
+if (platform_features ARM_SMMU_FEAT_COHERENT_WALK)
+iommu_set_feature(d, IOMMU_FEAT_COHERENT_WALK);
+
return 0;
}
As long as you are sure that arm_smmu_iommu_domain_init is called after
all the iommus have been initialized by arm_smmu_dt_init, then this
patch is correct.
We don't support SMMU hotplug on Xen :). All the SMMUs are initialize
via iommu_setup before DOM0 is created.
Though, I could update the commit message to explain it.
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 3/9] xen: arm: Handle 32-bit EL0 on 64-bit EL1 when advancing PC after trap
Hi Ian,
On 10/02/2015 12:45, Ian Campbell wrote:
Signed-off-by: Ian Campbell ian.campb...@citrix.com
Reviewed-by: Julien Grall julien.gr...@linaro.org
---
xen/arch/arm/traps.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index c5f65db..be65862 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -1487,7 +1487,7 @@ static int check_conditional_instr(struct cpu_user_regs
*regs, union hsr hsr)
{
unsigned long it;
-BUG_ON( !is_32bit_domain(current-domain) || !(cpsrPSR_THUMB) );
+BUG_ON( !psr_mode_is_32bit(regs-cpsr) || !(cpsrPSR_THUMB) );
it = ( (cpsr (10-2)) 0xfc) | ((cpsr 25) 0x3 );
@@ -1496,7 +1496,7 @@ static int check_conditional_instr(struct cpu_user_regs
*regs, union hsr hsr)
return 1;
/* The cond for this instruction works out as the top 4 bits. */
-cond = ( it 4 );
+cond = ( it 4 );
I haven't spot it in the previous review. This seems to be only a coding
change. Could you specify it in the commit message?
Regards,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 3/9] xen: arm: Handle 32-bit EL0 on 64-bit EL1 when advancing PC after trap
On Tue, 2015-02-10 at 13:44 +0800, Julien Grall wrote: /* The cond for this instruction works out as the top 4 bits. */ -cond = ( it 4 ); +cond = ( it 4 ); I haven't spot it in the previous review. This seems to be only a coding change. Could you specify it in the commit message? Sigh, this level of pedantry isn't really helpful IMHO. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 4/9] xen: arm: correctly handle vtimer traps from userspace
Hi Ian,
On 10/02/2015 12:45, Ian Campbell wrote:
Previously 32-bit userspace on 32-bit kernel and 64-bit userspace on 64-bit
kernel could access these registers irrespective of whether the kernel had
configured them to be allowed to. To fix this:
- Userspace access to CNTP_CTL_EL0 and CNTP_TVAL_EL0 should be gated on
CNTKCTL_EL1.EL0PTEN.
Should not we take care of CNTP_CVAL_EL0 too? It seems that we don't
even trap it for now...
[..]
@@ -2062,8 +2053,7 @@ asmlinkage void do_trap_hypervisor(struct cpu_user_regs
*regs)
do_cp15_32(regs, hsr);
break;
case HSR_EC_CP15_64:
-if ( !is_32bit_domain(current-domain) )
-goto bad_trap;
+BUG_ON(!psr_mode_is_32bit(regs-cpsr));
You should mention the change from if ( ) goto bad_trap to BUG_ON(
... ) in the commit message.
Although, I think the debug message in bad_trap is useful to keep. It
may be handy to have the HSR and the guest stack trace printed if Xen
hit the condition.
[..]
@@ -238,7 +250,7 @@ static int vtimer_emulate_cp64(struct cpu_user_regs *regs,
union hsr hsr)
switch ( hsr.bits HSR_CP64_REGS_MASK )
{
case HSR_CPREG64(CNTPCT):
-if (!vtimer_cntpct(regs, x, cp64.read))
+if ( !vtimer_cntpct(regs, x, cp64.read) )
I would mention the coding style change in the commit message.
Regards,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] question about memory allocation for driver domain
On 09/02/2015 20:02, Oleksandr Tyshchenko wrote: On Mon, Feb 9, 2015 at 10:31 AM, Julien Grall julien.gr...@linaro.org wrote: On 07/02/2015 01:15, Oleksandr Tyshchenko wrote: Hi Julien Hi Oleksandr, On Thu, Feb 5, 2015 at 6:36 PM, Oleksandr Tyshchenko The next problem is ballooning. When the guest balloon out memory, the page will be freed by Xen and can be re-used by another domain. When guest balloon in, Xen will allocate a page (randomly) and therefore the mapping won't be anymore IPA (guest physical address) == PA (physical address). Any DMA request using this address will read/write data from wrong memory. Is it possible to disable ballon driver for domd? I think updating is_domain_direct_mapped is enough here. We won't support memory hotplug for this kind of domain. The last problem but not the least is, depending on which backend you are running in the 1:1 domain (such blkback), grant won't be mapped 1:1 to the guest, so you will have to use swiotlb in order to use the right DMA address. For instance, without swiotlb, guest won't be able to use a disk partition via blkfront. This because the backend is giving directly the grant address to the block driver. To solve this, we have to use swiotlb and set specific DMA callback. For now, there are only used for DOM0. We are using SWIOTLB for domd too. Good :). Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 6/9] xen: arm: Handle CP14 32-bit register accesses from userspace
On 10/02/2015 11:40, Ian Campbell wrote: On Wed, 2014-09-10 at 10:48 +0100, Ian Campbell wrote: On Tue, 2014-09-09 at 16:45 -0700, Julien Grall wrote: Hi Ian, On 09/09/14 09:23, Ian Campbell wrote: Accesses to these from 32-bit userspace would cause a hypervisor exception (host crash) when running a 64-bit kernel, which is worked around by the fix to XSA-102. On 32-bit kernels they would be implemented as RAZ/WI which is incorrect but harmless. Update as follows: - DBGDSCRINT should be R/O. - DBGDSCREXT should be EL1 only. - DBGOSLAR is RO and EL1 only. - DBGVCR, DBGB[VC]R*, DBGW[VC]R*, and DBGOSDLR are EL1 only. DBGDIDR and DBGDSCRINT are accessible from EL0 if DBGDSCRext.UDCCdis. Since we emulate that as RAZ/WI we allow access. Shall we just set DBGDSCRext.UDCCdis to avoid taking care of EL0 access? I'd need to lookup what the acceptable reset states for that bit are, but perhaps. The AArch32 version of this bit resets to 0, so I think the code is OK as it is, at least for now. I'd like to implement proper handling of dbg registers sooner rather than later, but I think this series should go in first and the the dbg stuff can be built on it later. I'm fine with that. Let's have a 32-bit userspace support on 64-bit kernel before :). Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] freemem-slack and large memory environments
Hi, While testing commit 2563bca1, I found that libxl_get_free_memory returns 0 until there is more free memory than required for freemem-slack. This means that during the domain creation process, freed memory is first set aside for freemem-slack, then marked as truly free for consumption. On machines with large amounts of memory, freemem-slack can be very high (26GB on a 2TB test machine). If freeing this memory takes more time than allowed during domain startup, domain creation fails with ERROR_NOMEM. (Commit 2563bca1 doesn't help here, as free_memkb remains 0 until freemem-slack is satisfied.) There is already a 15% limit on the size of freemem-slack (commit a39b5bc6), but this does not take into consideration very large memory environments. (26GB is only 1.2% of 2TB), where this limit is not hit. It seems that there are two approaches to resolve this: - Introduce a hard limit on freemem-slack to avoid unnecessarily large reservations - Increase the retry count during domain creation to ensure enough time is set aside for any cycles spent freeing memory for freemem-slack (on the test machine, doubling the retry count to 6 is the minimum required) Which is the best approach (or did I miss something)? Thanks! Mike ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RFC] xen: arm: context switch vtimer PPI state.
Stefano,
do you have any comments on the viability of the general approach here
before I go off and start addressing the review comments?
Cheers,
Ian.
On Mon, 2015-01-26 at 15:55 +, Ian Campbell wrote:
... instead of artificially masking the timer interrupt in the timer
state and relying on the guest to unmask (which it isn't required to
do per the h/w spec, although Linux does)
To do this introduce the concept of routing a PPI to the currently
running VCPU. For such interrupts irq_get_domain returns NULL.
Then we make use of the GICD I[SC]ACTIVER registers to save and
restore the active state of the interrupt, which prevents the nested
invocations which the current masking works around.
For edge triggered interrupts we also need to context switch the
pending bit via I[SC]PENDR. Note that for level triggered interrupts
SPENDR sets a latch which is only cleared by ICPENDR (and not by h/w
state changes), therefore we do not want to context switch the pending
state for level PPIs -- instead we rely on the context switch of the
peripheral to restore the correct level.
RFC Only:
- Not implemented for GIC v3 yet.
- Lightly tested with hackbench on systems with level and edge
triggered vtimer PPI.
- Is irq_get_domain == NULL to indicate route-to-current-vcpu the
best idea? Any alternatives?
Signed-off-by: Ian Campbell ian.campb...@citrix.com
---
xen/arch/arm/gic-v2.c| 84
++
xen/arch/arm/gic.c | 32 +---
xen/arch/arm/irq.c | 48 ++--
xen/arch/arm/time.c | 26 +
xen/arch/arm/vtimer.c| 24 ++--
xen/include/asm-arm/domain.h | 11 ++
xen/include/asm-arm/gic.h| 14 +++
xen/include/asm-arm/irq.h|1 +
8 files changed, 204 insertions(+), 36 deletions(-)
diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index 31fb81a..9074aca 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -156,6 +156,45 @@ static void gicv2_save_state(struct vcpu *v)
writel_gich(0, GICH_HCR);
}
+static void gicv2_save_and_mask_hwppi(struct vcpu *v, const unsigned virq,
+ struct hwppi_state *s)
+{
+struct pending_irq *p = irq_to_pending(v, virq);
+const unsigned int offs = virq / 32;
+const unsigned int mask = (1u (virq % 32));
+const unsigned int pendingr = readl_gicd(GICD_ISPENDR + offs*4);
+const unsigned int activer = readl_gicd(GICD_ISACTIVER + offs*4);
+const unsigned int enabler = readl_gicd(GICD_ISENABLER + offs*4);
+const bool is_edge = !!(p-desc-arch.type DT_IRQ_TYPE_EDGE_BOTH);
+
+ASSERT(!is_idle_vcpu(v));
+
+s-active = !!(activer mask);
+s-enabled = !!(enabler mask);
+s-pending = !!(pendingr mask);
+s-inprogress = test_and_clear_bit(_IRQ_INPROGRESS, p-desc-status);
+
+/* Write a 1 to IC...R to clear the corresponding bit of state */
+if ( s-active )
+writel_gicd(mask, GICD_ICACTIVER + offs*4);
+/*
+ * For an edge interrupt clear the pending state, for a level interrupt
+ * this clears the latch there is no need since saving the peripheral
state
+ * (and/or restoring the next VCPU) will cause the correct action.
+ */
+if ( is_edge s-pending )
+writel_gicd(mask, GICD_ICPENDR + offs*4);
+
+if ( s-enabled )
+{
+writel_gicd(mask, GICD_ICENABLER + offs*4);
+set_bit(_IRQ_DISABLED, p-desc-status);
+}
+
+ASSERT(!(readl_gicd(GICD_ISACTIVER + offs*4) mask));
+ASSERT(!(readl_gicd(GICD_ISENABLER + offs*4) mask));
+}
+
static void gicv2_restore_state(const struct vcpu *v)
{
int i;
@@ -168,6 +207,49 @@ static void gicv2_restore_state(const struct vcpu *v)
writel_gich(GICH_HCR_EN, GICH_HCR);
}
+static void gicv2_restore_hwppi(struct vcpu *v, const unsigned virq,
+const struct hwppi_state *s)
+{
+struct pending_irq *p = irq_to_pending(v, virq);
+const unsigned int offs = virq / 32;
+const unsigned int mask = (1u (virq % 32));
+struct irq_desc *desc = irq_to_desc(virq);
+const bool is_edge = !!(desc-arch.type DT_IRQ_TYPE_EDGE_BOTH);
+struct pending_irq *pending = irq_to_pending(v, virq);
+
+pending-desc = desc; /* Migrate to new physical processor */
+
+/*
+ * The IRQ must always have been set inactive and masked etc by
+ * the saving of the previous state via save_and_mask_hwppi.
+ */
+ASSERT(!(readl_gicd(GICD_ISACTIVER + offs*4) mask));
+ASSERT(!(readl_gicd(GICD_ISENABLER + offs*4) mask));
+
+if ( s-active )
+writel_gicd(mask, GICD_ICACTIVER + offs*4);
+
+/*
+ * Restore pending state for edge triggered interrupts only. For
+ * level triggered interrupts the level will be restored as
+ * necessary by restoring the
Re: [Xen-devel] [PATCH RFC V2 4/5] xl: add pvusb commands
On 01/19/2015 09:28 AM, Chunyan Liu wrote:
Add pvusb commands.
To attach a usb device to guest through pvusb, one could follow
following example:
#xl usb-ctrl-attach test_vm version=1 num_ports=8
#xl usb-list test_vm
will show the usb controllers and port usage under the domain.
#xl usb-assignable-list
will list all assignable usb devices now in host, with their
sysfs interface. (This is very useful since later we will use
sysfs interface to attach a usb devie to guest)
#xl usb-attach test_vm 2-1.1
will find the first usable controller:port, and attach usb
device with sysfs interface 2-1.1 (sys/bus/usb/devices/2-1.1)
to it. One could also specify which controller and which port
#xl usb-detach test_vm 2-1.1
#xl usb-ctrl-detach test_vm dev_id
will destroy the controller with dev_id as specified. Dev_id
can be traced in usb-list info
Sorry for late review.
Some comments inline.
Signed-off-by: Chunyan Liu cy...@suse.com
Signed-off-by: Simon Cao caobosi...@gmail.com
---
tools/libxl/xl.h | 6 ++
tools/libxl/xl_cmdimpl.c | 256 ++
tools/libxl/xl_cmdtable.c | 30 ++
3 files changed, 292 insertions(+)
diff --git a/tools/libxl/xl.h b/tools/libxl/xl.h
index 5bc138c..f37a99f 100644
--- a/tools/libxl/xl.h
+++ b/tools/libxl/xl.h
@@ -86,6 +86,12 @@ int main_blockdetach(int argc, char **argv);
int main_vtpmattach(int argc, char **argv);
int main_vtpmlist(int argc, char **argv);
int main_vtpmdetach(int argc, char **argv);
+int main_usbassignable_list(int argc, char **argv);
+int main_usbctrl_attach(int argc, char **argv);
+int main_usbctrl_detach(int argc, char **argv);
+int main_usbattach(int argc, char **argv);
+int main_usbdetach(int argc, char **argv);
+int main_usblist(int argc, char **argv);
int main_uptime(int argc, char **argv);
int main_claims(int argc, char **argv);
int main_tmem_list(int argc, char **argv);
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 0b02a6c..a28f460 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -3000,6 +3000,262 @@ int main_cd_insert(int argc, char **argv)
return 0;
}
+static void usbinfo_print(libxl_device_usb *usbs, int num) {
+int i;
+if ( usbs == NULL )
+ return;
+libxl_usbinfo usbinfo;
+for (i = 0; i num; i++) {
+/* TO BE Improved */
+if (usbs[i].port )
+printf(Port %d:, usbs[i].port);
+printf(Interface %8s , usbs[i].intf);
+if (!libxl_device_usb_getinfo(ctx, usbs[i].intf, usbinfo)) {
+printf(Bus %03d Dev %03d: %04d:%04d %s %s\n,
+usbinfo.bus, usbinfo.devnum, usbinfo.idVendor,
+usbinfo.idProduct, usbinfo.manuf, usbinfo.prod);
+}
+libxl_usbinfo_dispose(usbinfo);
+}
+}
+
+
+static void usb_assignable_list(void)
+{
+libxl_device_usb *usbs;
+int num;
+
+usbs = libxl_device_usb_assignable_list(ctx, num);
+
+usbinfo_print(usbs, num);
+
+free(usbs);
+}
+
+int main_usbassignable_list(int argc, char **argv)
+{
+int opt;
+
+SWITCH_FOREACH_OPT(opt, , NULL, usb-assignable-list, 0) {
+/* No options */
+}
+
+usb_assignable_list();
+return 0;
+}
+
+int main_usbctrl_attach(int argc, char **argv)
+{
+uint32_t domid;
+int opt;
+char *oparg;
+libxl_device_usbctrl usbctrl;
+
+SWITCH_FOREACH_OPT(opt, , NULL, usb-controller-attach, 1) {
Should be usb-ctrl-attach.
+/* No options */
+}
+
+domid = find_domain(argv[optind++]);
+
+libxl_device_usbctrl_init(usbctrl);
+
+while (argc = optind) {
argc optind?
+if (MATCH_OPTION(type, argv[optind], oparg)) {
+if (!strcmp(pv, oparg)) {
+usbctrl.type = LIBXL_USBCTRL_TYPE_PV;
+} else if(!strcmp(ioemu, oparg)) {
+usbctrl.type = LIBXL_USBCTRL_TYPE_DEVICEMODEL;
+} else {
+fprintf(stderr, Invalid parameter `type'.\n);
+exit(-1);
+}
+} else if (MATCH_OPTION(version, argv[optind], oparg)) {
+usbctrl.usb_version = atoi(oparg);
+} else if (MATCH_OPTION(num_ports, argv[optind], oparg)) {
+usbctrl.num_ports = atoi(oparg);
+} else {
+fprintf(stderr, unrecognized argument `%s'\n, argv[optind]);
+exit(-1);
+}
+optind++;
+}
+
+if (dryrun_only) {
+ char* json = libxl_device_usbctrl_to_json(ctx, usbctrl);
+ printf(usb controller: %s\n, json);
+ free(json);
+ libxl_device_usbctrl_dispose(usbctrl);
+ if (ferror(stdout) || fflush(stdout)) {
+ perror(stdout);
+ exit(-1);
+ }
+ return 0;
+}
+
+if (libxl_device_usbctrl_add(ctx, domid, usbctrl, 0)) {
+fprintf(stderr, libxl_device_usbctrl_add failed.\n);
+exit(-1);
+}
+libxl_device_usbctrl_dispose(usbctrl);
+return 0;
Re: [Xen-devel] [PATCH v3 13/13] xen/iommu: smmu: Advertise when the SMMU support coherent table walk
Hi Stefano,
On 06/02/2015 22:06, Stefano Stabellini wrote:
On Fri, 30 Jan 2015, Julien Grall wrote:
When SMMU doesn't support coherent table walk, Xen may need to clean
updated PT (see commit 4c5f4cb xen/arm: p2m: Clean cache PT when the
IOMMU doesn't support coherent walk).
If one SMMU of the platform doesn't support coherent table walk, the
feature is disabled for the whole platform. This is because device is
assigned to a domain after the page table are populated.
This could impact performance on domain which doesn't use device
passthrough. But, as the spec strongly recommends the support of this
feature for maintstream platform, I expect server will always have SMMUs
supporting coherent table walk. If not, we may need to enable this feature
per-domain.
Signed-off-by: Julien Grall julien.gr...@linaro.org
---
I've just noticed that the support on the previous driver (i.e in
Xen 4.5) may incorrectly expose this feature when all the SMMUs is
not supporting coherent table walk.
I'm not sure, if I should send a patch for it.
Also I didn't squash this patch into xen/iommu: smmu: Add Xen specific
code to be able to use the driver to help for review and to catch
possible error in this patch.
Changes in v3:
- Patch added
---
xen/drivers/passthrough/arm/smmu.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/xen/drivers/passthrough/arm/smmu.c
b/xen/drivers/passthrough/arm/smmu.c
index 373eee8..f4c7e49 100644
--- a/xen/drivers/passthrough/arm/smmu.c
+++ b/xen/drivers/passthrough/arm/smmu.c
@@ -577,6 +577,13 @@ struct arm_smmu_domain {
spinlock_t lock;
};
+/*
+ * Xen: Platform features. It indicates the list of features support by all the
+ * SMMUs.
+ * Actually we only care about coherent table walk.
+ */
+static u32 platform_features = ARM_SMMU_FEAT_COHERENT_WALK;
+
/* Xen: Dummy iommu_domain */
struct iommu_domain
{
@@ -2810,6 +2817,13 @@ static int arm_smmu_iommu_domain_init(struct domain *d)
domain_hvm_iommu(d)-arch.priv = xen_domain;
+ /*
+* The feature coherent walk can be enabled only when all SMMUs
+* support it.
+*/
+ if (platform_features ARM_SMMU_FEAT_COHERENT_WALK)
+ iommu_set_feature(d, IOMMU_FEAT_COHERENT_WALK);
+
return 0;
}
As long as you are sure that arm_smmu_iommu_domain_init is called after
all the iommus have been initialized by arm_smmu_dt_init, then this
patch is correct.
We don't support SMMU hotplug on Xen :). All the SMMUs are initialize
via iommu_setup before DOM0 is created.
Regards,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 6/9] xen: arm: Handle CP14 32-bit register accesses from userspace
On Wed, 2014-09-10 at 10:48 +0100, Ian Campbell wrote: On Tue, 2014-09-09 at 16:45 -0700, Julien Grall wrote: Hi Ian, On 09/09/14 09:23, Ian Campbell wrote: Accesses to these from 32-bit userspace would cause a hypervisor exception (host crash) when running a 64-bit kernel, which is worked around by the fix to XSA-102. On 32-bit kernels they would be implemented as RAZ/WI which is incorrect but harmless. Update as follows: - DBGDSCRINT should be R/O. - DBGDSCREXT should be EL1 only. - DBGOSLAR is RO and EL1 only. - DBGVCR, DBGB[VC]R*, DBGW[VC]R*, and DBGOSDLR are EL1 only. DBGDIDR and DBGDSCRINT are accessible from EL0 if DBGDSCRext.UDCCdis. Since we emulate that as RAZ/WI we allow access. Shall we just set DBGDSCRext.UDCCdis to avoid taking care of EL0 access? I'd need to lookup what the acceptable reset states for that bit are, but perhaps. The AArch32 version of this bit resets to 0, so I think the code is OK as it is, at least for now. I'd like to implement proper handling of dbg registers sooner rather than later, but I think this series should go in first and the the dbg stuff can be built on it later. Ian. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 12/13] xen/iommu: smmu: Add Xen specific code to be able to use the driver
Hi Stefano,
On 06/02/2015 21:20, Stefano Stabellini wrote:
On Fri, 30 Jan 2015, Julien Grall wrote:
-static int force_stage;
-module_param_named(force_stage, force_stage, int, S_IRUGO | S_IWUSR);
-MODULE_PARM_DESC(force_stage,
- Force SMMU mappings to be installed at a particular stage of translation. A
value of '1' or '2' forces the corresponding stage. All other values are ignored (i.e. no
stage is forced). Note that selecting a specific stage will disable support for nested
translation.);
for the sake of minimizing the diff, I would add
#define module_param_named(a, b, c, d)
#define MODULE_PARM_DESC(a, b)
to the Xen definitions above
We still have to drop force_stage because it will get unused and won't
compile.
So it's not too bad to remove the 2 other lines.
[..]
+static struct iommu_group *iommu_group_get(struct device *dev)
+{
+ struct iommu_group *group = dev_iommu_group(dev);
+
+ if (group)
+ atomic_inc(group-ref);
+
+ return group;
+}
+
+#define iommu_group_get_iommudata(group) (group)-cfg
I would move all the Xen stuff at the beginning of the file or maybe to
a separate file. You could #include the linux smmu driver into it.
Maybe we cannot have runtime patching of this file, but at least we can
keep Xen and Linux stuff clearly separate.
Rather than using a void * in iommu_group, I directly use the real type
(arm_smmu_master_cfg). It's defined a bit earlier.
I would prefer to keep the real type because it's easier to understand
the code and catch possible error.
All the Xen code is beginning with /* Xen: */. Though, I could add a /*
Xen: End */ to make the separation clearer.
static DEFINE_SPINLOCK(arm_smmu_devices_lock);
static LIST_HEAD(arm_smmu_devices);
@@ -455,6 +690,8 @@ static void parse_driver_options(struct arm_smmu_device
*smmu)
static struct device_node *dev_get_dev_node(struct device *dev)
{
+ /* Xen: TODO: Add support for PCI */
+#if 0
if (dev_is_pci(dev)) {
struct pci_bus *bus = to_pci_dev(dev)-bus;
@@ -462,7 +699,7 @@ static struct device_node *dev_get_dev_node(struct device
*dev)
bus = bus-parent;
return bus-bridge-parent-of_node;
}
-
+#endif
Would it be possible instead to add:
#define dev_is_pci (0)
above among the Xen definitions?
dev_is_pci is already defined to 0 (see include/asm-arm/device.h), but
it won't prevent the compiler to check the validity of the code inside...
pci_dev doesn't contain a structure pci_bus on Xen. So it won't compile.
return dev-of_node;
}
@@ -556,6 +793,9 @@ static int register_smmu_master(struct arm_smmu_device
*smmu,
master-of_node = masterspec-np;
master-cfg.num_streamids= masterspec-args_count;
+ /* Xen: Let Xen knows that the device is protected by an SMMU */
+ dt_device_set_protected(masterspec-np);
+
for (i = 0; i master-cfg.num_streamids; ++i) {
u16 streamid = masterspec-args[i];
@@ -651,11 +891,12 @@ static void arm_smmu_tlb_inv_context(struct
arm_smmu_domain *smmu_domain)
arm_smmu_tlb_sync(smmu);
}
-static irqreturn_t arm_smmu_context_fault(int irq, void *dev)
+static void arm_smmu_context_fault(int irq, void *dev,
+ struct cpu_user_regs *regs)
{
- int flags, ret;
+ int flags;
u32 fsr, far, fsynr, resume;
- unsigned long iova;
+ paddr_t iova;
struct iommu_domain *domain = dev;
struct arm_smmu_domain *smmu_domain = domain-priv;
struct arm_smmu_cfg *cfg = smmu_domain-cfg;
@@ -666,7 +907,7 @@ static irqreturn_t arm_smmu_context_fault(int irq, void
*dev)
fsr = readl_relaxed(cb_base + ARM_SMMU_CB_FSR);
if (!(fsr FSR_FAULT))
- return IRQ_NONE;
+ return;
if (fsr FSR_IGN)
dev_err_ratelimited(smmu-dev,
@@ -678,19 +919,16 @@ static irqreturn_t arm_smmu_context_fault(int irq, void
*dev)
far = readl_relaxed(cb_base + ARM_SMMU_CB_FAR_LO);
iova = far;
-#ifdef CONFIG_64BIT
+ /* Xen: The fault address maybe higher than 32 bits on arm32 */
far = readl_relaxed(cb_base + ARM_SMMU_CB_FAR_HI);
- iova |= ((unsigned long)far 32);
-#endif
+ iova |= ((paddr_t)far 32);
if (!report_iommu_fault(domain, smmu-dev, iova, flags)) {
- ret = IRQ_HANDLED;
resume = RESUME_RETRY;
} else {
dev_err_ratelimited(smmu-dev,
- Unhandled context fault: iova=0x%08lx, fsynr=0x%x,
cb=%d\n,
+ Unhandled context fault: iova=0x%PRIpaddr, fsynr=0x%x,
cb=%d\n,
iova, fsynr, cfg-cbndx);
- ret = IRQ_NONE;
resume = RESUME_TERMINATE;
}
@@ -700,11 +938,10 @@ static irqreturn_t arm_smmu_context_fault(int irq, void
*dev)
/* Retry or terminate any
[Xen-devel] [rumpuserxen test] 34346: regressions - FAIL
flight 34346 rumpuserxen real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/34346/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-rumpuserxen6 xen-build fail REGR. vs. 33866 build-amd64-rumpuserxen 6 xen-build fail REGR. vs. 33866 Tests which did not succeed, but are not blocking: test-amd64-amd64-rumpuserxen-amd64 1 build-check(1) blocked n/a test-amd64-i386-rumpuserxen-i386 1 build-check(1) blocked n/a version targeted for testing: rumpuserxen e28e2b9daf7ab2922913889d90ec438b9bee3d56 baseline version: rumpuserxen 30d72f3fc5e35cd53afd82c8179cc0e0b11146ad People who touched revisions under test: Ian Jackson ian.jack...@eu.citrix.com Martin Lucina mar...@lucina.net jobs: build-amd64 pass build-i386 pass build-amd64-pvopspass build-i386-pvops pass build-amd64-rumpuserxen fail build-i386-rumpuserxen fail test-amd64-amd64-rumpuserxen-amd64 blocked test-amd64-i386-rumpuserxen-i386 blocked sg-report-flight on osstest.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. commit e28e2b9daf7ab2922913889d90ec438b9bee3d56 Author: Ian Jackson ian.jack...@eu.citrix.com Date: Wed Feb 4 16:29:26 2015 + app-tools: Support old -D__RUMPUSER_XEN__ for now Released versions of Xen (Xen 4.5) rely on __RUMPUSER_XEN__ being defined. A patch to change this in Xen upstream exists and will be backported, but until that makes it through to a stable point release of Xen 4.5, we should support both #defines. This commit partially reverts 91d56232d987 Renaming platform macros, app-tools and autoconf target string Signed-off-by: Ian Jackson ian.jack...@eu.citrix.com CC: Martin Lucina mar...@lucina.net CC: Ian Campbell ian.campb...@eu.citrix.com CC: Wei Liu wei.l...@citrix.com commit 05e06b0fe52918d6575e33b7d7551d85c93f7aff Author: Martin Lucina mar...@lucina.net Date: Mon Feb 2 18:01:52 2015 +0100 Sync Travis CI configuration with app-tools rename Signed-off-by: Martin Lucina mar...@lucina.net commit 3b36d1f55a08e1849ccd5424afb0fbe29647bd6c Author: Martin Lucina mar...@lucina.net Date: Mon Feb 2 18:00:36 2015 +0100 Remove even older rumpxen-app-* variants of app-tools Signed-off-by: Martin Lucina mar...@lucina.net commit 91d56232d987f5df594723ed46b9000b4d43e21a Author: Martin Lucina mar...@lucina.net Date: Mon Feb 2 17:52:41 2015 +0100 Renaming platform macros, app-tools and autoconf target string As discussed at: http://thread.gmane.org/gmane.comp.rumpkernel.user/739 This commit renames the platform macros, app-tools and autoconf target string to be consistent with current naming of the entire stack: app-tools/rumpapp-xen-* - app-tools/rumprun-xen-* $ARCH-rumpxen-netbsd - $ARCH-rumprun-netbsd -D__RUMPUSER_XEN__ -D__RUMPAPP__ - -D__RUMPRUN__ Signed-off-by: Martin Lucina mar...@lucina.net ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 0/5] multiboot2: Enable EFI boot services usage in loaded images
Hi all, On Fri, Jan 30, 2015 at 06:59:23PM +0100, Daniel Kiper wrote: Hi, This patch series enable EFI boot services usage in loaded images by multiboot2 protocol. Guys, do you have any comments on this patch series? Should I fix something? Could you apply them to GRUB2 tree? Daniel PS Please CC all interested parties. I suppose that there are some people here who are not subscribed to grub-devel list. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC PATCH V3 10/12] xen: Introduce monitor_op domctl
--- a/xen/include/public/hvm/params.h +++ b/xen/include/public/hvm/params.h @@ -162,21 +162,6 @@ */ #define HVM_PARAM_ACPI_IOPORTS_LOCATION 19 -/* Enable blocking memory events, async or sync (pause vcpu until response) - * onchangeonly indicates messages only on a change of value */ -#define HVM_PARAM_MEMORY_EVENT_CR0 20 -#define HVM_PARAM_MEMORY_EVENT_CR3 21 -#define HVM_PARAM_MEMORY_EVENT_CR4 22 -#define HVM_PARAM_MEMORY_EVENT_INT3 23 -#define HVM_PARAM_MEMORY_EVENT_SINGLE_STEP 25 -#define HVM_PARAM_MEMORY_EVENT_MSR 30 I'm not sure if HVM param slots can be re-used. If they can, leaving a note that the deleted numbers are available for re-sue would be nice. If they can't, leaving a note that they shouldn't be re-used would seem mandatory. Jan I'm not sure either if they can be reused, I would assume yes so I'll make the comment accordingly (unless someone knows more and objects). All other comments: Ack. Thanks! Tamas On a second look there seems to be a handful of HVM params that are already undefined, so they don't seem to get recycled. Tamas ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH V4 12/13] xen/xsm: Split vm_event_op into three separate labels
The XSM label vm_event_op has been used to control the three memops
controlling mem_access, mem_paging and mem_sharing. While these systems
rely on vm_event, these are not vm_event operations themselves. Thus,
in this patch we introduce three separate labels for each of these memops.
Signed-off-by: Tamas K Lengyel tamas.leng...@zentific.com
---
xen/arch/x86/mm/mem_paging.c| 2 +-
xen/arch/x86/mm/mem_sharing.c | 2 +-
xen/common/mem_access.c | 2 +-
xen/include/xsm/dummy.h | 20 +++-
xen/include/xsm/xsm.h | 33 ++---
xen/xsm/dummy.c | 13 -
xen/xsm/flask/hooks.c | 33 ++---
xen/xsm/flask/policy/access_vectors | 6 ++
8 files changed, 100 insertions(+), 11 deletions(-)
diff --git a/xen/arch/x86/mm/mem_paging.c b/xen/arch/x86/mm/mem_paging.c
index 9d2cc4c..0856c23 100644
--- a/xen/arch/x86/mm/mem_paging.c
+++ b/xen/arch/x86/mm/mem_paging.c
@@ -40,7 +40,7 @@ int mem_paging_memop(unsigned long cmd,
if ( rc )
return rc;
-rc = xsm_vm_event_op(XSM_DM_PRIV, d, XENMEM_paging_op);
+rc = xsm_mem_paging(XSM_DM_PRIV, d);
if ( rc )
return rc;
diff --git a/xen/arch/x86/mm/mem_sharing.c b/xen/arch/x86/mm/mem_sharing.c
index 612ed89..e3ebc05 100644
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -1316,7 +1316,7 @@ int mem_sharing_memop(unsigned long cmd,
if ( !hap_enabled(d) || !d-arch.hvm_domain.mem_sharing_enabled )
return -ENODEV;
-rc = xsm_vm_event_op(XSM_DM_PRIV, d, XENMEM_sharing_op);
+rc = xsm_mem_sharing(XSM_DM_PRIV, d);
if ( rc )
return rc;
diff --git a/xen/common/mem_access.c b/xen/common/mem_access.c
index a54fe6e..426f766 100644
--- a/xen/common/mem_access.c
+++ b/xen/common/mem_access.c
@@ -48,7 +48,7 @@ int mem_access_memop(unsigned long cmd,
if ( !p2m_mem_access_sanity_check(d) )
goto out;
-rc = xsm_vm_event_op(XSM_DM_PRIV, d, XENMEM_access_op);
+rc = xsm_mem_access(XSM_DM_PRIV, d);
if ( rc )
goto out;
diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index 50ee929..16967ed 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -519,11 +519,29 @@ static XSM_INLINE int
xsm_vm_event_control(XSM_DEFAULT_ARG struct domain *d, int
return xsm_default_action(action, current-domain, d);
}
-static XSM_INLINE int xsm_vm_event_op(XSM_DEFAULT_ARG struct domain *d, int op)
+#ifdef HAS_MEM_ACCESS
+static XSM_INLINE int xsm_mem_access(XSM_DEFAULT_ARG struct domain *d)
{
XSM_ASSERT_ACTION(XSM_DM_PRIV);
return xsm_default_action(action, current-domain, d);
}
+#endif
+
+#ifdef HAS_MEM_PAGING
+static XSM_INLINE int xsm_mem_paging(XSM_DEFAULT_ARG struct domain *d)
+{
+XSM_ASSERT_ACTION(XSM_DM_PRIV);
+return xsm_default_action(action, current-domain, d);
+}
+#endif
+
+#ifdef HAS_MEM_SHARING
+static XSM_INLINE int xsm_mem_sharing(XSM_DEFAULT_ARG struct domain *d)
+{
+XSM_ASSERT_ACTION(XSM_DM_PRIV);
+return xsm_default_action(action, current-domain, d);
+}
+#endif
#ifdef CONFIG_X86
static XSM_INLINE int xsm_do_mca(XSM_DEFAULT_VOID)
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index d56a68f..2a88d84 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -142,7 +142,18 @@ struct xsm_operations {
int (*get_vnumainfo) (struct domain *d);
int (*vm_event_control) (struct domain *d, int mode, int op);
-int (*vm_event_op) (struct domain *d, int op);
+
+#ifdef HAS_MEM_ACCESS
+int (*mem_access) (struct domain *d);
+#endif
+
+#ifdef HAS_MEM_PAGING
+int (*mem_paging) (struct domain *d);
+#endif
+
+#ifdef HAS_MEM_SHARING
+int (*mem_sharing) (struct domain *d);
+#endif
#ifdef CONFIG_X86
int (*do_mca) (void);
@@ -546,10 +557,26 @@ static inline int xsm_vm_event_control (xsm_default_t
def, struct domain *d, int
return xsm_ops-vm_event_control(d, mode, op);
}
-static inline int xsm_vm_event_op (xsm_default_t def, struct domain *d, int op)
+#ifdef HAS_MEM_ACCESS
+static inline int xsm_mem_access (xsm_default_t def, struct domain *d)
{
-return xsm_ops-vm_event_op(d, op);
+return xsm_ops-mem_access(d);
}
+#endif
+
+#ifdef HAS_MEM_PAGING
+static inline int xsm_mem_paging (xsm_default_t def, struct domain *d)
+{
+return xsm_ops-mem_paging(d);
+}
+#endif
+
+#ifdef HAS_MEM_SHARING
+static inline int xsm_mem_sharing (xsm_default_t def, struct domain *d)
+{
+return xsm_ops-mem_sharing(d);
+}
+#endif
#ifdef CONFIG_X86
static inline int xsm_do_mca(xsm_default_t def)
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index 6d12d32..3ddb4f6 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -119,7 +119,18 @@ void xsm_fixup_ops (struct xsm_operations *ops)
set_to_dummy_if_null(ops, map_gmfn_foreign);
set_to_dummy_if_null(ops, vm_event_control);
-
[Xen-devel] [PATCH V4 13/13] xen/vm_event: Add RESUME option to vm_event_op domctl
Thus far mem_access and mem_sharing memops had been able to signal
to Xen to start pulling responses off the corresponding rings. In this patch
we retire these memops and add them to the option to the vm_event_op domctl.
The vm_event_op domctl suboptions are the same for each ring thus we
consolidate them into XEN_VM_EVENT_ENABLE/DISABLE/RESUME.
As part of this patch in libxc we also rename the mem_access_enable/disable
functions to monitor_enable/disable and move them into xc_monitor.c.
Signed-off-by: Tamas K Lengyel tamas.leng...@zentific.com
---
tools/libxc/include/xenctrl.h | 22 ++---
tools/libxc/xc_mem_access.c | 25
tools/libxc/xc_mem_paging.c | 12 ++--
tools/libxc/xc_memshr.c | 15 ++
tools/libxc/xc_monitor.c| 22 +
tools/libxc/xc_vm_event.c | 6 +++---
tools/tests/xen-access/xen-access.c | 12 ++--
xen/arch/x86/mm/mem_sharing.c | 9 -
xen/common/mem_access.c | 9 -
xen/common/vm_event.c | 39 +++--
xen/include/public/domctl.h | 32 ++
xen/include/public/memory.h | 16 +++
12 files changed, 113 insertions(+), 106 deletions(-)
diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 3324132..3042e98 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -2269,6 +2269,7 @@ int xc_tmem_restore_extra(xc_interface *xch, int dom, int
fd);
*/
int xc_mem_paging_enable(xc_interface *xch, domid_t domain_id, uint32_t *port);
int xc_mem_paging_disable(xc_interface *xch, domid_t domain_id);
+int xc_mem_paging_resume(xc_interface *xch, domid_t domain_id);
int xc_mem_paging_nominate(xc_interface *xch, domid_t domain_id,
unsigned long gfn);
int xc_mem_paging_evict(xc_interface *xch, domid_t domain_id, unsigned long
gfn);
@@ -2282,17 +2283,6 @@ int xc_mem_paging_load(xc_interface *xch, domid_t
domain_id,
*/
/*
- * Enables mem_access and returns the mapped ring page.
- * Will return NULL on error.
- * Caller has to unmap this page when done.
- */
-void *xc_mem_access_enable(xc_interface *xch, domid_t domain_id, uint32_t
*port);
-void *xc_mem_access_enable_introspection(xc_interface *xch, domid_t domain_id,
- uint32_t *port);
-int xc_mem_access_disable(xc_interface *xch, domid_t domain_id);
-int xc_mem_access_resume(xc_interface *xch, domid_t domain_id);
-
-/*
* Set a range of memory to a specific access.
* Allowed types are XENMEM_access_default, XENMEM_access_n, any combination of
* XENMEM_access_ + (rwx), and XENMEM_access_rx2rw
@@ -2309,7 +2299,17 @@ int xc_get_mem_access(xc_interface *xch, domid_t
domain_id,
/***
* Monitor control operations.
+ *
+ * Enables the VM event monitor ring and returns the mapped ring page.
+ * This ring is used to deliver mem_access events, as well a set of additional
+ * events that can be enabled with the xc_monitor_* functions.
+ *
+ * Will return NULL on error.
+ * Caller has to unmap this page when done.
*/
+void *xc_monitor_enable(xc_interface *xch, domid_t domain_id, uint32_t *port);
+int xc_monitor_disable(xc_interface *xch, domid_t domain_id);
+int xc_monitor_resume(xc_interface *xch, domid_t domain_id);
int xc_monitor_mov_to_cr0(xc_interface *xch, domid_t domain_id,
unsigned int op, unsigned int sync,
unsigned int onchangeonly);
diff --git a/tools/libxc/xc_mem_access.c b/tools/libxc/xc_mem_access.c
index 37e776c..7050692 100644
--- a/tools/libxc/xc_mem_access.c
+++ b/tools/libxc/xc_mem_access.c
@@ -24,31 +24,6 @@
#include xc_private.h
#include xen/memory.h
-void *xc_mem_access_enable(xc_interface *xch, domid_t domain_id, uint32_t
*port)
-{
-return xc_vm_event_enable(xch, domain_id, HVM_PARAM_MONITOR_RING_PFN,
- port);
-}
-
-int xc_mem_access_disable(xc_interface *xch, domid_t domain_id)
-{
-return xc_vm_event_control(xch, domain_id,
- XEN_VM_EVENT_MONITOR_DISABLE,
- XEN_DOMCTL_VM_EVENT_OP_MONITOR,
- NULL);
-}
-
-int xc_mem_access_resume(xc_interface *xch, domid_t domain_id)
-{
-xen_mem_access_op_t mao =
-{
-.op= XENMEM_access_op_resume,
-.domid = domain_id
-};
-
-return do_memory_op(xch, XENMEM_access_op, mao, sizeof(mao));
-}
-
int xc_set_mem_access(xc_interface *xch,
domid_t domain_id,
xenmem_access_t access,
diff --git a/tools/libxc/xc_mem_paging.c b/tools/libxc/xc_mem_paging.c
index b635a4d..9e64190 100644
--- a/tools/libxc/xc_mem_paging.c
+++ b/tools/libxc/xc_mem_paging.c
@@ -48,7 +48,7 @@ int xc_mem_paging_enable(xc_interface *xch, domid_t domain_id,
}
return
[Xen-devel] [PATCH V4 05/13] xen: Rename mem_event to vm_event
In this patch we mechanically rename mem_event to vm_event. This patch
introduces no logic changes to the code. Using the name vm_event better
describes the intended use of this subsystem, which is not limited to memory
events. It can be used for off-loading the decision making logic into helper
applications when encountering various events during a VM's execution.
Signed-off-by: Tamas K Lengyel tamas.leng...@zentific.com
---
v4: Using git -M option for patch to improve readability
Note that in include/xen/vm_event.h the style problems are fixed in a later
patch in the series so that git can keep track of the relocation here.
---
MAINTAINERS| 4 +-
docs/misc/xsm-flask.txt| 2 +-
tools/libxc/Makefile | 2 +-
tools/libxc/xc_mem_access.c| 16 +-
tools/libxc/xc_mem_paging.c| 18 +-
tools/libxc/xc_memshr.c| 18 +-
tools/libxc/xc_private.h | 12 +-
tools/libxc/{xc_mem_event.c = xc_vm_event.c} | 40 +--
tools/tests/xen-access/xen-access.c| 110
tools/xenpaging/pagein.c | 2 +-
tools/xenpaging/xenpaging.c| 118 -
tools/xenpaging/xenpaging.h| 8 +-
xen/arch/x86/domain.c | 2 +-
xen/arch/x86/domctl.c | 4 +-
xen/arch/x86/hvm/emulate.c | 6 +-
xen/arch/x86/hvm/hvm.c | 46 ++--
xen/arch/x86/hvm/vmx/vmcs.c| 4 +-
xen/arch/x86/mm/hap/nested_ept.c | 4 +-
xen/arch/x86/mm/hap/nested_hap.c | 4 +-
xen/arch/x86/mm/mem_paging.c | 4 +-
xen/arch/x86/mm/mem_sharing.c | 32 +--
xen/arch/x86/mm/p2m-pod.c | 4 +-
xen/arch/x86/mm/p2m-pt.c | 4 +-
xen/arch/x86/mm/p2m.c | 99
xen/arch/x86/x86_64/compat/mm.c| 6 +-
xen/arch/x86/x86_64/mm.c | 6 +-
xen/common/Makefile| 2 +-
xen/common/domain.c| 12 +-
xen/common/domctl.c| 8 +-
xen/common/mem_access.c| 28 +--
xen/common/{mem_event.c = vm_event.c} | 336 -
xen/drivers/passthrough/pci.c | 2 +-
xen/include/asm-arm/p2m.h | 6 +-
xen/include/asm-x86/domain.h | 4 +-
xen/include/asm-x86/hvm/emulate.h | 2 +-
xen/include/asm-x86/p2m.h | 8 +-
xen/include/public/domctl.h| 46 ++--
xen/include/public/{mem_event.h = vm_event.h} | 90 +++
xen/include/xen/mem_access.h | 4 +-
xen/include/xen/p2m-common.h | 4 +-
xen/include/xen/sched.h| 26 +-
xen/include/xen/{mem_event.h = vm_event.h}| 74 +++---
xen/include/xsm/dummy.h| 4 +-
xen/include/xsm/xsm.h | 12 +-
xen/xsm/dummy.c| 4 +-
xen/xsm/flask/hooks.c | 16 +-
xen/xsm/flask/policy/access_vectors| 2 +-
47 files changed, 632 insertions(+), 633 deletions(-)
rename tools/libxc/{xc_mem_event.c = xc_vm_event.c} (79%)
rename xen/common/{mem_event.c = vm_event.c} (59%)
rename xen/include/public/{mem_event.h = vm_event.h} (61%)
rename xen/include/xen/{mem_event.h = vm_event.h} (50%)
diff --git a/MAINTAINERS b/MAINTAINERS
index 3bbac9e..3d09d15 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -361,10 +361,10 @@ F:xen/arch/x86/mm/mem_sharing.c
F: xen/arch/x86/mm/mem_paging.c
F: tools/memshr
-MEMORY EVENT AND ACCESS
+VM EVENT AND MEM ACCESS
M: Tim Deegan t...@xen.org
S: Supported
-F: xen/common/mem_event.c
+F: xen/common/vm_event.c
F: xen/common/mem_access.c
XENTRACE
diff --git a/docs/misc/xsm-flask.txt b/docs/misc/xsm-flask.txt
index 9559028..13ce498 100644
--- a/docs/misc/xsm-flask.txt
+++ b/docs/misc/xsm-flask.txt
@@ -87,7 +87,7 @@ __HYPERVISOR_domctl (xen/include/public/domctl.h)
* XEN_DOMCTL_set_machine_address_size
* XEN_DOMCTL_debug_op
* XEN_DOMCTL_gethvmcontext_partial
- * XEN_DOMCTL_mem_event_op
+ * XEN_DOMCTL_vm_event_op
* XEN_DOMCTL_mem_sharing_op
* XEN_DOMCTL_setvcpuextstate
* XEN_DOMCTL_getvcpuextstate
diff --git a/tools/libxc/Makefile b/tools/libxc/Makefile
index 6fa88c7..22ba2a1 100644
--- a/tools/libxc/Makefile
+++ b/tools/libxc/Makefile
@@ -31,7 +31,7 @@ CTRL_SRCS-y += xc_pm.c
CTRL_SRCS-y += xc_cpu_hotplug.c
CTRL_SRCS-y += xc_resume.c
CTRL_SRCS-y += xc_tmem.c
-CTRL_SRCS-y += xc_mem_event.c
+CTRL_SRCS-y += xc_vm_event.c
CTRL_SRCS-y += xc_mem_paging.c
CTRL_SRCS-y +=
Re: [Xen-devel] Xen's Linux kernel config options v3
On Mon, Feb 09, 2015 at 07:17:23AM +0100, Juergen Gross wrote: On 02/07/2015 12:44 AM, Luis R. Rodriguez wrote: After some feedback for the first draft I'd suggest the following: Option Selects Depends -- XEN XEN_PV(x86) XEN_HAVE_PVMMU(x86) PARAVIRT PARAVIRT_CLOCK XEN_PVH(x86) XEN_PVHVM PARAVIRT PARAVIRT_CLOCK XEN_PVHVM(x86)PARAVIRT PARAVIRT_CLOCK XEN_BACKEND SWIOTLB_XEN(arm,arm64) XEN_PV(x86) || XEN_PVH(x86) || XEN_PVHVM(x86) XEN_TMEM(x86) XEN_PRIVCMD Wrong indentation of above 2 entries I had moved this to select based on Konrad's suggestion that the backend selects this but then Jan noted this is not necessarily true given that there is no connection between these and backend functionality and forgot to move it out under. As such I'll remove both completely from selects -- but its not clear to me that XEN_BACKEND should depend on both as it seems (maybe I misunderstood) you are implying, should it? Do we just want to keep both as is today? Option Selects Depends -- XEN XEN_TMEM(x86) !ARM !ARM64 (default m if CLEANCACHE || FRONTSWAP) XEN_PRIVCMD config XEN_TMEM tristate depends on !ARM !ARM64 default m if (CLEANCACHE || FRONTSWAP) help Shim to interface in-kernel Transcendent Memory hooks (e.g. cleancache and frontswap) to Xen tmem hypercalls. config XEN_PRIVCMD tristate depends on XEN default m We at least remove that explicit 'depneds on XEN' as it is already part of the Kconfig file top level mainmenu, but that's a trivial obvious change. Luis ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v3 6/7] libxl/libxc: Move libxl_get_numainfo()'s hypercall buffer management to libxc
Signed-off-by: Boris Ostrovsky boris.ostrov...@oracle.com
---
tools/libxc/include/xenctrl.h |4 ++-
tools/libxc/xc_misc.c | 29 --
tools/libxl/libxl.c | 36 -
tools/python/xen/lowlevel/xc/xc.c | 39 +++-
4 files changed, 50 insertions(+), 58 deletions(-)
diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index d94571d..4466cd7 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -1228,6 +1228,7 @@ int xc_send_debug_keys(xc_interface *xch, char *keys);
typedef xen_sysctl_physinfo_t xc_physinfo_t;
typedef xen_sysctl_cputopo_t xc_cputopo_t;
typedef xen_sysctl_numainfo_t xc_numainfo_t;
+typedef xen_sysctl_meminfo_t xc_meminfo_t;
typedef uint32_t xc_cpu_to_node_t;
typedef uint32_t xc_cpu_to_socket_t;
@@ -1238,7 +1239,8 @@ typedef uint32_t xc_node_to_node_dist_t;
int xc_physinfo(xc_interface *xch, xc_physinfo_t *info);
int xc_cputopoinfo(xc_interface *xch, int *max_cpus, xc_cputopo_t *cputopo);
-int xc_numainfo(xc_interface *xch, xc_numainfo_t *info);
+int xc_numainfo(xc_interface *xch, int *max_nodes,
+xc_meminfo_t *meminfo, uint8_t *distance);
int xc_sched_id(xc_interface *xch,
int *sched_id);
diff --git a/tools/libxc/xc_misc.c b/tools/libxc/xc_misc.c
index 4c654f3..2dd5e13 100644
--- a/tools/libxc/xc_misc.c
+++ b/tools/libxc/xc_misc.c
@@ -204,22 +204,37 @@ out:
return ret;
}
-int xc_numainfo(xc_interface *xch,
-xc_numainfo_t *put_info)
+int xc_numainfo(xc_interface *xch, int *max_nodes,
+xc_meminfo_t *meminfo, uint8_t *distance)
{
int ret;
DECLARE_SYSCTL;
+DECLARE_HYPERCALL_BOUNCE(meminfo, *max_nodes * sizeof(*meminfo),
+ XC_HYPERCALL_BUFFER_BOUNCE_OUT);
+DECLARE_HYPERCALL_BOUNCE(distance,
+ *max_nodes * *max_nodes * sizeof(*distance),
+ XC_HYPERCALL_BUFFER_BOUNCE_OUT);
-sysctl.cmd = XEN_SYSCTL_numainfo;
+if ((ret = xc_hypercall_bounce_pre(xch, meminfo)))
+goto out;
+if ((ret = xc_hypercall_bounce_pre(xch, distance)))
+goto out;
-memcpy(sysctl.u.numainfo, put_info, sizeof(*put_info));
+sysctl.u.numainfo.max_node_index = *max_nodes - 1;
+set_xen_guest_handle(sysctl.u.numainfo.meminfo, meminfo);
+set_xen_guest_handle(sysctl.u.numainfo.distance, distance);
+sysctl.cmd = XEN_SYSCTL_numainfo;
if ((ret = do_sysctl(xch, sysctl)) != 0)
-return ret;
+goto out;
-memcpy(put_info, sysctl.u.numainfo, sizeof(*put_info));
+*max_nodes = sysctl.u.numainfo.max_node_index + 1;
-return 0;
+out:
+xc_hypercall_bounce_post(xch, meminfo);
+xc_hypercall_bounce_post(xch, distance);
+
+return ret;
}
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index f8d64c2..9c1c949 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -5110,41 +5110,25 @@ libxl_cputopology *libxl_get_cpu_topology(libxl_ctx
*ctx, int *nb_cpu_out)
libxl_numainfo *libxl_get_numainfo(libxl_ctx *ctx, int *nr)
{
GC_INIT(ctx);
-xc_numainfo_t ninfo;
-DECLARE_HYPERCALL_BUFFER(xen_sysctl_meminfo_t, meminfo);
-DECLARE_HYPERCALL_BUFFER(uint8_t, distance);
+xc_meminfo_t *meminfo;
+uint8_t *distance;
libxl_numainfo *ret = NULL;
int i, j, max_nodes;
max_nodes = libxl_get_max_nodes(ctx);
-if (max_nodes 0)
-{
+if (max_nodes 0) {
LIBXL__LOG(ctx, XTL_ERROR, Unable to determine number of NODES);
-ret = NULL;
goto out;
}
-meminfo = xc_hypercall_buffer_alloc(ctx-xch, meminfo, sizeof(*meminfo) *
max_nodes);
-distance = xc_hypercall_buffer_alloc(ctx-xch, distance, sizeof(*distance)
* max_nodes * max_nodes);
-if ((meminfo == NULL) || (distance == NULL)) {
-LIBXL__LOG_ERRNOVAL(ctx, XTL_ERROR, ENOMEM,
-Unable to allocate hypercall arguments);
-goto fail;
-}
+meminfo = libxl__zalloc(gc, sizeof(*meminfo) * max_nodes);
+distance = libxl__zalloc(gc, sizeof(*distance) * max_nodes * max_nodes);
-set_xen_guest_handle(ninfo.meminfo, meminfo);
-set_xen_guest_handle(ninfo.distance, distance);
-ninfo.max_node_index = max_nodes - 1;
-if (xc_numainfo(ctx-xch, ninfo) != 0) {
+if (xc_numainfo(ctx-xch, max_nodes, meminfo, distance) != 0) {
LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, getting numainfo);
-goto fail;
+goto out;
}
-if (ninfo.max_node_index max_nodes - 1)
-max_nodes = ninfo.max_node_index + 1;
-
-*nr = max_nodes;
-
ret = libxl__zalloc(NOGC, sizeof(libxl_numainfo) * max_nodes);
for (i = 0; i max_nodes; i++)
ret[i].dists = libxl__calloc(NOGC, max_nodes, sizeof(*distance));
@@ -5156,13 +5140,11 @@ libxl_numainfo *libxl_get_numainfo(libxl_ctx *ctx, int
*nr)
[Xen-devel] [PATCH v3 7/7] libxl: Add interface for querying hypervisor about PCI topology
.. and use this new interface to display it along with CPU topology
and NUMA information when 'xl info -n' command is issued
The output will look like
...
cpu_topology :
cpu:coresocket node
0: 000
...
device topology:
device node
:00:00.0 0
:00:01.0 0
...
Signed-off-by: Boris Ostrovsky boris.ostrov...@oracle.com
---
tools/libxc/include/xenctrl.h |3 ++
tools/libxc/xc_misc.c | 32 +
tools/libxl/libxl.c | 49 +++
tools/libxl/libxl.h | 14
tools/libxl/libxl_freebsd.c | 14
tools/libxl/libxl_internal.h |5 +++
tools/libxl/libxl_linux.c | 74 +
tools/libxl/libxl_netbsd.c| 14
tools/libxl/libxl_types.idl |7
tools/libxl/libxl_utils.c |8
tools/libxl/xl_cmdimpl.c | 44
11 files changed, 257 insertions(+), 7 deletions(-)
diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 4466cd7..9ba40eb 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -1229,6 +1229,7 @@ typedef xen_sysctl_physinfo_t xc_physinfo_t;
typedef xen_sysctl_cputopo_t xc_cputopo_t;
typedef xen_sysctl_numainfo_t xc_numainfo_t;
typedef xen_sysctl_meminfo_t xc_meminfo_t;
+typedef xen_sysctl_pcitopoinfo_t xc_pcitopoinfo_t;
typedef uint32_t xc_cpu_to_node_t;
typedef uint32_t xc_cpu_to_socket_t;
@@ -1241,6 +1242,8 @@ int xc_physinfo(xc_interface *xch, xc_physinfo_t *info);
int xc_cputopoinfo(xc_interface *xch, int *max_cpus, xc_cputopo_t *cputopo);
int xc_numainfo(xc_interface *xch, int *max_nodes,
xc_meminfo_t *meminfo, uint8_t *distance);
+int xc_pcitopoinfo(xc_interface *xch, int num_devs,
+ physdev_pci_device_t *devs, uint8_t *nodes);
int xc_sched_id(xc_interface *xch,
int *sched_id);
diff --git a/tools/libxc/xc_misc.c b/tools/libxc/xc_misc.c
index 2dd5e13..a8266d7 100644
--- a/tools/libxc/xc_misc.c
+++ b/tools/libxc/xc_misc.c
@@ -204,6 +204,38 @@ out:
return ret;
}
+int xc_pcitopoinfo(xc_interface *xch, int num_devs,
+ physdev_pci_device_t *devs,
+ uint8_t *nodes)
+{
+int ret;
+DECLARE_SYSCTL;
+DECLARE_HYPERCALL_BOUNCE(devs, num_devs * sizeof(*devs),
+ XC_HYPERCALL_BUFFER_BOUNCE_IN);
+DECLARE_HYPERCALL_BOUNCE(nodes, num_devs* sizeof(*nodes),
+ XC_HYPERCALL_BUFFER_BOUNCE_OUT);
+
+if ((ret = xc_hypercall_bounce_pre(xch, devs)))
+goto out;
+if ((ret = xc_hypercall_bounce_pre(xch, nodes)))
+goto out;
+
+sysctl.u.pcitopoinfo.first_dev = 0;
+sysctl.u.pcitopoinfo.num_devs = num_devs;
+set_xen_guest_handle(sysctl.u.pcitopoinfo.devs, devs);
+set_xen_guest_handle(sysctl.u.pcitopoinfo.nodes, nodes);
+
+sysctl.cmd = XEN_SYSCTL_pcitopoinfo;
+
+ret = do_sysctl(xch, sysctl);
+
+ out:
+xc_hypercall_bounce_post(xch, devs);
+xc_hypercall_bounce_post(xch, nodes);
+
+return ret;
+}
+
int xc_numainfo(xc_interface *xch, int *max_nodes,
xc_meminfo_t *meminfo, uint8_t *distance)
{
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 9c1c949..c3b6c8a 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -5107,6 +5107,55 @@ libxl_cputopology *libxl_get_cpu_topology(libxl_ctx
*ctx, int *nb_cpu_out)
return ret;
}
+#ifdef LIBXL_HAVE_PCITOPO
+libxl_pcitopology *libxl_get_pci_topology(libxl_ctx *ctx, int *num_devs)
+{
+GC_INIT(ctx);
+physdev_pci_device_t *devs;
+uint8_t *nodes;
+libxl_pcitopology *ret = NULL;
+int i, rc;
+
+*num_devs = libxl__pci_numdevs(gc);
+if (*num_devs = 0) {
+LOG(ERROR, Unable to determine number of PCI devices);
+goto out;
+}
+
+devs = libxl__zalloc(gc, sizeof(*devs) * *num_devs);
+nodes = libxl__zalloc(gc, sizeof(*nodes) * *num_devs);
+if (devs == NULL || nodes == NULL) {
+LOGEV(ERROR, ENOMEM, Unable to allocate hypercall arguments);
+goto out;
+}
+
+rc = libxl__pci_topology_init(gc, devs, *num_devs);
+if (rc) {
+LOGEV(ERROR, rc, Cannot initialize PCI hypercall structure);
+goto out;
+}
+
+if (xc_pcitopoinfo(ctx-xch, *num_devs, devs, nodes) != 0) {
+LOGE(ERROR, PCI topology info hypercall failed);
+goto out;
+}
+
+ret = libxl__zalloc(NOGC, sizeof(libxl_pcitopology) * *num_devs);
+
+for (i = 0; i *num_devs; i++) {
+ret[i].seg = devs[i].seg;
+ret[i].bus = devs[i].bus;
+ret[i].devfn = devs[i].devfn;
+ret[i].node = (nodes[i] == INVALID_NODE_ID) ?
+LIBXL_PCITOPOLOGY_INVALID_ENTRY : nodes[i];
+}
+
+ out:
+GC_FREE;
+return ret;
+}
+#endif
+
libxl_numainfo *libxl_get_numainfo(libxl_ctx *ctx, int *nr)
{
GC_INIT(ctx);
diff
[Xen-devel] [PATCH v3 0/7] Display IO topology when PXM data is available (plus some cleanup)
Changes in v3: * Added patch #1 to more consistently define nodes as a u8 and properly use NUMA_NO_NODE. * Make changes to xen_sysctl_numainfo, similar to those made to xen_sysctl_topologyinfo. (Q: I kept both sets of changes in the same patch #3 to avoid bumping interface version twice. Perhaps it's better to split it into two?) * Instead of copying data for each loop index allocate a buffer and copy once for all three queries in sysctl.c. * Move hypercall buffer management from libxl to libxc (as requested by Dario, patches #5 and #6). * Report topology info for offlined CPUs as well * Added LIBXL_HAVE_PCITOPO macro Changes in v2: * Split topology sysctls into two --- one for CPU topology and the other for devices * Avoid long loops in the hypervisor by using continuations. (I am not particularly happy about using first_dev in the interface, suggestions for a better interface would be appreciated) * Use proper libxl conventions for interfaces * Avoid hypervisor stack corruption when copying PXM data from guest A few patches that add interface for querying hypervisor about device topology and allow 'xl info -n' display this information if PXM object is provided by ACPI. This series also makes some optimizations and cleanup of current CPU topology and NUMA sysctl queries. Boris Ostrovsky (7): x86/numa: Make use of NUMA_NO_NODE consistent pci: Do not ignore device's PXM information sysctl: Make topologyinfo and numainfo sysctls a little more efficient sysctl: Add sysctl interface for querying PCI topology libxl/libxc: Move libxl_get_cpu_topology()'s hypercall buffer management to libxc libxl/libxc: Move libxl_get_numainfo()'s hypercall buffer management to libxc libxl: Add interface for querying hypervisor about PCI topology tools/libxc/include/xenctrl.h | 11 ++- tools/libxc/xc_misc.c | 84 --- tools/libxl/libxl.c | 152 - tools/libxl/libxl.h | 14 +++ tools/libxl/libxl_freebsd.c | 14 +++ tools/libxl/libxl_internal.h|5 + tools/libxl/libxl_linux.c | 74 tools/libxl/libxl_netbsd.c | 14 +++ tools/libxl/libxl_types.idl |7 + tools/libxl/libxl_utils.c |8 ++ tools/libxl/xl_cmdimpl.c| 44 ++- tools/misc/xenpm.c | 92 ++- tools/python/xen/lowlevel/xc/xc.c | 103 ++--- xen/arch/x86/physdev.c | 23 - xen/arch/x86/smpboot.c |2 +- xen/arch/x86/srat.c | 39 --- xen/arch/x86/x86_64/mm.c|2 +- xen/common/sysctl.c | 214 ++- xen/drivers/passthrough/pci.c | 13 ++- xen/drivers/passthrough/vtd/iommu.c |4 +- xen/include/asm-x86/numa.h |4 +- xen/include/public/physdev.h|6 + xen/include/public/sysctl.h | 104 - xen/include/xen/pci.h |5 +- 24 files changed, 698 insertions(+), 340 deletions(-) ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v3 4/7] sysctl: Add sysctl interface for querying PCI topology
Signed-off-by: Boris Ostrovsky boris.ostrov...@oracle.com
---
xen/common/sysctl.c | 73 +++
xen/include/public/sysctl.h | 29 +
2 files changed, 102 insertions(+), 0 deletions(-)
diff --git a/xen/common/sysctl.c b/xen/common/sysctl.c
index 30c5806..ea6557f 100644
--- a/xen/common/sysctl.c
+++ b/xen/common/sysctl.c
@@ -384,7 +384,80 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t)
u_sysctl)
xfree(cputopo);
}
break;
+#ifdef HAS_PCI
+case XEN_SYSCTL_pcitopoinfo:
+{
+xen_sysctl_pcitopoinfo_t *ti = op-u.pcitopoinfo;
+physdev_pci_device_t *devs;
+uint8_t *nodes;
+unsigned int first_dev, i;
+int num_devs;
+
+num_devs = ti-num_devs - ti-first_dev;
+
+if ( guest_handle_is_null(ti-devs) ||
+ guest_handle_is_null(ti-nodes) ||
+ (num_devs = 0) )
+{
+ret = -EINVAL;
+break;
+}
+
+devs = xmalloc_array(physdev_pci_device_t, num_devs);
+nodes = xmalloc_array(uint8_t, num_devs);
+if ( !devs || !nodes )
+{
+xfree(devs);
+xfree(nodes);
+ret = -ENOMEM;
+break;
+}
+
+first_dev = ti-first_dev;
+
+if ( copy_from_guest_offset(devs, ti-devs, first_dev, num_devs) )
+{
+xfree(devs);
+xfree(nodes);
+ret = -EFAULT;
+break;
+}
+for ( i = 0; i num_devs; i++ )
+{
+struct pci_dev *pdev;
+
+spin_lock(pcidevs_lock);
+pdev = pci_get_pdev(devs[i].seg, devs[i].bus, devs[i].devfn);
+if ( !pdev || (pdev-node == NUMA_NO_NODE) )
+nodes[i] = INVALID_NODE_ID;
+else
+nodes[i] = pdev-node;
+spin_unlock(pcidevs_lock);
+
+if ( hypercall_preempt_check() )
+break;
+}
+
+ti-first_dev += i + 1;
+
+if ( __copy_field_to_guest(u_sysctl, op,
+ u.pcitopoinfo.first_dev) ||
+ copy_to_guest_offset(ti-nodes, first_dev, nodes,num_devs) )
+{
+ret = -EFAULT;
+break;
+}
+
+if ( ti-first_dev ti-num_devs )
+ret = hypercall_create_continuation(__HYPERVISOR_sysctl,
+ h, u_sysctl);
+
+xfree(devs);
+xfree(nodes);
+}
+break;
+#endif
#ifdef TEST_COVERAGE
case XEN_SYSCTL_coverage_op:
ret = sysctl_coverage_op(op-u.coverage_op);
diff --git a/xen/include/public/sysctl.h b/xen/include/public/sysctl.h
index 7c78f81..044c3a1 100644
--- a/xen/include/public/sysctl.h
+++ b/xen/include/public/sysctl.h
@@ -33,6 +33,7 @@
#include xen.h
#include domctl.h
+#include physdev.h
#define XEN_SYSCTL_INTERFACE_VERSION 0x000C
@@ -494,6 +495,32 @@ struct xen_sysctl_cputopoinfo {
typedef struct xen_sysctl_cputopoinfo xen_sysctl_cputopoinfo_t;
DEFINE_XEN_GUEST_HANDLE(xen_sysctl_cputopoinfo_t);
+/* XEN_SYSCTL_pcitopoinfo */
+struct xen_sysctl_pcitopoinfo {
+/* IN: Size of pcitopo array */
+uint32_t num_devs;
+
+/*
+ * IN/OUT: First element of pcitopo array that needs to be processed by
+ * hypervisor.
+ * This is used primarily by hypercall continuations and callers will
+ * typically set it to zero
+ */
+uint32_t first_dev;
+
+/* IN: list of devices */
+XEN_GUEST_HANDLE_64(physdev_pci_device_t) devs;
+
+/*
+ * OUT: node identifier for each device.
+ * If information for a particular device is not avalable then set
+ * to INVALID_NODE_ID.
+ */
+XEN_GUEST_HANDLE_64(uint8) nodes;
+};
+typedef struct xen_sysctl_pcitopoinfo xen_sysctl_pcitopoinfo_t;
+DEFINE_XEN_GUEST_HANDLE(xen_sysctl_pcitopoinfo_t);
+
/* XEN_SYSCTL_numainfo */
#define INVALID_MEM_SZ (~0U)
@@ -692,12 +719,14 @@ struct xen_sysctl {
#define XEN_SYSCTL_scheduler_op 19
#define XEN_SYSCTL_coverage_op 20
#define XEN_SYSCTL_psr_cmt_op21
+#define XEN_SYSCTL_pcitopoinfo 22
uint32_t interface_version; /* XEN_SYSCTL_INTERFACE_VERSION */
union {
struct xen_sysctl_readconsole readconsole;
struct xen_sysctl_tbuf_op tbuf_op;
struct xen_sysctl_physinfo physinfo;
struct xen_sysctl_cputopoinfo cputopoinfo;
+struct xen_sysctl_pcitopoinfo pcitopoinfo;
struct xen_sysctl_numainfo numainfo;
struct xen_sysctl_sched_id sched_id;
struct xen_sysctl_perfc_op perfc_op;
--
1.7.1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V4 08/13] xen: Introduce monitor_op domctl
On 02/09/2015 01:53 PM, Tamas K Lengyel wrote:
In preparation for allowing for introspecting ARM and PV domains the old
control interface via the hvm_op hypercall is retired. A new control mechanism
is introduced via the domctl hypercall: monitor_op.
This patch aims to establish a base API on which future applications can build
on.
Suggested-by: Andrew Cooper andrew.coop...@citrix.com
Signed-off-by: Tamas K Lengyel tamas.leng...@zentific.com
Acked-by: Ian Campbell ian.campb...@citrix.com
Acked-by: Kevin Tian kevin.t...@intel.com
One minor typo, then:
Acked-by: Daniel De Graaf dgde...@tycho.nsa.gov
[...]
diff --git a/xen/xsm/flask/policy/access_vectors
b/xen/xsm/flask/policy/access_vectors
index 9da3275..35d1c7b 100644
--- a/xen/xsm/flask/policy/access_vectors
+++ b/xen/xsm/flask/policy/access_vectors
@@ -249,6 +249,8 @@ class hvm
# HVMOP_inject_trap
hvmctl
# XEN_DOMCTL_set_access_required
+# XEN_DOMCLT_monitor_op
+# XEN_DOMCLT_vm_event_op
vm_event
# XEN_DOMCTL_mem_sharing_op and XENMEM_sharing_op_{share,add_physmap} with:
# source = the domain making the hypercall
DOMCLT = DOMCTL
--
Daniel De Graaf
National Security Agency
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V4 05/13] xen: Rename mem_event to vm_event
On 02/09/2015 01:53 PM, Tamas K Lengyel wrote: In this patch we mechanically rename mem_event to vm_event. This patch introduces no logic changes to the code. Using the name vm_event better describes the intended use of this subsystem, which is not limited to memory events. It can be used for off-loading the decision making logic into helper applications when encountering various events during a VM's execution. Signed-off-by: Tamas K Lengyel tamas.leng...@zentific.com Acked-by: Daniel De Graaf dgde...@tycho.nsa.gov ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V4 12/13] xen/xsm: Split vm_event_op into three separate labels
On 02/09/2015 01:53 PM, Tamas K Lengyel wrote: The XSM label vm_event_op has been used to control the three memops controlling mem_access, mem_paging and mem_sharing. While these systems rely on vm_event, these are not vm_event operations themselves. Thus, in this patch we introduce three separate labels for each of these memops. Signed-off-by: Tamas K Lengyel tamas.leng...@zentific.com Acked-by: Daniel De Graaf dgde...@tycho.nsa.gov -- Daniel De Graaf National Security Agency ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V4 10/13] xen/vm_event: Decouple vm_event and mem_access.
On 02/09/2015 01:53 PM, Tamas K Lengyel wrote: The vm_event subsystem has been artifically tied to the presence of mem_access. While mem_access does depend on vm_event, vm_event is an entirely independent subsystem that can be used for arbitrary function-offloading to helper apps in domains. This patch removes the dependency that mem_access needs to be supported in order to enable vm_event. A new vm_event_resume function is introduced which pulls all responses off from given ring and delegates handling to appropriate helper functions (if necessary). By default, vm_event_resume just pulls the response from the ring and unpauses the corresponding vCPU. This approach reduces code duplication and present a single point of entry for the entire vm_event subsystem's response handling mechanism. Signed-off-by: Tamas K Lengyel tamas.leng...@zentific.com Typos from patch 8 have propagated. Otherwise: Acked-by: Daniel De Graaf dgde...@tycho.nsa.gov ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] question about memory allocation for driver domain
On 07/02/2015 01:15, Oleksandr Tyshchenko wrote: Hi Julien Hi Oleksandr, On Thu, Feb 5, 2015 at 6:36 PM, Oleksandr Tyshchenko Let me describe in detail about solution #3 before answer to your question. Maybe I missed something in the first mail. Also the Ian's answer clarified to me some points. We don't have complete solution for now. We only have temporally solution in which we relied on assumptions which might or not be acceptable, but it seems that the approach in general could work. If it is true the our target is to rewrite/rework this stuff, to make it more cleaner and correct from XEN point of view for platforms which doesn't have a SMMU even in the case where this stuff never reaches upstream. To run driver domain (domd) on OMAP5 platform with 1:1 mapping we did next preparations: (here I try to explain about memory allocation only, IRQ handling and other things are out of scope for the current thread) 1. Since the domd can use 128/256/512 Mb of RAM we modified existing populate_guest_memory() in xc_dom_arm.c to allow to allocate 128/256/512 Mb memory chunks. 2. Since the default rambase (0x4000) doesn't suitable for us for some reasons: - OMAP5 platform has memory mapped registers, starting from 0x480 - We have 2 guest domains (domd and domU) so it should be different rambases for them we added ability for toolstack to pass it via domain config file. While the overlapping is true on this Xen 4.5, we may decide to re-arrange the memory layout and put the GIC MMIOs on 0x480. A more generic solution would be to re-use the memory layout of the host. So a 1:1 mapping for MMIO and RAM would avoid overlapping with possible virtual region. I remembered to talk about it with Ian few months ago but we didn't have a practical use case at this time. FWIW, x86 has a similar solution via the e820_host param. 3. Since for domd we need one contiguous chunk of memory we created a new function allocate_domd_memory_11() in common/memory.c for the next purposes: - To allocate one contiguous memory chunk with specified order (as it was done for dom0) - To add this allocated chunk to the guest - domd (via guest_physmap_add_page(), taking into account that mfn=gpfn) 4. Since we need to allocate memory before any operation with it we created hook for XENMEM_populate_physmap command. Here we relied on the assumption that the domain_id for domd is always 1 (it is not true after the domd has been created again after destroying). During first XENMEM_populate_physmap command we set is_privileged=true and call allocate_domd_memory_11(), during next commands - call populate_physmap() as a usual. The is_domain_direct_mapped condition is a our case in populate_physmap(). I know that it is a very, very hacking solution). But, let's continue... How it works at the moment? 1. Create domd with default rambase_pfn (0x8000). 2. See what the mfn we got in allocate_domd_memory_11(). 3. Set rambase_pfn=mfn in config file. If the system configuration (N domains, domains memory, etc.) is not changed, we will always get the same mfn. If we decided to change something, for example, domd memory we need to repeat steps 2 and 3. Yes, looks not good. How it should works? The approach is to tailor the domd address map to the contiguous region the allocator gives us. So, a guest rambase (gpfn) must based on mfn of a page we have allocated successfully. Without any manual actions. I think it must be done in next steps: 1. Add a separate command, XENMEM_alloc_memory_11 or something similar and it should be issued before call xc_dom_rambase_init() in libxl_dom.c in case of presence domd_memory_11 property in config file only. This should remove terrible hook and anything related to d-domain_id=1 in common/memory.c. 2. Pass returned by XENMEM_alloc_memory_11 result to the xc_dom_rambase_init(). What are the advantages in compare with solution #1 and solution #2. 1. There is no need to add standalone allocator or modifying existing. Let's return to your question about created/destroyed domd multiple times. I have tried to do this with solution we have at the moment. I added some modifications to allow me to destroy/create domd multiple times. And I have seen that the allocator always returns the same page. This means that the all memory allocated for domd have been returned to the heap. Am I right? Or perhaps did you mean that this may happens with the completed solution? It seems logical to me that destroy/create domd in a row working fine. But this use-case is too simple :). Let's imagine we decide to start classical domains (i.e no 1:1 mapping) before creating domd (the 1:1 domain). As the free memory may be sparsed, allocating one large RAM region may not work and therefore the domain allocation fail. On a similar idea, the host RAM may be split on multiple non-contiguous banks. In this case, the RAM size of the 1:1 domain cannot be bigger than the size of the bank. You will never know which
Re: [Xen-devel] Inplace upgrading 4.4.x - 4.5.0
Hello Steven, upgrades from Xen 4.4 to 4.5 are supposed to work out of the box. Please post more details and we'll try to help you figure out what's wrong. Cheers, Stefano On Sun, 8 Feb 2015, Steven Haigh wrote: Hi all, I was under the impression that you should be able to do in-place upgrades from Xen 4.4 to 4.5 on a system without losing the ability to manage DomUs... This would support upgrades from running systems from Xen 4.4.x to 4.5.0 - only requiring a reboot to boot into the 4.5.0 hypervisor. When I try this in practice, I get a whole heap of permission denied errors and lose control of any running DomUs. Is there some secret sauce that will allow this to work? -- Steven Haigh Email: net...@crc.id.au Web: http://www.crc.id.au Phone: (03) 9001 6090 - 0412 935 897 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Inplace upgrading 4.4.x - 4.5.0
Thanks Stefano, I wanted to make sure I was correct with this belief before I posted all the info. I'll gather as much info as I can in the next day or so and see what we can do. On 9/02/2015 7:35 PM, Stefano Stabellini wrote: Hello Steven, upgrades from Xen 4.4 to 4.5 are supposed to work out of the box. Please post more details and we'll try to help you figure out what's wrong. Cheers, Stefano On Sun, 8 Feb 2015, Steven Haigh wrote: Hi all, I was under the impression that you should be able to do in-place upgrades from Xen 4.4 to 4.5 on a system without losing the ability to manage DomUs... This would support upgrades from running systems from Xen 4.4.x to 4.5.0 - only requiring a reboot to boot into the 4.5.0 hypervisor. When I try this in practice, I get a whole heap of permission denied errors and lose control of any running DomUs. Is there some secret sauce that will allow this to work? -- Steven Haigh Email: net...@crc.id.au Web: http://www.crc.id.au Phone: (03) 9001 6090 - 0412 935 897 -- Steven Haigh Email: net...@crc.id.au Web: http://www.crc.id.au Phone: (03) 9001 6090 - 0412 935 897 signature.asc Description: OpenPGP digital signature ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen/arm: allow console=hvc0 to be omitted for guests
On 10 February 2015 at 15:26, Ian Campbell ian.campb...@citrix.com wrote: On Tue, 2015-02-10 at 07:00 +, Stefano Stabellini wrote: On Fri, 30 Jan 2015, Ard Biesheuvel wrote: This patch registers hvc0 as the preferred console if no console has been specified explicitly on the kernel command line. The purpose is to allow platform agnostic kernels and boot images (such as distro installers) to boot in a Xen/ARM domU without the need to modify the command line by hand. Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org --- This applies on top of the patch Julien is cooking up to move the call to xen_guest_init() to an earlier boot stage. This needs to be at least before the call to console_init() in start_kernel() for this patch to do anything meaningful. This patch looks good but there isn't much point in queuing this up without the prerequisite. Julien, what patch exactly is that? What is the status of it? arch/arm/xen/enlighten.c | 4 1 file changed, 4 insertions(+) diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c index c7ca936ebd99..61382cafa877 100644 --- a/arch/arm/xen/enlighten.c +++ b/arch/arm/xen/enlighten.c @@ -24,6 +24,7 @@ #include linux/cpuidle.h #include linux/cpufreq.h #include linux/cpu.h +#include linux/console.h #include linux/mm.h @@ -322,6 +323,9 @@ static int __init xen_guest_init(void) register_cpu_notifier(xen_cpu_notifier); + if (!console_set_on_cmdline) + add_preferred_console(hvc, 0, NULL); FWIW on x86 this doesn't depend on console_set_on_cmdline, does it need to here? I didn't check the code, but it seems inappropriate to add a preferred console implicitly if the user has set 'console=' on the command line. On x86 it does depend on !xen_initial_domain. I suppose on the principal that a VT is normally available there. I suppose that doesn't apply to ARM so much, although it could. OK, I got confused by the xen_guest_init(). So do you mean if if (!xen_initial_domain) should be added? -- Ard. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen/arm: allow console=hvc0 to be omitted for guests
On Tue, 2015-02-10 at 07:00 +, Stefano Stabellini wrote: On Fri, 30 Jan 2015, Ard Biesheuvel wrote: This patch registers hvc0 as the preferred console if no console has been specified explicitly on the kernel command line. The purpose is to allow platform agnostic kernels and boot images (such as distro installers) to boot in a Xen/ARM domU without the need to modify the command line by hand. Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org --- This applies on top of the patch Julien is cooking up to move the call to xen_guest_init() to an earlier boot stage. This needs to be at least before the call to console_init() in start_kernel() for this patch to do anything meaningful. This patch looks good but there isn't much point in queuing this up without the prerequisite. Julien, what patch exactly is that? What is the status of it? arch/arm/xen/enlighten.c | 4 1 file changed, 4 insertions(+) diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c index c7ca936ebd99..61382cafa877 100644 --- a/arch/arm/xen/enlighten.c +++ b/arch/arm/xen/enlighten.c @@ -24,6 +24,7 @@ #include linux/cpuidle.h #include linux/cpufreq.h #include linux/cpu.h +#include linux/console.h #include linux/mm.h @@ -322,6 +323,9 @@ static int __init xen_guest_init(void) register_cpu_notifier(xen_cpu_notifier); + if (!console_set_on_cmdline) + add_preferred_console(hvc, 0, NULL); FWIW on x86 this doesn't depend on console_set_on_cmdline, does it need to here? On x86 it does depend on !xen_initial_domain. I suppose on the principal that a VT is normally available there. I suppose that doesn't apply to ARM so much, although it could. + return 0; } early_initcall(xen_guest_init); -- 1.8.3.2 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen/arm: allow console=hvc0 to be omitted for guests
Hi Stefano, On 10/02/2015 15:00, Stefano Stabellini wrote: On Fri, 30 Jan 2015, Ard Biesheuvel wrote: This patch registers hvc0 as the preferred console if no console has been specified explicitly on the kernel command line. The purpose is to allow platform agnostic kernels and boot images (such as distro installers) to boot in a Xen/ARM domU without the need to modify the command line by hand. Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org --- This applies on top of the patch Julien is cooking up to move the call to xen_guest_init() to an earlier boot stage. This needs to be at least before the call to console_init() in start_kernel() for this patch to do anything meaningful. This patch looks good but there isn't much point in queuing this up without the prerequisite. Julien, what patch exactly is that? What is the status of it? Calling xen_guest_init from setup_arch. It's based on a patch you sent an year ago (http://osdir.com/ml/linux-kernel/2013-08/msg00675.html) But I had some issue with the console. The splitting of xen_guest_init doesn't work. It seems that we decode the IRQ too early. I haven't had time to rework it and sent it. Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] modify the IO_TLB_SEGSIZE to io_tlb_segsize configurable as flexible requirement about SW-IOMMU.
On Mon, Feb 09, 2015 at 02:13:30AM +, Wang, Xiaoming wrote: Dear Wilk: -Original Message- From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com] Sent: Saturday, February 7, 2015 2:12 AM To: Wang, Xiaoming Cc: r...@linux-mips.org; boris.ostrov...@oracle.com; david.vra...@citrix.com; linux-m...@linux-mips.org; linux- ker...@vger.kernel.org; xen-de...@lists.xenproject.org; akpm@linux- foundation.org; li...@horizon.com; lau...@codeaurora.org; heiko.carst...@de.ibm.com; d.kasat...@samsung.com; takahiro.aka...@linaro.org; ch...@chris-wilson.co.uk; pebo...@tiscali.nl; Liu, Chuansheng; Zhang, Dongxing Subject: Re: [PATCH] modify the IO_TLB_SEGSIZE to io_tlb_segsize configurable as flexible requirement about SW-IOMMU. On Fri, Feb 06, 2015 at 12:10:15AM +, Wang, Xiaoming wrote: -Original Message- From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com] Sent: Friday, February 6, 2015 3:33 AM To: Wang, Xiaoming Cc: r...@linux-mips.org; boris.ostrov...@oracle.com; david.vra...@citrix.com; linux-m...@linux-mips.org; linux- ker...@vger.kernel.org; xen-de...@lists.xenproject.org; akpm@linux- foundation.org; li...@horizon.com; lau...@codeaurora.org; heiko.carst...@de.ibm.com; d.kasat...@samsung.com; takahiro.aka...@linaro.org; ch...@chris-wilson.co.uk; pebo...@tiscali.nl; Liu, Chuansheng; Zhang, Dongxing Subject: Re: [PATCH] modify the IO_TLB_SEGSIZE to io_tlb_segsize configurable as flexible requirement about SW-IOMMU. On Fri, Feb 06, 2015 at 07:01:14AM +0800, xiaomin1 wrote: The maximum of SW-IOMMU is limited to 2^11*128 = 256K. While in different platform and different requirements this seems improper. So modify the IO_TLB_SEGSIZE to io_tlb_segsize as configurable is make sense. More details please. What is the issue you are hitting? Example: If 1M bytes are requied. There has an error like. Ok, but even with 1MB size - you only have 64 'slots' (if you allocate an 64MB buffer). And the other 'slots' can be fragmented so you might still not have enough 1MB chunks available. Do you have some thoughts on how that would be addressed? Yes, If IO_TLB_SEGSIZE is 128 the slabs is 32K/128 = 256 While IO_TLB_SEGSIZE is 512 the slabs is 32K/512 =64 (for 1M). So it is dilemma between slabs and segsize. Right. I have a thought how about modifying the IO_TLB_DEFAULT_SIZE to io_tlb_default_size configurable too? It would seem that 'io_tlb_default_size' should be influenced by the 'io_tlb_segsize' - as in have some calculation that would come up with the best value (if there is one?) Because of the multivariate requirement. [ 31.474769] dwc3_otg :00:16.0: dwc3_intel_byt_notify_charger_type(): dwc3_intel_byt_notify_charger_type: invalid SDP current! [ 31.554077] android_work: sent uevent USB_STATE=CONNECTED [ 31.564244] android_usb gadget: high-speed config #1: android [ 31.571468] android_work: sent uevent USB_STATE=CONFIGURED [ 31.942738] DMA: Out of SW-IOMMU space for 1048576 bytes at device gadget [ 31.950345] Kernel panic - not syncing: DMA: Random memory could be DMA written [ 31.950345] [ 31.960170] CPU: 1 PID: 172 Comm: droidboot Tainted: GW 3.10.20-x86_64_byt-g1077f87 #2 [ 31.970086] Hardware name: Intel Corp. VALLEYVIEW C0 PLATFORM/BYT-T FFD8, BIOS BLADE_21.X64.0004.R14.1412311144 FFD8_X64_R_2014_12_31_1151 12/31/2014 [ 31.985053] 0010 880136c2fc98 82967d45 880136c2fd10 [ 31.993327] 82961761 0008 880136c2fd20 880136c2fcc0 [ 32.001590] 829618fb 0002 820aeff9 8d8c [ 32.009871] Call Trace: [ 32.012610] [82967d45] dump_stack+0x19/0x1b [ 32.018353] [82961761] panic+0xc8/0x1d6 [ 32.023707] [829618fb] ? printk+0x55/0x57 [ 32.029258] [820aeff9] ? console_unlock+0x1f9/0x460 [ 32.035772] [82347cbe] swiotlb_map_page+0x12e/0x140 [ 32.042283] [82599d4d] usb_gadget_map_request+0x16d/0x220 [ 32.049387] [8255ce89] dwc3_gadget_ep_queue+0x229/0x460 [ 32.056297] [825b4624] ffs_epfile_io.isra.96+0x3e4/0x520 [ 32.063296] [820e438d] ? get_parent_ip+0xd/0x50 [ 32.069427] [82975a61] ? sub_preempt_count+0x71/0x100 [ 32.076142] [825b47b8] ffs_epfile_read+0x28/0x30 [ 32.082370] [821b6b8c] vfs_read+0x9c/0x170 [ 32.088014] [821b765d] SyS_read+0x4d/0xa0 [ 32.093562] [8297b179] ia32_do_call+0x13/0x13 Signed-off-by: Chuansheng Liu chuansheng@intel.com Signed-off-by: Zhang Dongxing dongxing.zh...@intel.com Signed-off-by: xiaomin1 xiaoming.w...@intel.com --- arch/mips/cavium-octeon/dma-octeon.c |2 +-
[Xen-devel] [PATCH V4 08/13] xen: Introduce monitor_op domctl
In preparation for allowing for introspecting ARM and PV domains the old
control interface via the hvm_op hypercall is retired. A new control mechanism
is introduced via the domctl hypercall: monitor_op.
This patch aims to establish a base API on which future applications can build
on.
Suggested-by: Andrew Cooper andrew.coop...@citrix.com
Signed-off-by: Tamas K Lengyel tamas.leng...@zentific.com
Acked-by: Ian Campbell ian.campb...@citrix.com
Acked-by: Kevin Tian kevin.t...@intel.com
---
v4: Style fixes
Only defining struct mov_to_cr and struct debug_event in asm-x86/domain.h
Add pause/unpause domain wrapper when enabled a monitor option.
---
tools/libxc/Makefile| 1 +
tools/libxc/include/xenctrl.h | 19
tools/libxc/xc_mem_access.c | 9 +-
tools/libxc/xc_monitor.c| 118 +
tools/libxc/xc_private.h| 2 +-
tools/libxc/xc_vm_event.c | 7 +-
tools/tests/xen-access/xen-access.c | 14 +--
xen/arch/x86/Makefile | 1 +
xen/arch/x86/hvm/emulate.c | 3 +-
xen/arch/x86/hvm/event.c| 69 ++--
xen/arch/x86/hvm/hvm.c | 38 +--
xen/arch/x86/hvm/vmx/vmcs.c | 6 +-
xen/arch/x86/hvm/vmx/vmx.c | 2 +-
xen/arch/x86/mm/p2m.c | 9 --
xen/arch/x86/monitor.c | 204
xen/common/domctl.c | 9 ++
xen/common/vm_event.c | 19 +---
xen/include/asm-arm/monitor.h | 13 +++
xen/include/asm-x86/domain.h| 28 +
xen/include/asm-x86/hvm/domain.h| 1 -
xen/include/asm-x86/monitor.h | 8 ++
xen/include/public/domctl.h | 50 -
xen/include/public/hvm/params.h | 15 ---
xen/include/public/vm_event.h | 2 +-
xen/xsm/flask/hooks.c | 3 +
xen/xsm/flask/policy/access_vectors | 2 +
26 files changed, 510 insertions(+), 142 deletions(-)
create mode 100644 tools/libxc/xc_monitor.c
create mode 100644 xen/arch/x86/monitor.c
create mode 100644 xen/include/asm-arm/monitor.h
create mode 100644 xen/include/asm-x86/monitor.h
diff --git a/tools/libxc/Makefile b/tools/libxc/Makefile
index 22ba2a1..8b609cf 100644
--- a/tools/libxc/Makefile
+++ b/tools/libxc/Makefile
@@ -32,6 +32,7 @@ CTRL_SRCS-y += xc_cpu_hotplug.c
CTRL_SRCS-y += xc_resume.c
CTRL_SRCS-y += xc_tmem.c
CTRL_SRCS-y += xc_vm_event.c
+CTRL_SRCS-y += xc_monitor.c
CTRL_SRCS-y += xc_mem_paging.c
CTRL_SRCS-y += xc_mem_access.c
CTRL_SRCS-y += xc_memshr.c
diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 790db53..3324132 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -2308,6 +2308,25 @@ int xc_get_mem_access(xc_interface *xch, domid_t
domain_id,
uint64_t pfn, xenmem_access_t *access);
/***
+ * Monitor control operations.
+ */
+int xc_monitor_mov_to_cr0(xc_interface *xch, domid_t domain_id,
+ unsigned int op, unsigned int sync,
+ unsigned int onchangeonly);
+int xc_monitor_mov_to_cr3(xc_interface *xch, domid_t domain_id,
+ unsigned int op, unsigned int sync,
+ unsigned int onchangeonly);
+int xc_monitor_mov_to_cr4(xc_interface *xch, domid_t domain_id,
+ unsigned int op, unsigned int sync,
+ unsigned int onchangeonly);
+int xc_monitor_mov_to_msr(xc_interface *xch, domid_t domain_id,
+ unsigned int op, unsigned int extended_capture);
+int xc_monitor_singlestep(xc_interface *xch, domid_t domain_id,
+ unsigned int op);
+int xc_monitor_software_breakpoint(xc_interface *xch, domid_t domain_id,
+ unsigned int op);
+
+/***
* Memory sharing operations.
*
* Unles otherwise noted, these calls return 0 on succes, -1 and errno on
diff --git a/tools/libxc/xc_mem_access.c b/tools/libxc/xc_mem_access.c
index 0a3f0e6..37e776c 100644
--- a/tools/libxc/xc_mem_access.c
+++ b/tools/libxc/xc_mem_access.c
@@ -27,14 +27,7 @@
void *xc_mem_access_enable(xc_interface *xch, domid_t domain_id, uint32_t
*port)
{
return xc_vm_event_enable(xch, domain_id, HVM_PARAM_MONITOR_RING_PFN,
- port, 0);
-}
-
-void *xc_mem_access_enable_introspection(xc_interface *xch, domid_t domain_id,
- uint32_t *port)
-{
-return xc_vm_event_enable(xch, domain_id, HVM_PARAM_MONITOR_RING_PFN,
- port, 1);
+ port);
}
int xc_mem_access_disable(xc_interface *xch, domid_t domain_id)
diff --git a/tools/libxc/xc_monitor.c b/tools/libxc/xc_monitor.c
new file mode 100644
index 000..9e807d1
--- /dev/null
+++ b/tools/libxc/xc_monitor.c
@@ -0,0 +1,118 @@
[Xen-devel] [PATCH V4 10/13] xen/vm_event: Decouple vm_event and mem_access.
The vm_event subsystem has been artifically tied to the presence of mem_access.
While mem_access does depend on vm_event, vm_event is an entirely independent
subsystem that can be used for arbitrary function-offloading to helper apps in
domains. This patch removes the dependency that mem_access needs to be supported
in order to enable vm_event.
A new vm_event_resume function is introduced which pulls all responses off from
given ring and delegates handling to appropriate helper functions (if
necessary). By default, vm_event_resume just pulls the response from the ring
and unpauses the corresponding vCPU. This approach reduces code duplication
and present a single point of entry for the entire vm_event subsystem's
response handling mechanism.
Signed-off-by: Tamas K Lengyel tamas.leng...@zentific.com
---
v4: Consolidate resume routines into vm_event_resume
Style fixes
Sort xen/common/Makefile to be alphabetical
v3: Move ring processing out from mem_access.c to monitor.c in common
---
xen/arch/x86/mm/mem_sharing.c | 37 +-
xen/arch/x86/mm/p2m.c | 66 ++-
xen/common/Makefile | 18 -
xen/common/mem_access.c | 36 +
xen/common/vm_event.c | 77 +++--
xen/include/asm-x86/mem_sharing.h | 1 -
xen/include/asm-x86/p2m.h | 2 +-
xen/include/xen/mem_access.h| 14 +--
xen/include/xen/vm_event.h | 70 -
xen/include/xsm/dummy.h | 2 -
xen/include/xsm/xsm.h | 4 --
xen/xsm/dummy.c | 2 -
xen/xsm/flask/hooks.c | 36 -
xen/xsm/flask/policy/access_vectors | 8 ++--
14 files changed, 137 insertions(+), 236 deletions(-)
diff --git a/xen/arch/x86/mm/mem_sharing.c b/xen/arch/x86/mm/mem_sharing.c
index 0731261..4959407 100644
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -591,40 +591,6 @@ unsigned int mem_sharing_get_nr_shared_mfns(void)
return (unsigned int)atomic_read(nr_shared_mfns);
}
-int mem_sharing_sharing_resume(struct domain *d)
-{
-vm_event_response_t rsp;
-
-/* Get all requests off the ring */
-while ( vm_event_get_response(d, d-vm_event-share, rsp) )
-{
-struct vcpu *v;
-
-if ( rsp.version != VM_EVENT_INTERFACE_VERSION )
-{
-gdprintk(XENLOG_WARNING, vm_event interface version mismatch!\n);
-continue;
-}
-
-#ifndef NDEBUG
-if ( rsp.flags VM_EVENT_FLAG_DUMMY )
-continue;
-#endif
-
-/* Validate the vcpu_id in the response. */
-if ( (rsp.vcpu_id = d-max_vcpus) || !d-vcpu[rsp.vcpu_id] )
-continue;
-
-v = d-vcpu[rsp.vcpu_id];
-
-/* Unpause domain/vcpu */
-if ( rsp.flags VM_EVENT_FLAG_VCPU_PAUSED )
-vm_event_vcpu_unpause(v);
-}
-
-return 0;
-}
-
/* Functions that change a page's type and ownership */
static int page_make_sharable(struct domain *d,
struct page_info *page,
@@ -1475,7 +1441,8 @@ int mem_sharing_memop(struct domain *d,
xen_mem_sharing_op_t *mec)
{
if ( !mem_sharing_enabled(d) )
return -EINVAL;
-rc = mem_sharing_sharing_resume(d);
+
+vm_event_resume(d, d-vm_event-share);
}
break;
diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index 13a567d..5ccaede 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -1277,13 +1277,13 @@ int p2m_mem_paging_prep(struct domain *d, unsigned long
gfn, uint64_t buffer)
}
/**
- * p2m_mem_paging_resume - Resume guest gfn and vcpus
+ * p2m_mem_paging_resume - Resume guest gfn
* @d: guest domain
- * @gfn: guest page in paging state
+ * @rsp: vm_event response received
+ *
+ * p2m_mem_paging_resume() will forward the p2mt of a gfn to ram_rw. It is
+ * called by the pager.
*
- * p2m_mem_paging_resume() will forward the p2mt of a gfn to ram_rw and all
- * waiting vcpus will be unpaused again. It is called by the pager.
- *
* The gfn was previously either evicted and populated, or nominated and
* populated. If the page was evicted the p2mt will be p2m_ram_paging_in. If
* the page was just nominated the p2mt will be p2m_ram_paging_in_start because
@@ -1291,56 +1291,30 @@ int p2m_mem_paging_prep(struct domain *d, unsigned long
gfn, uint64_t buffer)
*
* If the gfn was dropped the vcpu needs to be unpaused.
*/
-void p2m_mem_paging_resume(struct domain *d)
+
+void p2m_mem_paging_resume(struct domain *d, vm_event_response_t *rsp)
{
struct p2m_domain *p2m = p2m_get_hostp2m(d);
-vm_event_response_t rsp;
p2m_type_t p2mt;
p2m_access_t a;
mfn_t mfn;
-/* Pull all responses off the ring */
-while( vm_event_get_response(d, d-vm_event-paging, rsp) )
+/* Fix p2m entry if the page was not dropped */
[Xen-devel] [PATCH V4 02/13] xen/mem_event: Cleanup mem_event ring names and domctls
The name of one of the mem_event rings still implies it is used only
for memory accesses, which is no longer the case. It is also used to
deliver various HVM events, thus the name monitor is more appropriate
in this setting.
The mem_event subop definitions are also shortened to be more meaningful.
The tool side changes are only mechanical renaming to match these new names.
Signed-off-by: Tamas K Lengyel tamas.leng...@zentific.com
Acked-by: Ian Campbell ian.campb...@citrix.com
---
v4: Shorted mem_event domctl subops.
v3: Style and comment fixes.
---
tools/libxc/xc_domain_restore.c | 14 +++---
tools/libxc/xc_domain_save.c| 4 ++--
tools/libxc/xc_hvm_build_x86.c | 2 +-
tools/libxc/xc_mem_access.c | 8
tools/libxc/xc_mem_event.c | 12 ++--
tools/libxc/xc_mem_paging.c | 4 ++--
tools/libxc/xc_memshr.c | 4 ++--
tools/libxc/xg_save_restore.h | 2 +-
xen/arch/x86/hvm/hvm.c | 4 ++--
xen/arch/x86/hvm/vmx/vmcs.c | 2 +-
xen/arch/x86/mm/p2m.c | 2 +-
xen/common/mem_access.c | 8
xen/common/mem_event.c | 30 ++--
xen/include/public/domctl.h | 43 -
xen/include/public/hvm/params.h | 2 +-
xen/include/xen/sched.h | 4 ++--
16 files changed, 76 insertions(+), 69 deletions(-)
diff --git a/tools/libxc/xc_domain_restore.c b/tools/libxc/xc_domain_restore.c
index a382701..2ab9f46 100644
--- a/tools/libxc/xc_domain_restore.c
+++ b/tools/libxc/xc_domain_restore.c
@@ -734,7 +734,7 @@ typedef struct {
uint64_t vcpumap[XC_SR_MAX_VCPUS/64];
uint64_t identpt;
uint64_t paging_ring_pfn;
-uint64_t access_ring_pfn;
+uint64_t monitor_ring_pfn;
uint64_t sharing_ring_pfn;
uint64_t vm86_tss;
uint64_t console_pfn;
@@ -828,15 +828,15 @@ static int pagebuf_get_one(xc_interface *xch, struct
restore_ctx *ctx,
// DPRINTF(paging ring pfn address: %llx\n, buf-paging_ring_pfn);
return pagebuf_get_one(xch, ctx, buf, fd, dom);
-case XC_SAVE_ID_HVM_ACCESS_RING_PFN:
+case XC_SAVE_ID_HVM_MONITOR_RING_PFN:
/* Skip padding 4 bytes then read the mem access ring location. */
-if ( RDEXACT(fd, buf-access_ring_pfn, sizeof(uint32_t)) ||
- RDEXACT(fd, buf-access_ring_pfn, sizeof(uint64_t)) )
+if ( RDEXACT(fd, buf-monitor_ring_pfn, sizeof(uint32_t)) ||
+ RDEXACT(fd, buf-monitor_ring_pfn, sizeof(uint64_t)) )
{
PERROR(error read the access ring pfn);
return -1;
}
-// DPRINTF(access ring pfn address: %llx\n, buf-access_ring_pfn);
+// DPRINTF(monitor ring pfn address: %llx\n, buf-monitor_ring_pfn);
return pagebuf_get_one(xch, ctx, buf, fd, dom);
case XC_SAVE_ID_HVM_SHARING_RING_PFN:
@@ -1660,8 +1660,8 @@ int xc_domain_restore(xc_interface *xch, int io_fd,
uint32_t dom,
xc_hvm_param_set(xch, dom, HVM_PARAM_IDENT_PT,
pagebuf.identpt);
if ( pagebuf.paging_ring_pfn )
xc_hvm_param_set(xch, dom, HVM_PARAM_PAGING_RING_PFN,
pagebuf.paging_ring_pfn);
-if ( pagebuf.access_ring_pfn )
-xc_hvm_param_set(xch, dom, HVM_PARAM_ACCESS_RING_PFN,
pagebuf.access_ring_pfn);
+if ( pagebuf.monitor_ring_pfn )
+xc_hvm_param_set(xch, dom, HVM_PARAM_MONITOR_RING_PFN,
pagebuf.monitor_ring_pfn);
if ( pagebuf.sharing_ring_pfn )
xc_hvm_param_set(xch, dom, HVM_PARAM_SHARING_RING_PFN,
pagebuf.sharing_ring_pfn);
if ( pagebuf.vm86_tss )
diff --git a/tools/libxc/xc_domain_save.c b/tools/libxc/xc_domain_save.c
index 254fdb3..949ef64 100644
--- a/tools/libxc/xc_domain_save.c
+++ b/tools/libxc/xc_domain_save.c
@@ -1664,9 +1664,9 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t
dom, uint32_t max_iter
goto out;
}
-chunk.id = XC_SAVE_ID_HVM_ACCESS_RING_PFN;
+chunk.id = XC_SAVE_ID_HVM_MONITOR_RING_PFN;
chunk.data = 0;
-xc_hvm_param_get(xch, dom, HVM_PARAM_ACCESS_RING_PFN, chunk.data);
+xc_hvm_param_get(xch, dom, HVM_PARAM_MONITOR_RING_PFN, chunk.data);
if ( (chunk.data != 0)
wrexact(io_fd, chunk, sizeof(chunk)) )
diff --git a/tools/libxc/xc_hvm_build_x86.c b/tools/libxc/xc_hvm_build_x86.c
index c81a25b..30a929d 100644
--- a/tools/libxc/xc_hvm_build_x86.c
+++ b/tools/libxc/xc_hvm_build_x86.c
@@ -497,7 +497,7 @@ static int setup_guest(xc_interface *xch,
special_pfn(SPECIALPAGE_CONSOLE));
xc_hvm_param_set(xch, dom, HVM_PARAM_PAGING_RING_PFN,
special_pfn(SPECIALPAGE_PAGING));
-xc_hvm_param_set(xch, dom, HVM_PARAM_ACCESS_RING_PFN,
+xc_hvm_param_set(xch, dom, HVM_PARAM_MONITOR_RING_PFN,
special_pfn(SPECIALPAGE_ACCESS));
xc_hvm_param_set(xch, dom, HVM_PARAM_SHARING_RING_PFN,
[Xen-devel] [PATCH V4 01/13] xen/mem_event: Cleanup of mem_event structures
From: Razvan Cojocaru rcojoc...@bitdefender.com
The public mem_event structures used to communicate with helper applications via
shared rings have been used in different settings. However, the variable names
within this structure have not reflected this fact, resulting in the reuse of
variables to mean different things under different scenarios.
This patch remedies the issue by clearly defining the structure members based on
the actual context within which the structure is used.
Signed-off-by: Razvan Cojocaru rcojoc...@bitdefender.com
Signed-off-by: Tamas K Lengyel tamas.leng...@zentific.com
---
v4: Attach mem_event version to each outgoing request directly in mem_event.
v3: Add padding to mem_event structures.
Add version field to mem_event structures and checks for it.
---
tools/tests/xen-access/xen-access.c | 43 +
tools/xenpaging/xenpaging.c | 40
xen/arch/x86/hvm/hvm.c | 177 +++-
xen/arch/x86/mm/mem_sharing.c | 16 +++-
xen/arch/x86/mm/p2m.c | 143 -
xen/common/mem_access.c | 6 ++
xen/common/mem_event.c | 2 +
xen/include/public/mem_event.h | 108 +-
8 files changed, 325 insertions(+), 210 deletions(-)
diff --git a/tools/tests/xen-access/xen-access.c
b/tools/tests/xen-access/xen-access.c
index 6cb382d..dd21d3b 100644
--- a/tools/tests/xen-access/xen-access.c
+++ b/tools/tests/xen-access/xen-access.c
@@ -551,13 +551,21 @@ int main(int argc, char *argv[])
continue;
}
+if ( req.version != MEM_EVENT_INTERFACE_VERSION )
+{
+ERROR(Error: mem_event interface version mismatch!\n);
+interrupted = -1;
+continue;
+}
+
memset( rsp, 0, sizeof (rsp) );
+rsp.version = MEM_EVENT_INTERFACE_VERSION;
rsp.vcpu_id = req.vcpu_id;
rsp.flags = req.flags;
switch (req.reason) {
-case MEM_EVENT_REASON_VIOLATION:
-rc = xc_get_mem_access(xch, domain_id, req.gfn, access);
+case MEM_EVENT_REASON_MEM_ACCESS:
+rc = xc_get_mem_access(xch, domain_id, req.u.mem_access.gfn,
access);
if (rc 0)
{
ERROR(Error %d getting mem_access event\n, rc);
@@ -567,21 +575,21 @@ int main(int argc, char *argv[])
printf(PAGE ACCESS: %c%c%c for GFN %PRIx64 (offset %06
PRIx64) gla %016PRIx64 (valid: %c; fault in gpt: %c;
fault with gla: %c) (vcpu %u)\n,
- req.access_r ? 'r' : '-',
- req.access_w ? 'w' : '-',
- req.access_x ? 'x' : '-',
- req.gfn,
- req.offset,
- req.gla,
- req.gla_valid ? 'y' : 'n',
- req.fault_in_gpt ? 'y' : 'n',
- req.fault_with_gla ? 'y': 'n',
+ req.u.mem_access.access_r ? 'r' : '-',
+ req.u.mem_access.access_w ? 'w' : '-',
+ req.u.mem_access.access_x ? 'x' : '-',
+ req.u.mem_access.gfn,
+ req.u.mem_access.offset,
+ req.u.mem_access.gla,
+ req.u.mem_access.gla_valid ? 'y' : 'n',
+ req.u.mem_access.fault_in_gpt ? 'y' : 'n',
+ req.u.mem_access.fault_with_gla ? 'y': 'n',
req.vcpu_id);
if ( default_access != after_first_access )
{
rc = xc_set_mem_access(xch, domain_id, after_first_access,
- req.gfn, 1);
+ req.u.mem_access.gfn, 1);
if (rc 0)
{
ERROR(Error %d setting gfn to access_type %d\n, rc,
@@ -592,13 +600,12 @@ int main(int argc, char *argv[])
}
-rsp.gfn = req.gfn;
-rsp.p2mt = req.p2mt;
+rsp.u.mem_access.gfn = req.u.mem_access.gfn;
break;
-case MEM_EVENT_REASON_INT3:
-printf(INT3: rip=%016PRIx64, gfn=%PRIx64 (vcpu %d)\n,
- req.gla,
- req.gfn,
+case MEM_EVENT_REASON_SOFTWARE_BREAKPOINT:
+printf(INT3: rip=%016PRIx64, gfn=%PRIx64 (vcpu %d)\n,
+ req.regs.x86.rip,
+ req.u.software_breakpoint.gfn,
req.vcpu_id);
/* Reinject */
diff --git a/tools/xenpaging/xenpaging.c b/tools/xenpaging/xenpaging.c
index 82c1ee4..c71ee06 100644
--- a/tools/xenpaging/xenpaging.c
+++ b/tools/xenpaging/xenpaging.c
@@ -684,9 +684,9 @@ static int
[Xen-devel] [PATCH V4 09/13] xen/vm_event: Check for VM_EVENT_FLAG_DUMMY only in Debug builds
The flag is only used for debugging purposes, thus it should be only checked for in debug builds of Xen. Signed-off-by: Tamas K Lengyel tamas.leng...@zentific.com --- xen/arch/x86/mm/mem_sharing.c | 2 ++ xen/arch/x86/mm/p2m.c | 2 ++ xen/common/mem_access.c | 2 ++ 3 files changed, 6 insertions(+) diff --git a/xen/arch/x86/mm/mem_sharing.c b/xen/arch/x86/mm/mem_sharing.c index 9d796e7..0731261 100644 --- a/xen/arch/x86/mm/mem_sharing.c +++ b/xen/arch/x86/mm/mem_sharing.c @@ -606,8 +606,10 @@ int mem_sharing_sharing_resume(struct domain *d) continue; } +#ifndef NDEBUG if ( rsp.flags VM_EVENT_FLAG_DUMMY ) continue; +#endif /* Validate the vcpu_id in the response. */ if ( (rsp.vcpu_id = d-max_vcpus) || !d-vcpu[rsp.vcpu_id] ) diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c index 38defdf..13a567d 100644 --- a/xen/arch/x86/mm/p2m.c +++ b/xen/arch/x86/mm/p2m.c @@ -1310,8 +1310,10 @@ void p2m_mem_paging_resume(struct domain *d) continue; } +#ifndef NDEBUG if ( rsp.flags VM_EVENT_FLAG_DUMMY ) continue; +#endif /* Validate the vcpu_id in the response. */ if ( (rsp.vcpu_id = d-max_vcpus) || !d-vcpu[rsp.vcpu_id] ) diff --git a/xen/common/mem_access.c b/xen/common/mem_access.c index f77f134..15dcbf0 100644 --- a/xen/common/mem_access.c +++ b/xen/common/mem_access.c @@ -44,8 +44,10 @@ void mem_access_resume(struct domain *d) continue; } +#ifndef NDEBUG if ( rsp.flags VM_EVENT_FLAG_DUMMY ) continue; +#endif /* Validate the vcpu_id in the response. */ if ( (rsp.vcpu_id = d-max_vcpus) || !d-vcpu[rsp.vcpu_id] ) -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH V4 00/13] xen: Clean-up of mem_event subsystem
This patch series aims to clean up the mem_event subsystem within Xen. The
original use-case for this system was to allow external helper applications
running in privileged domains to control various memory operations performed
by Xen. Amongs these were paging, sharing and access control. The subsystem
has since been extended to also deliver non-memory related events, namely
various HVM debugging events (INT3, MTF, MOV-TO-CR, MOV-TO-MSR). The structures
and naming of related functions however has not caught up to these new
use-cases, thus leaving many ambiguities in the code. Furthermore, future
use-cases envisioned for this subsystem include PV domains and ARM domains,
thus there is a need to establish a common base to build on.
In this series we convert the mem_event system to vm_event in which we clearly
define the scope of information that is transmitted via the event
delivery mechanism. Afterwards, we clean up the naming of the structures and
related functions to more clearly be in line with their actual operations.
Finally, the control of monitor events is moved to a new domctl, monitor_op.
Each patch in the series has been build-tested on x86 and ARM, both with
and without XSM enabled.
This PATCH series is also available at:
https://github.com/tklengyel/xen/tree/mem_event_cleanup4
Razvan Cojocaru (1):
xen/mem_event: Cleanup of mem_event structures
Tamas K Lengyel (12):
xen/mem_event: Cleanup mem_event ring names and domctls
xen/mem_paging: Convert mem_event_op to mem_paging_op
xen/mem_access: Merge mem_event sanity check into mem_access check
xen: Rename mem_event to vm_event
tools/tests: Clean-up tools/tests/xen-access
x86/hvm: factor out and rename vm_event related functions
xen: Introduce monitor_op domctl
xen/vm_event: Check for VM_EVENT_FLAG_DUMMY only in Debug builds
xen/vm_event: Decouple vm_event and mem_access.
xen/vm_event: Relocate memop checks
xen/xsm: Split vm_event_op into three separate labels
xen/vm_event: Add RESUME option to vm_event_op domctl
MAINTAINERS | 4 +-
docs/misc/xsm-flask.txt | 2 +-
tools/libxc/Makefile | 3 +-
tools/libxc/include/xenctrl.h | 41 ++-
tools/libxc/xc_domain_restore.c | 14 +-
tools/libxc/xc_domain_save.c | 4 +-
tools/libxc/xc_hvm_build_x86.c| 2 +-
tools/libxc/xc_mem_access.c | 32 --
tools/libxc/xc_mem_paging.c | 52 ++-
tools/libxc/xc_memshr.c | 29 +-
tools/libxc/xc_monitor.c | 140
tools/libxc/xc_private.h | 15 +-
tools/libxc/{xc_mem_event.c = xc_vm_event.c} | 59 ++-
tools/libxc/xg_save_restore.h | 2 +-
tools/tests/xen-access/xen-access.c | 226 +---
tools/xenpaging/pagein.c | 2 +-
tools/xenpaging/xenpaging.c | 154
tools/xenpaging/xenpaging.h | 8 +-
xen/arch/x86/Makefile | 1 +
xen/arch/x86/domain.c | 2 +-
xen/arch/x86/domctl.c | 4 +-
xen/arch/x86/hvm/Makefile | 3 +-
xen/arch/x86/hvm/emulate.c| 9 +-
xen/arch/x86/hvm/event.c | 190 ++
xen/arch/x86/hvm/hvm.c| 192 +-
xen/arch/x86/hvm/vmx/vmcs.c | 10 +-
xen/arch/x86/hvm/vmx/vmx.c| 9 +-
xen/arch/x86/mm/hap/nested_ept.c | 4 +-
xen/arch/x86/mm/hap/nested_hap.c | 4 +-
xen/arch/x86/mm/mem_paging.c | 46 ++-
xen/arch/x86/mm/mem_sharing.c | 136 ---
xen/arch/x86/mm/p2m-pod.c | 4 +-
xen/arch/x86/mm/p2m-pt.c | 4 +-
xen/arch/x86/mm/p2m.c | 259 +++---
xen/arch/x86/monitor.c| 204 +++
xen/arch/x86/x86_64/compat/mm.c | 26 +-
xen/arch/x86/x86_64/mm.c | 26 +-
xen/common/Makefile | 18 +-
xen/common/domain.c | 12 +-
xen/common/domctl.c | 17 +-
xen/common/mem_access.c | 47 +--
xen/common/{mem_event.c = vm_event.c}| 492 ++
xen/drivers/passthrough/pci.c | 2 +-
xen/include/asm-arm/monitor.h | 13 +
xen/include/asm-arm/p2m.h | 6 +-
xen/include/asm-x86/domain.h | 32 +-
xen/include/asm-x86/hvm/domain.h | 1 -
xen/include/asm-x86/hvm/emulate.h | 2 +-
xen/include/asm-x86/hvm/event.h | 40 +++
xen/include/asm-x86/hvm/hvm.h | 11 -
xen/include/asm-x86/mem_paging.h | 7 +-
[Xen-devel] [PATCH V4 11/13] xen/vm_event: Relocate memop checks
The memop handler function for paging/sharing responsible for calling XSM
doesn't really have anything to do with vm_event, thus in this patch we
relocate it into mem_paging_memop and mem_sharing_memop. This has already
been the approach in mem_access_memop, so in this patch we just make it
consistent.
Signed-off-by: Tamas K Lengyel tamas.leng...@zentific.com
---
xen/arch/x86/mm/mem_paging.c | 42 --
xen/arch/x86/mm/mem_sharing.c | 76 ++-
xen/arch/x86/x86_64/compat/mm.c | 28 +++
xen/arch/x86/x86_64/mm.c | 26 +++---
xen/common/vm_event.c | 43 --
xen/include/asm-x86/mem_paging.h | 7 +++-
xen/include/asm-x86/mem_sharing.h | 4 +--
xen/include/xen/vm_event.h| 1 -
8 files changed, 101 insertions(+), 126 deletions(-)
diff --git a/xen/arch/x86/mm/mem_paging.c b/xen/arch/x86/mm/mem_paging.c
index 68b7fcc..9d2cc4c 100644
--- a/xen/arch/x86/mm/mem_paging.c
+++ b/xen/arch/x86/mm/mem_paging.c
@@ -21,40 +21,62 @@
*/
+#include xen/guest_access.h
#include asm/p2m.h
-#include xen/vm_event.h
+#include xsm/xsm.h
-
-int mem_paging_memop(struct domain *d, xen_mem_paging_op_t *mpc)
+int mem_paging_memop(unsigned long cmd,
+ XEN_GUEST_HANDLE_PARAM(xen_mem_paging_op_t) arg)
{
+int rc;
+xen_mem_paging_op_t mpo;
+struct domain *d;
+
+rc = -EFAULT;
+if ( copy_from_guest(mpo, arg, 1) )
+return rc;
+
+rc = rcu_lock_live_remote_domain_by_id(mpo.domain, d);
+if ( rc )
+return rc;
+
+rc = xsm_vm_event_op(XSM_DM_PRIV, d, XENMEM_paging_op);
+if ( rc )
+return rc;
+
+rc = -ENODEV;
if ( unlikely(!d-vm_event-paging.ring_page) )
-return -ENODEV;
+return rc;
-switch( mpc-op )
+switch( mpo.op )
{
case XENMEM_paging_op_nominate:
{
-return p2m_mem_paging_nominate(d, mpc-gfn);
+rc = p2m_mem_paging_nominate(d, mpo.gfn);
}
break;
case XENMEM_paging_op_evict:
{
-return p2m_mem_paging_evict(d, mpc-gfn);
+rc = p2m_mem_paging_evict(d, mpo.gfn);
}
break;
case XENMEM_paging_op_prep:
{
-unsigned long gfn = mpc-gfn;
-return p2m_mem_paging_prep(d, gfn, mpc-buffer);
+rc = p2m_mem_paging_prep(d, mpo.gfn, mpo.buffer);
}
break;
default:
-return -ENOSYS;
+rc = -ENOSYS;
break;
}
+
+if ( !rc __copy_to_guest(arg, mpo, 1) )
+rc = -EFAULT;
+
+return rc;
}
diff --git a/xen/arch/x86/mm/mem_sharing.c b/xen/arch/x86/mm/mem_sharing.c
index 4959407..612ed89 100644
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -28,6 +28,7 @@
#include xen/grant_table.h
#include xen/sched.h
#include xen/rcupdate.h
+#include xen/guest_access.h
#include xen/vm_event.h
#include asm/page.h
#include asm/string.h
@@ -1293,30 +1294,52 @@ int relinquish_shared_pages(struct domain *d)
return rc;
}
-int mem_sharing_memop(struct domain *d, xen_mem_sharing_op_t *mec)
+int mem_sharing_memop(unsigned long cmd,
+ XEN_GUEST_HANDLE_PARAM(xen_mem_sharing_op_t) arg)
{
-int rc = 0;
+int rc;
+xen_mem_sharing_op_t mso;
+struct domain *d;
+
+rc = -EFAULT;
+if ( copy_from_guest(mso, arg, 1) )
+return rc;
+
+if ( mso.op == XENMEM_sharing_op_audit )
+return mem_sharing_audit();
+
+rc = rcu_lock_live_remote_domain_by_id(mso.domain, d);
+if ( rc )
+return rc;
/* Only HAP is supported */
if ( !hap_enabled(d) || !d-arch.hvm_domain.mem_sharing_enabled )
return -ENODEV;
-switch(mec-op)
+rc = xsm_vm_event_op(XSM_DM_PRIV, d, XENMEM_sharing_op);
+if ( rc )
+return rc;
+
+rc = -ENODEV;
+if ( unlikely(!d-vm_event-share.ring_page) )
+return rc;
+
+switch(mso.op)
{
case XENMEM_sharing_op_nominate_gfn:
{
-unsigned long gfn = mec-u.nominate.u.gfn;
+unsigned long gfn = mso.u.nominate.u.gfn;
shr_handle_t handle;
if ( !mem_sharing_enabled(d) )
return -EINVAL;
rc = mem_sharing_nominate_page(d, gfn, 0, handle);
-mec-u.nominate.handle = handle;
+mso.u.nominate.handle = handle;
}
break;
case XENMEM_sharing_op_nominate_gref:
{
-grant_ref_t gref = mec-u.nominate.u.grant_ref;
+grant_ref_t gref = mso.u.nominate.u.grant_ref;
unsigned long gfn;
shr_handle_t handle;
@@ -1325,7 +1348,7 @@ int mem_sharing_memop(struct domain *d,
xen_mem_sharing_op_t *mec)
if ( mem_sharing_gref_to_gfn(d, gref, gfn) 0 )
return -EINVAL;
rc = mem_sharing_nominate_page(d, gfn, 3, handle);
-mec-u.nominate.handle = handle;
+mso.u.nominate.handle = handle;
[Xen-devel] [PATCH V4 06/13] tools/tests: Clean-up tools/tests/xen-access
The spin-lock implementation in the xen-access test program is implemented
in a fashion that is actually incomplete. The x86 assembly that guarantees that
the lock is held by only one thread lacks the lock; instruction.
However, the spin-lock is not actually necessary in xen-access as it is not
multithreaded. The presence of the faulty implementation of the lock in a non-
multithreaded environment is unnecessarily complicated for developers who are
trying to follow this code as a guide in implementing their own applications.
Thus, removing it from the code improves the clarity on the behavior of the
system.
Also converting functions that always return 0 to return to void, and making
the teardown function actually return an error code on error.
Signed-off-by: Tamas K Lengyel tamas.leng...@zentific.com
Acked-by: Ian Campbell ian.campb...@citrix.com
---
tools/tests/xen-access/xen-access.c | 99 +++--
1 file changed, 19 insertions(+), 80 deletions(-)
diff --git a/tools/tests/xen-access/xen-access.c
b/tools/tests/xen-access/xen-access.c
index 0a22a31..fe1589e 100644
--- a/tools/tests/xen-access/xen-access.c
+++ b/tools/tests/xen-access/xen-access.c
@@ -45,56 +45,6 @@
#define ERROR(a, b...) fprintf(stderr, a \n, ## b)
#define PERROR(a, b...) fprintf(stderr, a : %s\n, ## b, strerror(errno))
-/* Spinlock and mem event definitions */
-
-#define SPIN_LOCK_UNLOCKED 0
-
-#define ADDR (*(volatile long *) addr)
-/**
- * test_and_set_bit - Set a bit and return its old value
- * @nr: Bit to set
- * @addr: Address to count from
- *
- * This operation is atomic and cannot be reordered.
- * It also implies a memory barrier.
- */
-static inline int test_and_set_bit(int nr, volatile void *addr)
-{
-int oldbit;
-
-asm volatile (
-btsl %2,%1\n\tsbbl %0,%0
-: =r (oldbit), =m (ADDR)
-: Ir (nr), m (ADDR) : memory);
-return oldbit;
-}
-
-typedef int spinlock_t;
-
-static inline void spin_lock(spinlock_t *lock)
-{
-while ( test_and_set_bit(1, lock) );
-}
-
-static inline void spin_lock_init(spinlock_t *lock)
-{
-*lock = SPIN_LOCK_UNLOCKED;
-}
-
-static inline void spin_unlock(spinlock_t *lock)
-{
-*lock = SPIN_LOCK_UNLOCKED;
-}
-
-static inline int spin_trylock(spinlock_t *lock)
-{
-return !test_and_set_bit(1, lock);
-}
-
-#define vm_event_ring_lock_init(_m) spin_lock_init((_m)-ring_lock)
-#define vm_event_ring_lock(_m) spin_lock((_m)-ring_lock)
-#define vm_event_ring_unlock(_m) spin_unlock((_m)-ring_lock)
-
typedef struct vm_event {
domid_t domain_id;
xc_evtchn *xce_handle;
@@ -102,7 +52,6 @@ typedef struct vm_event {
vm_event_back_ring_t back_ring;
uint32_t evtchn_port;
void *ring_page;
-spinlock_t ring_lock;
} vm_event_t;
typedef struct xenaccess {
@@ -180,6 +129,7 @@ int xenaccess_teardown(xc_interface *xch, xenaccess_t
*xenaccess)
if ( rc != 0 )
{
ERROR(Error tearing down domain xenaccess in xen);
+return rc;
}
}
@@ -191,6 +141,7 @@ int xenaccess_teardown(xc_interface *xch, xenaccess_t
*xenaccess)
if ( rc != 0 )
{
ERROR(Error unbinding event port);
+return rc;
}
}
@@ -201,6 +152,7 @@ int xenaccess_teardown(xc_interface *xch, xenaccess_t
*xenaccess)
if ( rc != 0 )
{
ERROR(Error closing event channel);
+return rc;
}
}
@@ -209,6 +161,7 @@ int xenaccess_teardown(xc_interface *xch, xenaccess_t
*xenaccess)
if ( rc != 0 )
{
ERROR(Error closing connection to xen);
+return rc;
}
xenaccess-xc_handle = NULL;
@@ -241,9 +194,6 @@ xenaccess_t *xenaccess_init(xc_interface **xch_r, domid_t
domain_id)
/* Set domain id */
xenaccess-vm_event.domain_id = domain_id;
-/* Initialise lock */
-vm_event_ring_lock_init(xenaccess-vm_event);
-
/* Enable mem_access */
xenaccess-vm_event.ring_page =
xc_mem_access_enable(xenaccess-xc_handle,
@@ -314,19 +264,24 @@ xenaccess_t *xenaccess_init(xc_interface **xch_r, domid_t
domain_id)
return xenaccess;
err:
-xenaccess_teardown(xch, xenaccess);
+rc = xenaccess_teardown(xch, xenaccess);
+if ( rc )
+{
+ERROR(Failed to teardown xenaccess structure!\n);
+}
err_iface:
return NULL;
}
-int get_request(vm_event_t *vm_event, vm_event_request_t *req)
+/*
+ * Note that this function is not thread safe.
+ */
+static void get_request(vm_event_t *vm_event, vm_event_request_t *req)
{
vm_event_back_ring_t *back_ring;
RING_IDX req_cons;
-vm_event_ring_lock(vm_event);
-
back_ring = vm_event-back_ring;
req_cons = back_ring-req_cons;
@@ -337,19 +292,16 @@ int get_request(vm_event_t *vm_event, vm_event_request_t
*req)
/* Update ring */
back_ring-req_cons = req_cons;
back_ring-sring-req_event = req_cons + 1;
-
-vm_event_ring_unlock(vm_event);
Re: [Xen-devel] [PATCH 4/4] libxl: More probably detect reentry of destroyed ctx
Wei Liu writes (Re: [PATCH 4/4] libxl: More probably detect reentry of destroyed ctx): On Mon, Feb 09, 2015 at 03:51:12PM +, Ian Jackson wrote: In libxl_ctx_free: 1. Move the GC_INIT earlier, so that we can: Acked-by: Wei Liu wei.l...@citrix.com Thanks. +assert(!ctx-osevent_in_hook); +CTX-osevent_in_hook += 1000; It would be good if you add comment here to say this is used to help debugging. Good idea. I have done this: CTX-osevent_in_hook += 1000; /* make violations easier to debug */ Thanks for your acks. I will push this to staging now. I think at least 1-3 of these, and probably all of them, should be backported. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [OSSTEST PATCH 1/2] sg-report-job-history: Separate out $cond in queries
We are going to want to reuse this, so separate out the computation of
$cond and @params.
Signed-off-by: Ian Jackson ian.jack...@eu.citrix.com
---
sg-report-job-history | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/sg-report-job-history b/sg-report-job-history
index ee021b6..479e347 100755
--- a/sg-report-job-history
+++ b/sg-report-job-history
@@ -155,24 +155,21 @@ sub processjobbranch ($$) {
my @test_rows;
my $blessingscond= '('.join(' OR ', map { blessing=? } @blessings).')';
-my $stmt= END;
-SELECT *
- FROM jobs JOIN flights USING (flight)
- WHERE job = ?
- AND $blessingscond
-END
+my $cond = job = ? AND $blessingscond;
my (@params) = ($j, @blessings);
if (defined $bra) {
-$stmt .= END;
+$cond .= END;
AND branch = ?
END
push @params, $bra;
}
-$stmt .= END;
+my $flightsq= $dbh_tests-prepare(END);
+SELECT *
+ FROM jobs JOIN flights USING (flight)
+ WHERE ($cond)
ORDER BY flight DESC
LIMIT 100
END
-my $flightsq= $dbh_tests-prepare($stmt);
$flightsq-execute(@params);
while (my $f= $flightsq-fetchrow_hashref()) {
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH V4 04/13] xen/mem_access: Merge mem_event sanity check into mem_access check
The current sanity check when enabling mem_event is only applicable
to mem_access.
Signed-off-by: Tamas K Lengyel tamas.leng...@zentific.com
---
xen/common/mem_event.c | 4
xen/include/asm-x86/p2m.h | 8 +---
xen/include/public/domctl.h | 1 -
3 files changed, 1 insertion(+), 12 deletions(-)
diff --git a/xen/common/mem_event.c b/xen/common/mem_event.c
index 8a9119f..3ed6abc 100644
--- a/xen/common/mem_event.c
+++ b/xen/common/mem_event.c
@@ -621,10 +621,6 @@ int mem_event_domctl(struct domain *d,
xen_domctl_mem_event_op_t *mec,
case XEN_MEM_EVENT_MONITOR_ENABLE:
case XEN_MEM_EVENT_MONITOR_ENABLE_INTROSPECTION:
{
-rc = -ENODEV;
-if ( !p2m_mem_event_sanity_check(d) )
-break;
-
rc = mem_event_enable(d, mec, med, _VPF_mem_access,
HVM_PARAM_MONITOR_RING_PFN,
mem_access_notification);
diff --git a/xen/include/asm-x86/p2m.h b/xen/include/asm-x86/p2m.h
index e86e26f..20accc6 100644
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -600,16 +600,10 @@ void p2m_mem_event_emulate_check(struct vcpu *v,
/* Enable arch specific introspection options (such as MSR interception). */
void p2m_setup_introspection(struct domain *d);
-/* Sanity check for mem_event hardware support */
-static inline bool_t p2m_mem_event_sanity_check(struct domain *d)
-{
-return hap_enabled(d) cpu_has_vmx;
-}
-
/* Sanity check for mem_access hardware support */
static inline bool_t p2m_mem_access_sanity_check(struct domain *d)
{
-return is_hvm_domain(d);
+return is_hvm_domain(d) hap_enabled(d) cpu_has_vmx;
}
/*
diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
index 034cec7..3b4c2e2 100644
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -796,7 +796,6 @@ struct xen_domctl_gdbsx_domstatus {
*
* The XEN_MEM_EVENT_MONITOR_ENABLE* domctls return several
* non-standard error codes to indicate why access could not be enabled:
- * ENODEV - host lacks HAP support (EPT/NPT) or HAP is disabled in guest
* EBUSY - guest has or had access enabled, ring buffer still active
*
*/
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] dom0 kernel - irq nobody cared ... the continuing saga ..
Monday, February 9, 2015, 5:36:28 PM, you wrote: On 09.02.15 at 16:18, david.vra...@citrix.com wrote: On 09/02/15 15:03, Sander Eikelenboom wrote: Hi Jan / David / Konrad, I was just testing a 3.19 kernel on my intel machine and again ran into the sporadically appearing irq nobody cared on the dom0 kernel. This occurs now for quite some kernel versions (running xen-unstable now, but it also appeared in the past with builds that are now xen-4.5). I wouldn't suspect anything Xen related here. IRQ #18 is a shared line-level interrupt so other driver/device that was/is sharing than line is misbehaving. I'd recommend seeing if your BIOS has a option to put the disk controllers into AHCI mode which would allow them to use MSIs (I think). But iirc previous instances weren't always pointing at a disk controller, and hence dealing with that as a special case won't make the underlying problem go away. Sander, this looking different from previous reports of yours - is this different (or differently configured) hardware now? In which case knowing what other devices sit on that same IRQ would (again) be necessary, including which of them you pass to guests. Jan S-ata controller is already in AHCI mode and using MSI, it actually was the IDE controller that was on irq 18. Yes the device that tries to handle the interrupt seems to change .. however that device is always not actively used. This time it was an unused IDE controller with driver loaded in dom0 and a mini-pcie wifi card passed through to a guest. But i did a bios update like David suggested and now the IDE controller is gone (which is chipset only since it lacks a physical connector anyway). Now it is sharing the IRQ with the SMbus: 00:1f.3 SMBus: Intel Corporation 7 Series/C210 Series Chipset Family SMBus Controller (rev 04) Subsystem: Intel Corporation Device 204f Flags: medium devsel, IRQ 18 Memory at f7d35000 (64-bit, non-prefetchable) [size=256] I/O ports at f040 [size=32] 02:00.0 Network controller: Atheros Communications Inc. AR9285 Wireless Network Adapter (PCI-Express) (rev 01) Subsystem: Lenovo Device 30a1 Flags: bus master, fast devsel, latency 0, IRQ 18 Memory at f7c0 (64-bit, non-prefetchable) [size=64K] Capabilities: [40] Power Management version 3 Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit- Capabilities: [60] Express Legacy Endpoint, MSI 00 Capabilities: [100] Advanced Error Reporting Capabilities: [140] Virtual Channel Capabilities: [160] Device Serial Number 00-00-00-00-00-00-00-00 Capabilities: [170] Power Budgeting ? Kernel driver in use: pciback Why it seems so keen on interrupt sharing eludes me completely. Also wondering why it doesn't enable MSI on the WIFI NIC, but perhaps the driver doesn't support it .. will have to look at that later and see what it does when booting baremetal. -- Sander ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] x86 spinlock: Fix memory corruption on completing completions
On Mon, Feb 9, 2015 at 4:02 AM, Peter Zijlstra pet...@infradead.org wrote: On Mon, Feb 09, 2015 at 03:04:22PM +0530, Raghavendra K T wrote: So we have 3 choices, 1. xadd 2. continue with current approach. 3. a read before unlock and also after that. For the truly paranoid we have probe_kernel_address(), suppose the lock was in module space and the module just got unloaded under us. That's much too expensive. The xadd shouldn't be noticeably more expensive than the current add_smp(). Yes, lock xadd used to be several cycles slower than just lock add on some early cores, but I think these days it's down to a single-cycle difference, which is not really different from doing a separate load after the add. The real problem with xadd used to be that we always had to do magic special-casing for i386, but that's one of the reasons we dropped support for original 80386. So I think Raghavendra's last version (which hopefully fixes the lockup problem that Sasha reported) together with changing that add_smp(lock-tickets.head, TICKET_LOCK_INC); if (READ_ONCE(lock-tickets.tail) TICKET_SLOWPATH_FLAG) .. into something like val = xadd((lock-ticket.head_tail, TICKET_LOCK_INC TICKET_SHIFT); if (unlikely(val TICKET_SLOWPATH_FLAG)) ... would be the right thing to do. Somebody should just check that I got that shift right, and that the tail is in the high bytes (head really needs to be high to work, if it's in the low byte(s) the xadd would overflow from head into tail which would be wrong). Linus ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] modify the IO_TLB_SEGSIZE to io_tlb_segsize configurable as flexible requirement about SW-IOMMU.
Dear Wilk: -Original Message- From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com] Sent: Monday, February 9, 2015 11:36 PM To: Wang, Xiaoming Cc: r...@linux-mips.org; boris.ostrov...@oracle.com; david.vra...@citrix.com; linux-m...@linux-mips.org; linux- ker...@vger.kernel.org; xen-de...@lists.xenproject.org; akpm@linux- foundation.org; li...@horizon.com; lau...@codeaurora.org; heiko.carst...@de.ibm.com; d.kasat...@samsung.com; takahiro.aka...@linaro.org; ch...@chris-wilson.co.uk; pebo...@tiscali.nl; Liu, Chuansheng; Zhang, Dongxing Subject: Re: [PATCH] modify the IO_TLB_SEGSIZE to io_tlb_segsize configurable as flexible requirement about SW-IOMMU. On Mon, Feb 09, 2015 at 02:13:30AM +, Wang, Xiaoming wrote: Dear Wilk: -Original Message- From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com] Sent: Saturday, February 7, 2015 2:12 AM To: Wang, Xiaoming Cc: r...@linux-mips.org; boris.ostrov...@oracle.com; david.vra...@citrix.com; linux-m...@linux-mips.org; linux- ker...@vger.kernel.org; xen-de...@lists.xenproject.org; akpm@linux- foundation.org; li...@horizon.com; lau...@codeaurora.org; heiko.carst...@de.ibm.com; d.kasat...@samsung.com; takahiro.aka...@linaro.org; ch...@chris-wilson.co.uk; pebo...@tiscali.nl; Liu, Chuansheng; Zhang, Dongxing Subject: Re: [PATCH] modify the IO_TLB_SEGSIZE to io_tlb_segsize configurable as flexible requirement about SW-IOMMU. On Fri, Feb 06, 2015 at 12:10:15AM +, Wang, Xiaoming wrote: -Original Message- From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com] Sent: Friday, February 6, 2015 3:33 AM To: Wang, Xiaoming Cc: r...@linux-mips.org; boris.ostrov...@oracle.com; david.vra...@citrix.com; linux-m...@linux-mips.org; linux- ker...@vger.kernel.org; xen-de...@lists.xenproject.org; akpm@linux- foundation.org; li...@horizon.com; lau...@codeaurora.org; heiko.carst...@de.ibm.com; d.kasat...@samsung.com; takahiro.aka...@linaro.org; ch...@chris-wilson.co.uk; pebo...@tiscali.nl; Liu, Chuansheng; Zhang, Dongxing Subject: Re: [PATCH] modify the IO_TLB_SEGSIZE to io_tlb_segsize configurable as flexible requirement about SW-IOMMU. On Fri, Feb 06, 2015 at 07:01:14AM +0800, xiaomin1 wrote: The maximum of SW-IOMMU is limited to 2^11*128 = 256K. While in different platform and different requirements this seems improper. So modify the IO_TLB_SEGSIZE to io_tlb_segsize as configurable is make sense. More details please. What is the issue you are hitting? Example: If 1M bytes are requied. There has an error like. Ok, but even with 1MB size - you only have 64 'slots' (if you allocate an 64MB buffer). And the other 'slots' can be fragmented so you might still not have enough 1MB chunks available. Do you have some thoughts on how that would be addressed? Yes, If IO_TLB_SEGSIZE is 128 the slabs is 32K/128 = 256 While IO_TLB_SEGSIZE is 512 the slabs is 32K/512 =64 (for 1M). So it is dilemma between slabs and segsize. Right. I have a thought how about modifying the IO_TLB_DEFAULT_SIZE to io_tlb_default_size configurable too? It would seem that 'io_tlb_default_size' should be influenced by the 'io_tlb_segsize' - as in have some calculation that would come up with the best value (if there is one?) I am not sure if the 256 number of slabs is a standard . If so there has a fixed calculation between 'io_tlb_default_size' and 'io_tlb_segsize' But if 'io_tlb_default_size' is limited as 64M in some platforms, while the max segsize is required as 1M, we have to sacrifice the slabs to meet segsize. So leaving 'io_tlb_default_size' and 'io_tlb_segsize' independent is better, I think. Because of the multivariate requirement. [ 31.474769] dwc3_otg :00:16.0: dwc3_intel_byt_notify_charger_type(): dwc3_intel_byt_notify_charger_type: invalid SDP current! [ 31.554077] android_work: sent uevent USB_STATE=CONNECTED [ 31.564244] android_usb gadget: high-speed config #1: android [ 31.571468] android_work: sent uevent USB_STATE=CONFIGURED [ 31.942738] DMA: Out of SW-IOMMU space for 1048576 bytes at device gadget [ 31.950345] Kernel panic - not syncing: DMA: Random memory could be DMA written [ 31.950345] [ 31.960170] CPU: 1 PID: 172 Comm: droidboot Tainted: GW 3.10.20-x86_64_byt-g1077f87 #2 [ 31.970086] Hardware name: Intel Corp. VALLEYVIEW C0 PLATFORM/BYT-T FFD8, BIOS BLADE_21.X64.0004.R14.1412311144 FFD8_X64_R_2014_12_31_1151 12/31/2014 [ 31.985053] 0010 880136c2fc98 82967d45 880136c2fd10 [ 31.993327] 82961761 0008 880136c2fd20 880136c2fcc0 [ 32.001590] 829618fb 0002 820aeff9 8d8c [ 32.009871]
Re: [Xen-devel] [edk2] [PATCH v3 21/27] Ovmf/Xen: add ARM and AArch64 support to XenBusDxe
Hi Ard,
I did an implementation of BaseSynchronizationLib for ARM(32) a couple years
ago. I am not sure why I have never pushed this patch upstream.
Anyway, feel free to use it and push it upstream after reviewing it and adding
support for AArch64.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Olivier Martin olivier.mar...@arm.com
Thanks,
Olivier
From: Jordan Justen [jordan.l.jus...@intel.com]
Sent: 07 February 2015 22:00
To: Ard Biesheuvel; Kinney, Michael D
Cc: edk2-de...@lists.sourceforge.net; Laszlo Ersek; Olivier Martin; Roy Franz;
Leif Lindholm; Stefano Stabellini; ian.campb...@citrix.com; Anthony PERARD;
Christoffer Dall; xen-devel@lists.xen.org; Ilias Biris; Julien Grall
Subject: Re: [edk2] [PATCH v3 21/27] Ovmf/Xen: add ARM and AArch64 support to
XenBusDxe
On 2015-02-05 01:56:04, Ard Biesheuvel wrote:
On 4 February 2015 at 21:10, Jordan Justen jordan.l.jus...@intel.com wrote:
On 2015-02-03 11:20:06, Ard Biesheuvel wrote:
This patch adds support to XenBusDxe for executing on ARM and AArch64
machines (the former only when built with GCC).
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
OvmfPkg/XenBusDxe/AtomicsGcc.c | 44
+
OvmfPkg/XenBusDxe/XenBusDxe.inf | 3 +++
2 files changed, 47 insertions(+)
create mode 100644 OvmfPkg/XenBusDxe/AtomicsGcc.c
diff --git a/OvmfPkg/XenBusDxe/AtomicsGcc.c
b/OvmfPkg/XenBusDxe/AtomicsGcc.c
new file mode 100644
index ..a0bdcbf67440
--- /dev/null
+++ b/OvmfPkg/XenBusDxe/AtomicsGcc.c
@@ -0,0 +1,44 @@
+/** @file
+ Arch-independent implementations of XenBusDxe atomics using GCC
__builtins
+
+ Copyright (C) 2014, Linaro Ltd.
+
+ This program and the accompanying materials
+ are licensed and made available under the terms and conditions of the
BSD License
+ which accompanies this distribution. The full text of the license may
be found at
+ http://opensource.org/licenses/bsd-license.php
+
+ THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN AS IS BASIS,
+ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR
IMPLIED.
+
+**/
+
+UINT16
+EFIAPI
+InternalSyncCompareExchange16 (
+ IN volatile UINT16 *Value,
+ IN UINT16CompareValue,
+ IN UINT16ExchangeValue
Can you instead get InterlockedCompareExchange16 added to
BaseSynchronizationLib?
http://permalink.gmane.org/gmane.comp.bios.tianocore.devel/10470
That would seem the obvious choice, but sadly, BaseSynchronizationLib
is not implemented at all for ARM and AArch64 (Some .c files are there
but they are just unsynchronized C implementations)
So in order to do this properly, I would need to
- implement the existing functions for ARM and AArch64
Would you? It appears the library is already used by ARM platforms as
is.
If you add your InterlockedCompareExchange16, it is at least an
improvement, right?
- implement InterlockedCompareExchange16 () for all existing
architectures, including IPF, which I don't have a clue about, and
toolchains I don't have access to
Mike, you added the IPF InterlockedCompareExchange32.s and
InterlockedCompareExchange64.s files. Could you help to provide a
InterlockedCompareExchange16.s?
- implement TestAndClearBit () for all architectures, or create a
BaseBitopsLib and implement it there
I only meant to add InterlockedCompareExchange16 for now.
-Jordan
I now understand how Anthony ended up doing it like this in the first place
:-)
Anyway, we are all invested in improving the code base, so I am happy
to do my part, but I would need help from others to implement the
pieces that are really not feasible for me to take on.
--
Ard.
+ )
+{
+ return __sync_val_compare_and_swap_2 (Value, CompareValue,
ExchangeValue);
+}
+
+INT32
+EFIAPI
+TestAndClearBit (
+ IN INT32Bit,
+ IN volatile VOID*Address
+ )
+{
+ //
+ // Calculate the effective address relative to 'Address' based on the
+ // higher order bits of 'Bit'. Use signed shift instead of division to
+ // ensure we round towards -Inf, and end up with a positive shift in
'Bit',
+ // even if 'Bit' itself is negative.
+ //
+ Address += (Bit 5) * sizeof(INT32);
+ Bit = 31;
+
+ return (__sync_fetch_and_and_4 (Address, ~(1U Bit)) (1U Bit))
!= 0;
+}
diff --git a/OvmfPkg/XenBusDxe/XenBusDxe.inf
b/OvmfPkg/XenBusDxe/XenBusDxe.inf
index 31553ac5a64a..949ec0a0c732 100644
--- a/OvmfPkg/XenBusDxe/XenBusDxe.inf
+++ b/OvmfPkg/XenBusDxe/XenBusDxe.inf
@@ -54,6 +54,9 @@
X64/InterlockedCompareExchange16.nasm
X64/TestAndClearBit.nasm
+[Sources.AARCH64, Sources.ARM]
+ AtomicsGcc.c | GCC
+
[LibraryClasses]
UefiDriverEntryPoint
Re: [Xen-devel] [PATCH v3 04/27] ArmVirtualizationPkg: add GICv3 detection to VirtFdtDxe
The main comment I will make on this patch is to rename redistributor
interface into redistributor region.
The Device Tree binding actually defines the entry as 'GIC Redistributor
region' or 'GIC Redistributors':
http://lxr.free-electrons.com/diff/Documentation/devicetree/bindings/arm/gic-v3.txt?diffvar=v;diffval=3.4
The GIC redistributor region contains the GIC redistributors for all the
cores.
On 03/02/15 19:19, Ard Biesheuvel wrote:
This adds support for detecting the presence of a GICv3 interrupt
controller from the device tree, and recording its distributor and
redistributor base addresses in their respective PCDs.
Contributed-under: TianoCore Contribution Agreement 1.0
Acked-by: Laszlo Ersek ler...@redhat.com
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
Removed Olivier's R-b due to the fact that this patch was changed to
accomodate pending but not yet finalized changes to the GICv3 driver.
I think that recording the distributor and redistributor base addresses
should be sufficient in any case, but we may have to revisit this still
when the GIC dust settles.
.../ArmVirtualizationPkg/ArmVirtualizationQemu.dsc | 1 +
.../ArmVirtualizationPkg/VirtFdtDxe/VirtFdtDxe.c | 31 +-
.../ArmVirtualizationPkg/VirtFdtDxe/VirtFdtDxe.inf | 1 +
3 files changed, 32 insertions(+), 1 deletion(-)
diff --git a/ArmPlatformPkg/ArmVirtualizationPkg/ArmVirtualizationQemu.dsc
b/ArmPlatformPkg/ArmVirtualizationPkg/ArmVirtualizationQemu.dsc
index 32c8deb3b1d6..f38ffd034a59 100644
--- a/ArmPlatformPkg/ArmVirtualizationPkg/ArmVirtualizationQemu.dsc
+++ b/ArmPlatformPkg/ArmVirtualizationPkg/ArmVirtualizationQemu.dsc
@@ -172,6 +172,7 @@
# ARM General Interrupt Controller
#
gArmTokenSpaceGuid.PcdGicDistributorBase|0x0
+ gArmTokenSpaceGuid.PcdGicRedistributorBase|0x0
gArmTokenSpaceGuid.PcdGicInterruptInterfaceBase|0x0
## PL031 RealTimeClock
diff --git a/ArmPlatformPkg/ArmVirtualizationPkg/VirtFdtDxe/VirtFdtDxe.c
b/ArmPlatformPkg/ArmVirtualizationPkg/VirtFdtDxe/VirtFdtDxe.c
index 1d44f9ba02b3..e8bbea0847c0 100644
--- a/ArmPlatformPkg/ArmVirtualizationPkg/VirtFdtDxe/VirtFdtDxe.c
+++ b/ArmPlatformPkg/ArmVirtualizationPkg/VirtFdtDxe/VirtFdtDxe.c
@@ -46,6 +46,7 @@ typedef enum {
PropertyTypeTimer,
PropertyTypePsci,
PropertyTypeFwCfg,
+ PropertyTypeGicV3,
} PROPERTY_TYPE;
typedef struct {
@@ -62,6 +63,7 @@ STATIC CONST PROPERTY CompatibleProperties[] = {
{ PropertyTypeTimer, arm,armv8-timer },
{ PropertyTypePsci,arm,psci-0.2},
{ PropertyTypeFwCfg, qemu,fw-cfg-mmio},
+ { PropertyTypeGicV3, arm,gic-v3 },
{ PropertyTypeUnknown, }
};
@@ -114,7 +116,7 @@ InitializeVirtFdtDxe (
VIRTIO_TRANSPORT_DEVICE_PATH *DevicePath;
EFI_HANDLE Handle;
UINT64 RegBase;
- UINT64 DistBase, CpuBase;
+ UINT64 DistBase, CpuBase, RedistBase;
CONST INTERRUPT_PROPERTY *InterruptProp;
INT32 SecIntrNum, IntrNum, VirtIntrNum, HypIntrNum;
CONST CHAR8*PsciMethod;
@@ -256,6 +258,33 @@ InitializeVirtFdtDxe (
DEBUG ((EFI_D_INFO, Found GIC @ 0x%Lx/0x%Lx\n, DistBase, CpuBase));
break;
+case PropertyTypeGicV3:
+ //
+ // The GIC v3 DT binding describes a series of at least 3 physical base
+ // addresses: the distributor interface (GICD), at least one
redistributor
+ // interface (GICR) and the CPU interface (GICC).
+ // Under virtualization, we assume that the first redistributor interface
+ // listed covers the boot CPU. Also, our GICv3 driver only supports the
+ // system register CPU interface, so we can safely ignore the MMIO
version
+ // which is listed after the sequence of redistributor interfaces.
+ // This means we are only interested in the first two memory regions
+ // supplied, and ignore everything else.
+ //
+ ASSERT (Len = 32);
+
+ DistBase = fdt64_to_cpu (((UINT64 *)RegProp)[0]);
+ ASSERT (DistBase MAX_UINT32);
+
+ RedistBase = fdt64_to_cpu (((UINT64 *)RegProp)[2]);
Add a comment about [2] to understand where it is come from
+ ASSERT (RedistBase MAX_UINT32);
+
+ PcdSet32 (PcdGicDistributorBase, (UINT32)DistBase);
+ PcdSet32 (PcdGicRedistributorBase, (UINT32)RedistBase);
+
+ DEBUG ((EFI_D_INFO, Found GIC v3 (re)distributor @ 0x%Lx (0x%Lx)\n,
+DistBase, RedistBase));
+ break;
+
case PropertyTypeRtc:
ASSERT (Len == 16);
diff --git a/ArmPlatformPkg/ArmVirtualizationPkg/VirtFdtDxe/VirtFdtDxe.inf
b/ArmPlatformPkg/ArmVirtualizationPkg/VirtFdtDxe/VirtFdtDxe.inf
index 514ce2fdf658..dbf0f8eb54bc 100644
--- a/ArmPlatformPkg/ArmVirtualizationPkg/VirtFdtDxe/VirtFdtDxe.inf
+++ b/ArmPlatformPkg/ArmVirtualizationPkg/VirtFdtDxe/VirtFdtDxe.inf
@@ -51,6 +51,7 @@
[Xen-devel] [GIT PULL] xen: features and fixes for 3.20-rc0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Linus, Please git pull the following tag: git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git stable/for-linus-3.20-rc0-tag xen: features and fixes for 3.20-rc0 - - Reworked handling for foreign (grant mapped) pages to simplify the code, enable a number of additional use cases and fix a number of long-standing bugs. - - Prefer the TSC over the Xen PV clock when dom0 (and the TSC is stable). - - Assorted other cleanup and minor bug fixes. Thanks. David arch/arm/include/asm/xen/page.h |2 +- arch/arm/xen/enlighten.c |4 +- arch/arm/xen/mm.c|2 +- arch/arm/xen/p2m.c |2 +- arch/x86/include/asm/xen/page.h | 20 +-- arch/x86/xen/mmu.c | 17 +- arch/x86/xen/p2m.c | 267 ++ arch/x86/xen/setup.c | 37 ++--- arch/x86/xen/smp.c |2 +- arch/x86/xen/time.c |4 + arch/x86/xen/xen-ops.h |6 + drivers/block/xen-blkback/blkback.c | 177 ++-- drivers/block/xen-blkback/common.h |3 + drivers/net/xen-netback/interface.c |7 +- drivers/net/xen-netback/netback.c| 106 +--- drivers/xen/balloon.c| 86 +- drivers/xen/gntdev.c | 143 drivers/xen/grant-table.c| 120 +- drivers/xen/manage.c |8 +- drivers/xen/tmem.c |2 +- drivers/xen/xen-scsiback.c |6 +- drivers/xen/xenbus/xenbus_dev_frontend.c | 11 +- include/linux/mm.h |8 + include/linux/page-flags.h |5 + include/xen/grant_table.h| 43 - include/xen/interface/features.h |6 + include/xen/interface/grant_table.h |7 + mm/memory.c |2 + 28 files changed, 509 insertions(+), 594 deletions(-) Chuck Tuffli (1): arm64: Relax licensing of arm64 Xen DMA operations David Vrabel (7): mm: provide a find_special_page vma operation xen/grant-table: pre-populate kernel unmap ops for xen_gnttab_unmap_refs() xen: remove scratch frames for ballooned pages and m2p override xen/grant-table: add helpers for allocating pages xen/gntdev: convert priv-lock to a mutex xen/gntdev: mark userspace PTEs as special on x86 PV guests xen/gntdev: provide find_special_page VMA operation Davidlohr Bueso (1): x86,xen: use current-state helpers Jan Beulich (1): xen/tmem: mark xen_tmem_init() __init Jennifer Herbert (8): mm: add 'foreign' alias for the 'pinned' page flag x86/xen: require ballooned pages for grant maps xen: mark grant mapped pages as foreign xen-netback: use foreign page information from the pages themselves xen/grant-table: add a mechanism to safely unmap pages that are in use xen/gntdev: safely unmap grants in case they are still in use xen-blkback: safely unmap grants in case they are still in use xenbus: Add proper handling of XS_ERROR from Xenbus for transactions. Juergen Gross (5): x86/xen: cleanup arch/x86/xen/setup.c x86/xen: use correct types for addresses in arch/x86/xen/setup.c x86/xen: add some __init and static annotations in arch/x86/xen/setup.c x86/xen: add some __init annotations in arch/x86/xen/mmu.c x86/xen: cleanup arch/x86/xen/mmu.c Palik, Imre (1): x86/xen: prefer TSC over xen clocksource for dom0 Ross Lagerwall (1): xen/manage: Fix USB interaction issues when resuming -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBAgAGBQJU2JHIAAoJEFxbo/MsZsTRCvoH/Rm+BrUTtIxVz8mSp34FMIrS RI9rrwFncj0FzSeTYUzFcugjrNE7x7kJ2AZom7mZPWYId7LlucFUSA0caBh1bf77 E5Hq+sb26WoGfXvqt5Oalpw9FGdSrdZOuZRDiOGEJWvceg2NdC142ZbM8Zj1tuD2 9g15XunAyc22k1Z8DCGWemruq8lXk78X5bzQGymlPemoMCjfhW+9MSg9Nxh0r9LC EGonQeGlxfVYYpLRUvqrgbfWTcuSvkbEDriCJ+Ba6q0d3Mdlxytr82f5pQ732BhM 2g+GwHCQO6xbF/aeDEirDlKNrY6EY0sVApYun4d0BTx2KyBPJCnwpoWfjZWYCVM= =979c -END PGP SIGNATURE- ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [Qemu-devel] [v2][PATCH] libxl: add one machine property to support IGD GFX passthrough
On Mon, 2015-02-09 at 14:28 +0800, Chen, Tiejun wrote: What about this? I've not read the code in detail,since I'm travelling but from a quick glance it looks to be implementing the sort of thing I meant, thanks. A couple of higher level comments: I'd suggest to put the code for reading the vid/did into a helper function so it can be reused. You might like to optionally consider add a forcing option somehow so that people with new devices not in the list can control things without the need to recompile (e.g. gfx_passthru_kind_override?). Perhaps that isn't needed for a first cut though and it would be a libxl API so thought required. I think it should probably log something at a lowish level when it has autodetected IGD. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] x86/nmi: Fix shootdown of pcpus running in VMX non-root mode
Hi, At 11:25 + on 09 Feb (1423477508), Andrew Cooper wrote: In the case of a crash, nmi_shootdown_cpus() patches nmi_crash() into the IDT of each processor, such that the next NMI it receives will force it into the crash path. c/s 7dd3b06ff vmx: fix handling of NMI VMEXIT fixed one issue but inadvertently introduced another. The original use of self_nmi() would follow vector #2, but a direct call to do_nmi() does not. Introduce a function pointer which should be used in preference to direct do_nmi() calls, which is updated on the crash path to point at do_nmi_crash() Signed-off-by: Andrew Cooper andrew.coop...@citrix.com CC: Jan Beulich jbeul...@suse.com CC: Tim Deegan t...@xen.org --- This patch very certainly functions correctly (it is in active use now in a customer escalation), but I was wondering how paranoid we should be about interleaved reads/writes and whether an atomic write would be better? Performance is not a issue at all but in a crash senario we don't want to be taking any chances with correctness. Yes, atomic updates sound like a good idea. Would it make sense to add a _get_gate() or similar so the vmx path can read the actual IDT rather than adding a _third_ place where we set what to do on NMI? If not... --- a/xen/include/asm-x86/processor.h +++ b/xen/include/asm-x86/processor.h @@ -522,9 +522,10 @@ DECLARE_TRAP_HANDLER(alignment_check); #undef DECLARE_TRAP_HANDLER_CONST #undef DECLARE_TRAP_HANDLER +extern void (*nmi_handler)(const struct cpu_user_regs *regs); ...please add a comment here describing what's going on - in particular that changing this variable doesn't change the handler for all NMI paths (and that for most purposes set_nmi_callback() is more suitable). Cheers, Tim. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] question about memory allocation for driver domain
On Mon, Feb 9, 2015 at 10:31 AM, Julien Grall julien.gr...@linaro.org wrote: On 07/02/2015 01:15, Oleksandr Tyshchenko wrote: Hi Julien Hi Oleksandr, Hi Julien On Thu, Feb 5, 2015 at 6:36 PM, Oleksandr Tyshchenko Let me describe in detail about solution #3 before answer to your question. Maybe I missed something in the first mail. Also the Ian's answer clarified to me some points. We don't have complete solution for now. We only have temporally solution in which we relied on assumptions which might or not be acceptable, but it seems that the approach in general could work. If it is true the our target is to rewrite/rework this stuff, to make it more cleaner and correct from XEN point of view for platforms which doesn't have a SMMU even in the case where this stuff never reaches upstream. To run driver domain (domd) on OMAP5 platform with 1:1 mapping we did next preparations: (here I try to explain about memory allocation only, IRQ handling and other things are out of scope for the current thread) 1. Since the domd can use 128/256/512 Mb of RAM we modified existing populate_guest_memory() in xc_dom_arm.c to allow to allocate 128/256/512 Mb memory chunks. 2. Since the default rambase (0x4000) doesn't suitable for us for some reasons: - OMAP5 platform has memory mapped registers, starting from 0x480 - We have 2 guest domains (domd and domU) so it should be different rambases for them we added ability for toolstack to pass it via domain config file. While the overlapping is true on this Xen 4.5, we may decide to re-arrange the memory layout and put the GIC MMIOs on 0x480. A more generic solution would be to re-use the memory layout of the host. So a 1:1 mapping for MMIO and RAM would avoid overlapping with possible virtual region. I remembered to talk about it with Ian few months ago but we didn't have a practical use case at this time. FWIW, x86 has a similar solution via the e820_host param. 3. Since for domd we need one contiguous chunk of memory we created a new function allocate_domd_memory_11() in common/memory.c for the next purposes: - To allocate one contiguous memory chunk with specified order (as it was done for dom0) - To add this allocated chunk to the guest - domd (via guest_physmap_add_page(), taking into account that mfn=gpfn) 4. Since we need to allocate memory before any operation with it we created hook for XENMEM_populate_physmap command. Here we relied on the assumption that the domain_id for domd is always 1 (it is not true after the domd has been created again after destroying). During first XENMEM_populate_physmap command we set is_privileged=true and call allocate_domd_memory_11(), during next commands - call populate_physmap() as a usual. The is_domain_direct_mapped condition is a our case in populate_physmap(). I know that it is a very, very hacking solution). But, let's continue... How it works at the moment? 1. Create domd with default rambase_pfn (0x8000). 2. See what the mfn we got in allocate_domd_memory_11(). 3. Set rambase_pfn=mfn in config file. If the system configuration (N domains, domains memory, etc.) is not changed, we will always get the same mfn. If we decided to change something, for example, domd memory we need to repeat steps 2 and 3. Yes, looks not good. How it should works? The approach is to tailor the domd address map to the contiguous region the allocator gives us. So, a guest rambase (gpfn) must based on mfn of a page we have allocated successfully. Without any manual actions. I think it must be done in next steps: 1. Add a separate command, XENMEM_alloc_memory_11 or something similar and it should be issued before call xc_dom_rambase_init() in libxl_dom.c in case of presence domd_memory_11 property in config file only. This should remove terrible hook and anything related to d-domain_id=1 in common/memory.c. 2. Pass returned by XENMEM_alloc_memory_11 result to the xc_dom_rambase_init(). What are the advantages in compare with solution #1 and solution #2. 1. There is no need to add standalone allocator or modifying existing. Let's return to your question about created/destroyed domd multiple times. I have tried to do this with solution we have at the moment. I added some modifications to allow me to destroy/create domd multiple times. And I have seen that the allocator always returns the same page. This means that the all memory allocated for domd have been returned to the heap. Am I right? Or perhaps did you mean that this may happens with the completed solution? It seems logical to me that destroy/create domd in a row working fine. But this use-case is too simple :). Let's imagine we decide to start classical domains (i.e no 1:1 mapping) before creating domd (the 1:1 domain). As the free memory may be sparsed, allocating one large RAM region may not work and therefore the domain allocation fail. On a similar idea, the host RAM
Re: [Xen-devel] Guidelines for new PV protocol submission
El 05/02/15 a les 11.42, Ian Campbell ha escrit: On Tue, 2015-01-20 at 13:47 +0100, Roger Pau Monné wrote: Hello, I should probably have done this earlier because I've been aware of this issue for a long time (since I've started dealing with the PV blk protocol). The current way to describe PV protocols in Xen is very inefficient IMHO. Using C structs as the description of a binary protocol seems very wrong, specially taking into account that different ABIs can generate different layouts for the same C struct. This is for example a problem in the PV blk protocol, since the binary layout of the structures change depending on the bitness. In order to avoid this, I would like to request that any new PV protocol that's added to Xen be described in binary terms, just like it's normally done with other protocols. As a reference see for example the following section from the TCP RFC: http://tools.ietf.org/html/rfc793#page-15 How about on the next doc day I'll convert netif.h and you do blkif.h? Sounds like a plan, although I think I got the short straw ;). Roger. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] question about memory allocation for driver domain
On 09/02/2015 18:53, Ian Campbell wrote: On Mon, 2015-02-09 at 16:31 +0800, Julien Grall wrote: It seems logical to me that destroy/create domd in a row working fine. But this use-case is too simple :). Let's imagine we decide to start classical domains (i.e no 1:1 mapping) before creating domd (the 1:1 domain). As the free memory may be sparsed, allocating one large RAM region may not work and therefore the domain allocation fail. On a similar idea, the host RAM may be split on multiple non-contiguous banks. In this case, the RAM size of the 1:1 domain cannot be bigger than the size of the bank. You will never know which bank is used, as IIRC, the allocator behavior change between debug and non-debug build. We had the same issue on DOM0 before the support of multiple banks has been added. It sounds like you may want multiple bank support for an upstream use case. It seems to me that any use of 1:1 memory for !dom0 needs to be from a preallocated region which is allocated for this purpose at boot and then reserved for this specific allocation. e.g. lets imagine a hypervisor option mem_11_reserve=256M,256M,128M which would, at boot time, allocate 2x 256M contiguous regions and 1x128M one. When building a guest some mechanism (new hypercall, some other other trickery etc) indicates that the guest being built is supposed to use one of these regions instead of the usual domheap allocator. This would allow for a boot time configurable number of 1:1 regions. I think this would work for the embedded use case since the domains which have these special properties are well defined in size and number and so can be allocated up front. That seems a fair trade to use 1:1 mapping for domain. And it doesn't modify the allocator. The next problem is ballooning. When the guest balloon out memory, the page will be freed by Xen and can be re-used by another domain. I think we need to do as we do for 1:1 dom0 here and not hand back the memory on decrease reservation, but instead punch a hole in the p2m but keep the mfn in reserve. It sounds a fair trade in order to support 1:1 domain mapping. IOW ballooning is not supported for such domains (we only go as far as punching the hole to allow for the other usecase of ballooning which is to make a p2m hole for the Xen backend driver to use for grant maps) If I'm not mistaken, netback is balloon out to allocate some pages. But yeah, as you said, extending the DOM0 1:1 concept would avoid a such problem. The code for the 1:1 mapping in Xen (aside the allocation) is domain-agnostic. Oleksandr, I think modifying is_domain_direct_mapped (include/asm-arm/domain.h) should be enough here. The last problem but not the least is, depending on which backend you are running in the 1:1 domain (such blkback), grant won't be mapped 1:1 to the guest, so you will have to use swiotlb in order to use the right DMA address. For instance, without swiotlb, guest won't be able to use a disk partition via blkfront. This because the backend is giving directly the grant address to the block driver. To solve this, we have to use swiotlb and set specific DMA callback. For now, there are only used for DOM0. Not much we can do here except extend the dom0 code here to conditionally enable itself for other domains. You mean in the guest kernel? Maybe we have to introduce a new feature flags indicating is the domain is using 1:1 mapping or not? It would help in Xen code too. Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] x86/nmi: Fix shootdown of pcpus running in VMX non-root mode
On 09/02/15 11:43, Tim Deegan wrote: Hi, At 11:25 + on 09 Feb (1423477508), Andrew Cooper wrote: In the case of a crash, nmi_shootdown_cpus() patches nmi_crash() into the IDT of each processor, such that the next NMI it receives will force it into the crash path. c/s 7dd3b06ff vmx: fix handling of NMI VMEXIT fixed one issue but inadvertently introduced another. The original use of self_nmi() would follow vector #2, but a direct call to do_nmi() does not. Introduce a function pointer which should be used in preference to direct do_nmi() calls, which is updated on the crash path to point at do_nmi_crash() Signed-off-by: Andrew Cooper andrew.coop...@citrix.com CC: Jan Beulich jbeul...@suse.com CC: Tim Deegan t...@xen.org --- This patch very certainly functions correctly (it is in active use now in a customer escalation), but I was wondering how paranoid we should be about interleaved reads/writes and whether an atomic write would be better? Performance is not a issue at all but in a crash senario we don't want to be taking any chances with correctness. Yes, atomic updates sound like a good idea. Would it make sense to add a _get_gate() or similar so the vmx path can read the actual IDT rather than adding a _third_ place where we set what to do on NMI? A _get_gate() would return nmi() or nmi_crash() rather than do_nmi() or do_nmi_crash(). The latter pair is needed as we are already executing in C context rather than coming straight in from an interrupt. If not... --- a/xen/include/asm-x86/processor.h +++ b/xen/include/asm-x86/processor.h @@ -522,9 +522,10 @@ DECLARE_TRAP_HANDLER(alignment_check); #undef DECLARE_TRAP_HANDLER_CONST #undef DECLARE_TRAP_HANDLER +extern void (*nmi_handler)(const struct cpu_user_regs *regs); ...please add a comment here describing what's going on - in particular that changing this variable doesn't change the handler for all NMI paths (and that for most purposes set_nmi_callback() is more suitable). Good point. I will respin with some more atomicity and comments. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC 7/7] libxl: Wait for QEMU startup in stubdomain
On Mon, Feb 09, 2015 at 09:07:13AM +, Ian Campbell wrote: On Fri, 2015-02-06 at 17:23 +, Stefano Stabellini wrote: One of the main issues outstanding from when Anthony originally posted his patches is how we want to go about building this? I honestly do not know how well the current dracut-based approach to building the root image will work across various Linux distributions; perhaps it will be OK, since all of the libraries that dracut will siphon in will have to be in place to meet the build requirements for QEMU to begin with. However, I have zero knowledge about ARM-based Xen or where NetBSD is used for dom0, and how they might affect the decisionmaking. I also do not know what lessons have been learned from building other stubdoms, rumpkernel, or Mirage that might inform these decisions. In other words, what do you see as a sensible build scheme? The approach taken in the patches strikes me as too hacky for release quality, but maybe it is OK... It looks OK to me but I am not an expert in this kind of things. I'll let Ian Campbell and Ian Jackson (CC'ed) comment on it. I'm not at all keen on things like the use of dracut (or mkinitramfs or similar) in Xen's build since they are inherently/inevitably specific to the Linux distro they came from, so they often don't work (or aren't even available on) other Linux distros and are an even bigger problem for *BSD. I'd like to precise that the use of dracut here is only to copy a binary and it's dependencies (shared libraries), the binary used is called dracut-installer. I guest that the same can be achieved by the copy_exec() function from mkinitramfs (found in /usr/share/initramfs-tools/hook-functions on a debian system). The rest is done by a script, which choose which binary and file to include in the rootfs, where to put them and how to generate the image. -- Anthony PERARD ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Guidelines for new PV protocol submission
On Mon, 2015-02-09 at 12:01 +0100, Roger Pau Monné wrote: El 05/02/15 a les 11.42, Ian Campbell ha escrit: On Tue, 2015-01-20 at 13:47 +0100, Roger Pau Monné wrote: Hello, I should probably have done this earlier because I've been aware of this issue for a long time (since I've started dealing with the PV blk protocol). The current way to describe PV protocols in Xen is very inefficient IMHO. Using C structs as the description of a binary protocol seems very wrong, specially taking into account that different ABIs can generate different layouts for the same C struct. This is for example a problem in the PV blk protocol, since the binary layout of the structures change depending on the bitness. In order to avoid this, I would like to request that any new PV protocol that's added to Xen be described in binary terms, just like it's normally done with other protocols. As a reference see for example the following section from the TCP RFC: http://tools.ietf.org/html/rfc793#page-15 How about on the next doc day I'll convert netif.h and you do blkif.h? Sounds like a plan, although I think I got the short straw ;). I know :-P Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Guidelines for new PV protocol submission
Hi All! On Tue, Jan 20, 2015 at 2:47 PM, Roger Pau Monné roger@citrix.com wrote: Hello, I should probably have done this earlier because I've been aware of this issue for a long time (since I've started dealing with the PV blk protocol). The current way to describe PV protocols in Xen is very inefficient IMHO. Using C structs as the description of a binary protocol seems very wrong, specially taking into account that different ABIs can generate different layouts for the same C struct. This is for example a problem in the PV blk protocol, since the binary layout of the structures change depending on the bitness. In order to avoid this, I would like to request that any new PV protocol that's added to Xen be described in binary terms, just like it's normally done with other protocols. As a reference see for example the following section from the TCP RFC: http://tools.ietf.org/html/rfc793#page-15 Guys, what do you think about using an Interface Description Language such as Google Protocol Buffers or something like? With best regards, I think this is both more easy to understand and removes the bitness problem of using C structs. Then each user of this protocol could define it's own set of structures that would map to the binary layout, which should be almost trivial. There would be no problem with using __packed or similar gcc'isms as each implementation could choose the more convenient way to represent this layout internally. Roger. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel -- *Vitaly Chernooky | Senior Developer - Product Engineering and Development* GlobalLogic P *+380.44.4929695 ext.1136* M *+380.98.7920568* S cvv_2k www.globallogic.com http://www.globallogic.com/email_disclaimer.txt ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH OSSTEST 00/12] Libvirt save, restore and migration support
This series implements libvirt save, restore and migration test in OSSTest. The first 5 patches are used to 1. separate save / restore support from migration support; 2. introduce notion of local / remote migration support. With the above changes we lay the ground to test libvirt's save / restore functionalities in one machine and test libvirt's migration functionality in a pair test. At this point test-amd64-*-libvirt is able to test save / restore functionality. Later patches are adjustment to other test scripts to actual implement new libvirt test cases. After dumping standalone flights runvars, nothing is deleted and following new runvars are added. +xen-unstable test-amd64-amd64-libvirt-pair all_hostflags arch-amd64,arch-xen-amd64,suite-wheezy,purpose-test,equiv-1 +xen-unstable test-amd64-amd64-libvirt-pair archamd64 +xen-unstable test-amd64-amd64-libvirt-pair buildjobbuild-amd64 +xen-unstable test-amd64-amd64-libvirt-pair debian_arch amd64 +xen-unstable test-amd64-amd64-libvirt-pair debian_kernkind pvops +xen-unstable test-amd64-amd64-libvirt-pair kernbuildjobbuild-amd64-pvops +xen-unstable test-amd64-amd64-libvirt-pair kernkindpvops +xen-unstable test-amd64-amd64-libvirt-pair libvirtbuildjob build-amd64-libvirt +xen-unstable test-amd64-amd64-libvirt-pair toolstack libvirt +xen-unstable test-amd64-amd64-libvirt-pair xenbuildjob build-amd64 +xen-unstable test-amd64-amd64-libvirt-qemut-debianhvm-amd64 all_hostflags arch-amd64,arch-xen-amd64,suite-wheezy,purpose-test,hvm +xen-unstable test-amd64-amd64-libvirt-qemut-debianhvm-amd64 archamd64 +xen-unstable test-amd64-amd64-libvirt-qemut-debianhvm-amd64 biosrombios +xen-unstable test-amd64-amd64-libvirt-qemut-debianhvm-amd64 buildjobbuild-amd64 +xen-unstable test-amd64-amd64-libvirt-qemut-debianhvm-amd64 debianhvm_image debian-7.2.0-amd64-CD-1.iso +xen-unstable test-amd64-amd64-libvirt-qemut-debianhvm-amd64 device_model_versionqemu-xen-traditional +xen-unstable test-amd64-amd64-libvirt-qemut-debianhvm-amd64 enable_xsm false +xen-unstable test-amd64-amd64-libvirt-qemut-debianhvm-amd64 kernbuildjobbuild-amd64-pvops +xen-unstable test-amd64-amd64-libvirt-qemut-debianhvm-amd64 kernkindpvops +xen-unstable test-amd64-amd64-libvirt-qemut-debianhvm-amd64 libvirtbuildjob build-amd64-libvirt +xen-unstable test-amd64-amd64-libvirt-qemut-debianhvm-amd64 toolstack libvirt +xen-unstable test-amd64-amd64-libvirt-qemut-debianhvm-amd64 xenbuildjob build-amd64 +xen-unstable test-amd64-amd64-libvirt-qemut-debianhvm-amd64-xsm all_hostflags arch-amd64,arch-xen-amd64,suite-wheezy,purpose-test,hvm +xen-unstable test-amd64-amd64-libvirt-qemut-debianhvm-amd64-xsm archamd64 +xen-unstable test-amd64-amd64-libvirt-qemut-debianhvm-amd64-xsm biosrombios +xen-unstable test-amd64-amd64-libvirt-qemut-debianhvm-amd64-xsm buildjobbuild-amd64-xsm +xen-unstable test-amd64-amd64-libvirt-qemut-debianhvm-amd64-xsm debianhvm_image debian-7.2.0-amd64-CD-1.iso +xen-unstable test-amd64-amd64-libvirt-qemut-debianhvm-amd64-xsm device_model_versionqemu-xen-traditional +xen-unstable test-amd64-amd64-libvirt-qemut-debianhvm-amd64-xsm enable_xsm true +xen-unstable test-amd64-amd64-libvirt-qemut-debianhvm-amd64-xsm kernbuildjobbuild-amd64-pvops +xen-unstable test-amd64-amd64-libvirt-qemut-debianhvm-amd64-xsm kernkindpvops +xen-unstable test-amd64-amd64-libvirt-qemut-debianhvm-amd64-xsm libvirtbuildjob build-amd64-xsm-libvirt +xen-unstable test-amd64-amd64-libvirt-qemut-debianhvm-amd64-xsm toolstack libvirt +xen-unstable test-amd64-amd64-libvirt-qemut-debianhvm-amd64-xsm xenbuildjob build-amd64-xsm +xen-unstable test-amd64-i386-libvirt-pair
[Xen-devel] [PATCH OSSTEST 07/12] ts-xen-build-prep: install ebtables
Libvirt's test suite needs it.
Signed-off-by: Wei Liu wei.l...@citrix.com
Cc: Ian Campbell ian.campb...@citrix.com
Cc: Ian Jackson ian.jack...@eu.citrix.com
---
ts-xen-build-prep | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/ts-xen-build-prep b/ts-xen-build-prep
index 3684c0a..1bf40db 100755
--- a/ts-xen-build-prep
+++ b/ts-xen-build-prep
@@ -178,7 +178,7 @@ sub prep () {
autoconf automake libtool xsltproc
libxml2-utils libxml2-dev libnl-dev
libdevmapper-dev w3c-dtd-xhtml libxml-xpath-perl
- ccache nasm checkpolicy));
+ ccache nasm checkpolicy ebtables));
target_cmd_root($ho, chmod -R a+r /usr/share/git-core/templates);
# workaround for Debian #595728
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH OSSTEST 04/12] toolstack: distinguish local and remote migration support
Libvirt supports migrating a guest to remote host but not local host.
Distinguish the concept of local migration support and remote migration
support.
Toolstack's migrate_check now takes an extra argument to indicate which
mode we're interested in.
In sg-run-job we still check for local migration support because that's
the implicit target in test-guest-migr. Libvirt will still be blocked.
Signed-off-by: Wei Liu wei.l...@citrix.com
Cc: Ian Campbell ian.campb...@citrix.com
Cc: Ian Jackson ian.jack...@eu.citrix.com
---
Osstest/Toolstack/libvirt.pm | 19 ---
Osstest/Toolstack/xend.pm| 2 +-
Osstest/Toolstack/xl.pm | 4 ++--
sg-run-job | 2 +-
ts-migrate-support-check | 5 -
5 files changed, 24 insertions(+), 8 deletions(-)
diff --git a/Osstest/Toolstack/libvirt.pm b/Osstest/Toolstack/libvirt.pm
index acb801c..a804ed5 100644
--- a/Osstest/Toolstack/libvirt.pm
+++ b/Osstest/Toolstack/libvirt.pm
@@ -64,9 +64,22 @@ sub shutdown_wait ($$$) {
guest_await_destroy($gho,$timeout);
}
-sub migrate_check ($) {
-my ($self) = @_;
-die Migration check is not yet supported on libvirt.;
+sub migrate_check ($$) {
+my ($self, $mode) = @_;
+my $rc;
+
+if ($mode eq 'local') {
+# local migration is not supported
+$rc = 1;
+} else {
+ # $mode eq 'remote'
+ my $ho = $self-{Host};
+ my $caps = target_cmd_output_root($ho, virsh capabilities);
+ $rc = ($caps =~ m/migration_features/) ? 0 : 1
+}
+
+logm(rc=$rc);
+return $rc;
}
sub saverestore_check ($) {
diff --git a/Osstest/Toolstack/xend.pm b/Osstest/Toolstack/xend.pm
index ad98e65..bb39b75 100644
--- a/Osstest/Toolstack/xend.pm
+++ b/Osstest/Toolstack/xend.pm
@@ -35,7 +35,7 @@ sub new {
}
# xend always supported migration
-sub migrate_check ($) { return 0; }
+sub migrate_check ($$) { return 0; }
# xend always supported save / restore
sub saverestore_check ($) { return 0; }
diff --git a/Osstest/Toolstack/xl.pm b/Osstest/Toolstack/xl.pm
index b124273..7c82770 100644
--- a/Osstest/Toolstack/xl.pm
+++ b/Osstest/Toolstack/xl.pm
@@ -58,8 +58,8 @@ sub shutdown_wait ($$$) {
target_cmd_root($ho,$self-{_Command} shutdown -w $gn, $timeout);
}
-sub migrate_check ($) {
-my ($self) = @_;
+sub migrate_check ($$) {
+my ($self,$mode) = @_;
my $ho = $self-{Host};
my $help = target_cmd_output_root($ho, $self-{_Command}. help);
my $rc = ($help =~ m/^\s*migrate/m) ? 0 : 1;
diff --git a/sg-run-job b/sg-run-job
index cc2ab3b..b3747a7 100755
--- a/sg-run-job
+++ b/sg-run-job
@@ -289,7 +289,7 @@ proc run-job/test-pair {} {
}
proc test-guest-migr {g} {
-set to_reap [spawn-ts . = ts-migrate-support-check + host $g]
+set to_reap [spawn-ts . = ts-migrate-support-check + host $g local]
set can_migrate [reap-ts $to_reap]
if {!$can_migrate} return
diff --git a/ts-migrate-support-check b/ts-migrate-support-check
index cd41f68..d237710 100755
--- a/ts-migrate-support-check
+++ b/ts-migrate-support-check
@@ -23,5 +23,8 @@ use Osstest::TestSupport;
tsreadconfig();
our $ho = selecthost($ARGV[0]);
+# $ARGV[1] is guest name, $ARG[2] is migration mode.
+# Mode should be either local or remote
+our $mode = $ARGV[2];
-exit(toolstack($ho)-migrate_check());
+exit(toolstack($ho)-migrate_check($mode));
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH OSSTEST 09/12] ts-debian-hvm-install: stub out libvirt + ovmf / rombios
Libvirt's configuration converter doesn't know how to deal with BIOS
selection. The end result is it always use the default one (seabios).
Stub out ovmf and rombios to avoid false positive results.
This restriction will be removed once libvirt's converter knows how to
deal with BIOS selection.
Signed-off-by: Wei Liu wei.l...@citrix.com
Cc: Ian Campbell ian.campb...@citrix.com
Cc: Ian Jackson ian.jack...@eu.citrix.com
---
ts-debian-hvm-install | 7 +++
1 file changed, 7 insertions(+)
diff --git a/ts-debian-hvm-install b/ts-debian-hvm-install
index 449b96c..7fe9ca8 100755
--- a/ts-debian-hvm-install
+++ b/ts-debian-hvm-install
@@ -28,6 +28,13 @@ if (@ARGV $ARGV[0] =~ m/^--stage(\d+)$/) { $stage=$1;
shift @ARGV; }
defined($r{bios}) or die Need to define which bios to use;
+# Libvirt doesn't know anything about bios. It will always use the
+# default one (seabios). Stub out rombios and ovmf to avoid false
+# positive results.
+if ($r{bios} =~ m/ovmf|rombios/ $r{toolstack} eq 'libvirt') {
+die libvirt + $r{bios} is not supported yet.;
+}
+
our ($whhost,$gn) = @ARGV;
$whhost ||= 'host';
$gn ||= 'debianhvm';
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH OSSTEST 08/12] ts-libvirt-build: run libvirt test suite
We're interested in xlconfigtest. Since we're running test anyway run
the whole suite.
Signed-off-by: Wei Liu wei.l...@citrix.com
Cc: Ian Campbell ian.campb...@citrix.com
Cc: Ian Jackson ian.jack...@eu.citrix.com
---
ts-libvirt-build | 23 +--
1 file changed, 13 insertions(+), 10 deletions(-)
diff --git a/ts-libvirt-build b/ts-libvirt-build
index 7322d73..d9db31e 100755
--- a/ts-libvirt-build
+++ b/ts-libvirt-build
@@ -27,6 +27,7 @@ builddirsprops();
our %submodmap = qw(gnulib gnulib);
our $submodules;
+our $xenprefix;
sub libvirtd_init ();
@@ -39,15 +40,6 @@ sub checkout () {
}
sub config() {
-my $xenprefix;
-foreach (qw(/usr/local /usr)) {
- if (target_file_exists($ho, $xendist$_/lib/libxenctrl.so)) {
- $xenprefix=$xendist$_;
- last;
- }
-}
-die no xen prefix unless $xenprefix;
-
# Uses --no-git because otherwise autogen.sh will undo
# submodulefixup's attempts to honour
# revision_libvirt_gnulib. This in turn requires that we specify
@@ -69,7 +61,10 @@ END
sub build() {
target_cmd_build($ho, 3600, $builddir, END);
cd libvirt
-(make $makeflags 21 touch ../build-ok-stamp) |tee ../log
+(make $makeflags 21 \\
+ LD_LIBRARY_PATH=$xenprefix/lib/ \\
+ make check VIR_TEST_EXPENSIVE=1 21 \\
+ touch ../build-ok-stamp) |tee ../log
test -f ../build-ok-stamp #/
echo ok.
END
@@ -90,6 +85,14 @@ END
END
}
+foreach (qw(/usr/local /usr)) {
+if (target_file_exists($ho, $xendist$_/lib/libxenctrl.so)) {
+ $xenprefix=$xendist$_;
+ last;
+}
+}
+die no xen prefix unless $xenprefix;
+
checkout();
config();
build();
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH OSSTEST 06/12] toolstack/libvirt: guest migrate, save and restore support
Signed-off-by: Wei Liu wei.l...@citrix.com
Cc: Ian Campbell ian.campb...@citrix.com
Cc: Ian Jackson ian.jack...@eu.citrix.com
---
Osstest/Toolstack/libvirt.pm | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/Osstest/Toolstack/libvirt.pm b/Osstest/Toolstack/libvirt.pm
index a804ed5..d7d5154 100644
--- a/Osstest/Toolstack/libvirt.pm
+++ b/Osstest/Toolstack/libvirt.pm
@@ -93,17 +93,22 @@ sub saverestore_check ($) {
sub migrate ($) {
my ($self,$gho,$dst,$timeout) = @_;
-die Migration is not yet supported on libvirt.;
+my $ho = $self-{Host};
+my $gn = $gho-{Name};
+target_cmd_root($ho, virsh migrate $gn $dst, $timeout);
}
sub save () {
my ($self,$gho,$f,$timeout) = @_;
-die Save is not yet supported on libvirt.;
+my $ho = $self-{Host};
+my $gn = $gho-{Name};
+target_cmd_root($ho, virsh save $gn $f, $timeout);
}
sub restore () {
my ($self,$gho,$f,$timeout) = @_;
-die Restore is not yet supported on libvirt.;
+my $ho = $self-{Host};
+target_cmd_root($ho, virsh restore $f, $timeout);
}
1;
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH OSSTEST 05/12] sg-run-job: remove save/restore dependency on local migration support
Since we've introduced different checks for save / restore and local
migration, it's possible to run save / restore tests without running
local migration tests.
Signed-off-by: Wei Liu wei.l...@citrix.com
Cc: Ian Campbell ian.campb...@citrix.com
Cc: Ian Jackson ian.jack...@eu.citrix.com
---
sg-run-job | 18 +-
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a/sg-run-job b/sg-run-job
index b3747a7..79ddd2a 100755
--- a/sg-run-job
+++ b/sg-run-job
@@ -291,13 +291,21 @@ proc run-job/test-pair {} {
proc test-guest-migr {g} {
set to_reap [spawn-ts . = ts-migrate-support-check + host $g local]
set can_migrate [reap-ts $to_reap]
-if {!$can_migrate} return
+set to_reap [spawn-ts . = ts-saverestore-support-check + host]
+set can_saverestore [reap-ts $to_reap]
-foreach iteration {{} .2} {
-run-ts . =$iteration ts-guest-saverestore + host $g
-run-ts . =$iteration ts-guest-localmigrate + host $g
+if {$can_saverestore} {
+foreach iteration {{} .2} {
+run-ts . =$iteration ts-guest-saverestore + host $g
+}
+}
+
+if {$can_migrate} {
+foreach iteration {{} .2} {
+run-ts . =$iteration ts-guest-localmigrate + host $g
+}
+run-ts . = ts-guest-localmigrate x10 + host $g
}
-run-ts . = ts-guest-localmigrate x10 + host $g
}
proc test-guest {g} {
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH OSSTEST 03/12] osstest migrate support check catch - variables
From: Ian Jackson ian.jack...@eu.citrix.com
Signed-off-by: Ian Jackson ian.jack...@eu.citrix.com
---
sg-run-job | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/sg-run-job b/sg-run-job
index 2cf810a..cc2ab3b 100755
--- a/sg-run-job
+++ b/sg-run-job
@@ -289,7 +289,9 @@ proc run-job/test-pair {} {
}
proc test-guest-migr {g} {
-if {[catch { run-ts . = ts-migrate-support-check + host $g }]} return
+set to_reap [spawn-ts . = ts-migrate-support-check + host $g]
+set can_migrate [reap-ts $to_reap]
+if {!$can_migrate} return
foreach iteration {{} .2} {
run-ts . =$iteration ts-guest-saverestore + host $g
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH OSSTEST 02/12] Introduce ts-saverestore-support-check
Signed-off-by: Wei Liu wei.l...@citrix.com Cc: Ian Campbell ian.campb...@citrix.com Cc: Ian Jackson ian.jack...@eu.citrix.com --- ts-saverestore-support-check | 27 +++ 1 file changed, 27 insertions(+) create mode 100755 ts-saverestore-support-check diff --git a/ts-saverestore-support-check b/ts-saverestore-support-check new file mode 100755 index 000..71514fc --- /dev/null +++ b/ts-saverestore-support-check @@ -0,0 +1,27 @@ +#!/usr/bin/perl -w +# This is part of osstest, an automated testing framework for Xen. +# Copyright (C) 2015 Citrix Inc. +# +# This program is free software: you can redistribute it and/or modify +# it under the terms of the GNU Affero General Public License as published by +# the Free Software Foundation, either version 3 of the License, or +# (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU Affero General Public License for more details. +# +# You should have received a copy of the GNU Affero General Public License +# along with this program. If not, see http://www.gnu.org/licenses/. + +use strict qw(vars); +use DBI; +use Osstest; +use Osstest::TestSupport; + +tsreadconfig(); + +our $ho = selecthost($ARGV[0]); + +exit(toolstack($ho)-saverestore_check()); -- 1.9.1 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH OSSTEST 11/12] make-flight, mfi-common: rename onetoolstack to pairtoolstack
The name onetoolstack in confusing. Currently it's in fact referring
to the toolstack used to test pair migration, so rename it to
pairtoolstack.
No functional changes introduced.
Signed-off-by: Wei Liu wei.l...@citrix.com
Cc: Ian Campbell ian.campb...@citrix.com
Cc: Ian Jackson ian.jack...@eu.citrix.com
---
make-flight | 2 +-
mfi-common | 8
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/make-flight b/make-flight
index dabcacd..23d51ea 100755
--- a/make-flight
+++ b/make-flight
@@ -420,7 +420,7 @@ test_matrix_do_one () {
# Test live migration
job_create_test test-$xenarch$kern-$dom0arch-pair test-pair \
-$onetoolstack $xenarch $dom0arch \
+$pairtoolstack $xenarch $dom0arch \
!host !host_hostflags \
$debian_runvars \
all_hostflags=$most_hostflags,equiv-1
diff --git a/mfi-common b/mfi-common
index a0603a2..8e53fbb 100644
--- a/mfi-common
+++ b/mfi-common
@@ -309,10 +309,10 @@ job_create_test () {
test_matrix_iterate () {
case $xenbranch in
- xen-3.*-testing) onetoolstack=xend ;;
- xen-4.0-testing) onetoolstack=xend ;;
- xen-4.1-testing) onetoolstack=xend ;;
- *)onetoolstack=xl ;;
+ xen-3.*-testing) pairtoolstack=xend ;;
+ xen-4.0-testing) pairtoolstack=xend ;;
+ xen-4.1-testing) pairtoolstack=xend ;;
+ *)pairtoolstack=xl ;;
esac
for xenarch in ${TEST_ARCHES- i386 amd64 armhf } ; do
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH OSSTEST 10/12] make-flight: debian hvm tests with libvirt
Signed-off-by: Wei Liu wei.l...@citrix.com
Cc: Ian Campbell ian.campb...@citrix.com
Cc: Ian Jackson ian.jack...@eu.citrix.com
---
make-flight | 21 ++---
1 file changed, 14 insertions(+), 7 deletions(-)
diff --git a/make-flight b/make-flight
index 8ac3a87..dabcacd 100755
--- a/make-flight
+++ b/make-flight
@@ -92,7 +92,9 @@ job_create_test_filter_callback () {
*)
case $job in
*-qemuu-*)
- if [ x$toolstack != xxl ]; then return 1; fi
+ if [ x$toolstack != xxl -a x$toolstack != xlibvirt ];then
+ return 1;
+ fi
;;
esac
;;
@@ -208,9 +210,10 @@ do_hvm_debian_test_one () {
testname=$1
bios=$2
xsm=$3
+ toolstack=$4
- job_create_test test-$xenarch$kern-$dom0arch-xl$qemuu_suffix-$testname-amd64\
-test-debianhvm xl $xenarch $dom0arch $qemuu_runvar \
+ job_create_test
test-$xenarch$kern-$dom0arch-$toolstack$qemuu_suffix-$testname-amd64\
+test-debianhvm $toolstack $xenarch $dom0arch $qemuu_runvar \
enable_xsm=$xsm \
debianhvm_image=debian-7.2.0-amd64-CD-1.iso \
bios=$bios \
@@ -226,16 +229,20 @@ do_hvm_debian_tests() {
# QEMU upstream supports ovmf and seabios
if [ x$qemuu_suffix == x-qemuu ]; then
-do_hvm_debian_test_one ovmf ovmf false
-for xsm in $xsms ; do
- do_hvm_debian_test_one debianhvm seabios $xsm
+for toolstack in xl libvirt; do
+ do_hvm_debian_test_one ovmf ovmf false $toolstack
+ for xsm in $xsms ; do
+do_hvm_debian_test_one debianhvm seabios $xsm $toolstack
+ done
done
fi
# QEMU traditional supports rombios
if [ x$qemuu_suffix == x-qemut ]; then
for xsm in $xsms ; do
- do_hvm_debian_test_one debianhvm rombios $xsm
+ for toolstack in xl libvirt; do
+do_hvm_debian_test_one debianhvm rombios $xsm $toolstack
+ done
done
fi
}
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH] x86/nmi: Fix shootdown of pcpus running in VMX non-root mode
In the case of a crash, nmi_shootdown_cpus() patches nmi_crash() into the IDT
of each processor, such that the next NMI it receives will force it into the
crash path.
c/s 7dd3b06ff vmx: fix handling of NMI VMEXIT fixed one issue but
inadvertently introduced another. The original use of self_nmi() would follow
vector #2, but a direct call to do_nmi() does not.
Introduce a function pointer which should be used in preference to direct
do_nmi() calls, which is updated on the crash path to point at do_nmi_crash()
Signed-off-by: Andrew Cooper andrew.coop...@citrix.com
CC: Jan Beulich jbeul...@suse.com
CC: Tim Deegan t...@xen.org
---
This patch very certainly functions correctly (it is in active use now in a
customer escalation), but I was wondering how paranoid we should be about
interleaved reads/writes and whether an atomic write would be better?
Performance is not a issue at all but in a crash senario we don't want to be
taking any chances with correctness.
---
xen/arch/x86/crash.c|4 +++-
xen/arch/x86/hvm/vmx/vmx.c |2 +-
xen/arch/x86/traps.c|2 ++
xen/include/asm-x86/processor.h |3 ++-
4 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/xen/arch/x86/crash.c b/xen/arch/x86/crash.c
index c0b83df..0822a68 100644
--- a/xen/arch/x86/crash.c
+++ b/xen/arch/x86/crash.c
@@ -36,7 +36,7 @@ static unsigned int crashing_cpu;
static DEFINE_PER_CPU_READ_MOSTLY(bool_t, crash_save_done);
/* This becomes the NMI handler for non-crashing CPUs, when Xen is crashing. */
-void do_nmi_crash(struct cpu_user_regs *regs)
+void do_nmi_crash(const struct cpu_user_regs *regs)
{
int cpu = smp_processor_id();
@@ -160,6 +160,8 @@ static void nmi_shootdown_cpus(void)
}
}
+nmi_handler = do_nmi_crash;
+
/* Ensure the new callback function is set before sending out the NMI. */
wmb();
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 88b7821..67bdcb4 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -2701,7 +2701,7 @@ void vmx_vmexit_handler(struct cpu_user_regs *regs)
((intr_info INTR_INFO_INTR_TYPE_MASK) ==
(X86_EVENTTYPE_NMI 8)) )
{
-do_nmi(regs);
+nmi_handler(regs);
enable_nmis();
}
break;
diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index f5516dc..890e22a 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -105,6 +105,8 @@ idt_entry_t *idt_tables[NR_CPUS] __read_mostly;
void (*ioemul_handle_quirk)(
u8 opcode, char *io_emul_stub, struct cpu_user_regs *regs);
+void (*nmi_handler)(const struct cpu_user_regs *regs) __read_mostly = do_nmi;
+
static int debug_stack_lines = 20;
integer_param(debug_stack_lines, debug_stack_lines);
diff --git a/xen/include/asm-x86/processor.h b/xen/include/asm-x86/processor.h
index 20eade6..70c9abc 100644
--- a/xen/include/asm-x86/processor.h
+++ b/xen/include/asm-x86/processor.h
@@ -522,9 +522,10 @@ DECLARE_TRAP_HANDLER(alignment_check);
#undef DECLARE_TRAP_HANDLER_CONST
#undef DECLARE_TRAP_HANDLER
+extern void (*nmi_handler)(const struct cpu_user_regs *regs);
void trap_nop(void);
void enable_nmis(void);
-void noreturn do_nmi_crash(struct cpu_user_regs *regs);
+void noreturn do_nmi_crash(const struct cpu_user_regs *regs);
void do_reserved_trap(struct cpu_user_regs *regs);
void syscall_enter(void);
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH OSSTEST 12/12] make-flight, mfi-common: create live migration test for libvirt
Signed-off-by: Wei Liu wei.l...@citrix.com
Cc: Ian Campbell ian.campb...@citrix.com
Cc: Ian Jackson ian.jack...@eu.citrix.com
---
make-flight | 13 +++--
mfi-common | 6 +-
2 files changed, 16 insertions(+), 3 deletions(-)
diff --git a/make-flight b/make-flight
index 23d51ea..80c9c39 100755
--- a/make-flight
+++ b/make-flight
@@ -419,11 +419,20 @@ test_matrix_do_one () {
done # qemuu_suffix
# Test live migration
- job_create_test test-$xenarch$kern-$dom0arch-pair test-pair \
-$pairtoolstack $xenarch $dom0arch \
+ for toolstack in $pairtoolstack; do
+# Don't change test case name for old test cases with xl and xend
+if [ x$toolstack = xxl -o x$toolstack = xxend ]; then
+ toolstack_suffix=
+else
+ toolstack_suffix=-$toolstack
+fi
+job_create_test test-$xenarch$kern-$dom0arch$toolstack_suffix-pair \
+test-pair \
+$toolstack $xenarch $dom0arch \
!host !host_hostflags \
$debian_runvars \
all_hostflags=$most_hostflags,equiv-1
+ done
if [ x$test_pvh = xy -a $xenarch = amd64 -a $dom0arch = amd64 ]; then
diff --git a/mfi-common b/mfi-common
index 8e53fbb..8ad6450 100644
--- a/mfi-common
+++ b/mfi-common
@@ -312,7 +312,11 @@ test_matrix_iterate () {
xen-3.*-testing) pairtoolstack=xend ;;
xen-4.0-testing) pairtoolstack=xend ;;
xen-4.1-testing) pairtoolstack=xend ;;
- *)pairtoolstack=xl ;;
+ xen-4.2-testing) pairtoolstack=xl ;;
+ xen-4.3-testing) pairtoolstack=xl ;;
+ xen-4.4-testing) pairtoolstack=xl ;;
+ xen-4.5-testing) pairtoolstack=xl ;;
+ *)pairtoolstack=xl libvirt ;;
esac
for xenarch in ${TEST_ARCHES- i386 amd64 armhf } ; do
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
