[Xen-devel] [xen-4.5-testing test] 34638: regressions - FAIL
flight 34638 xen-4.5-testing real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/34638/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-libvirt 5 xen-boot fail REGR. vs. 34200 test-amd64-amd64-pair14 leak-check/basis/src_host(14) fail REGR. vs. 34200 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 10 migrate-support-checkfail never pass test-armhf-armhf-xl-sedf-pin 10 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 10 migrate-support-checkfail never pass test-armhf-armhf-xl-midway 10 migrate-support-checkfail never pass test-armhf-armhf-xl 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-amd64-i386-libvirt 10 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 5 xen-boot fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-winxpsp3 14 guest-stop fail never pass test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stopfail never pass test-amd64-i386-xl-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop fail never pass test-amd64-amd64-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-qemut-win7-amd64 14 guest-stop fail never pass test-amd64-i386-pair17 guest-migrate/src_host/dst_host fail never pass test-amd64-i386-xl-qemut-winxpsp3 14 guest-stopfail never pass test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop fail never pass test-amd64-amd64-xl-winxpsp3 14 guest-stop fail never pass version targeted for testing: xen 2417e243bb510dafdbd589a5aeedb29095e62c10 baseline version: xen d8e78d691d9b4bcc945d8f0b0ed2b48713931c4d People who touched revisions under test: Ian Campbell ian.campb...@citrix.com Ian Jackson ian.jack...@eu.citrix.com Jim Fehlig jfeh...@suse.com Julien Grall julien.gr...@linaro.org Wei Liu wei.l...@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 build-amd64-rumpuserxen pass build-i386-rumpuserxen 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 test-amd64-amd64-xl-qemut-debianhvm-amd64pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-rumpuserxen-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail
Re: [Xen-devel] [PATCH v4 14/29] MdePkg/BaseSynchronizationLib: implement 16-bit compare-exchange
On 17 February 2015 at 18:40, Jordan Justen jordan.l.jus...@intel.com wrote: Ard, For the subject, I think MdePkg/BaseSynchronizationLib: Add InterlockedCompareExchange16 would be better. OK Acked-by: Jordan Justen jordan.l.jus...@intel.com Thanks Thanks for working to move this to a common location. No problem Mike, I think Anthony tested the IA32 and X64 implementations with Xen. For IPF, I don't think it has been tested. As mentioned in the other thread, Anthony seems to be incommunicado, and some other of the Xen guys have replied that Xen on OVMF/x86 is broken for other reasons so they cannot positively confirm that everything still works, even though the x86 changes other than the PCI/xenbus split are primarily refactoring of existing code. As far as IPF is concerned: I don't think Xen or Ovmf can be built for IPF anyway, but I think a build test and visual inspection of the .S file should be sufficient here? Thanks, Ard. On 2015-02-12 03:19:06, Ard Biesheuvel wrote: This implements the function InterlockedCompareExchange16 () for all architectures, using architecture and toolchain specific intrinsics or primitive assembler instructions. Contributed-under: TianoCore Contribution Agreement 1.0 Reviewed-by: Olivier Martin olivier.mar...@arm.com Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org --- MdePkg/Include/Library/SynchronizationLib.h | 26 ++ MdePkg/Library/BaseSynchronizationLib/AArch64/Synchronization.S | 44 MdePkg/Library/BaseSynchronizationLib/Arm/Synchronization.S | 44 MdePkg/Library/BaseSynchronizationLib/Arm/Synchronization.asm | 44 MdePkg/Library/BaseSynchronizationLib/BaseSynchronizationLib.inf | 5 + MdePkg/Library/BaseSynchronizationLib/BaseSynchronizationLibInternals.h | 26 ++ MdePkg/Library/BaseSynchronizationLib/Ebc/Synchronization.c | 31 +++ MdePkg/Library/BaseSynchronizationLib/Ia32/GccInline.c | 42 ++ MdePkg/Library/BaseSynchronizationLib/Ia32/InterlockedCompareExchange16.asm | 46 ++ MdePkg/Library/BaseSynchronizationLib/Ia32/InterlockedCompareExchange16.c | 51 +++ MdePkg/Library/BaseSynchronizationLib/Ipf/InterlockedCompareExchange16.s | 30 ++ MdePkg/Library/BaseSynchronizationLib/Synchronization.c | 31 +++ MdePkg/Library/BaseSynchronizationLib/SynchronizationGcc.c | 31 +++ MdePkg/Library/BaseSynchronizationLib/SynchronizationMsc.c | 31 +++ MdePkg/Library/BaseSynchronizationLib/X64/GccInline.c | 44 MdePkg/Library/BaseSynchronizationLib/X64/InterlockedCompareExchange16.asm | 42 ++ MdePkg/Library/BaseSynchronizationLib/X64/InterlockedCompareExchange16.c | 54 ++ 17 files changed, 622 insertions(+) diff --git a/MdePkg/Include/Library/SynchronizationLib.h b/MdePkg/Include/Library/SynchronizationLib.h index f97569739914..7b97683ca0af 100644 --- a/MdePkg/Include/Library/SynchronizationLib.h +++ b/MdePkg/Include/Library/SynchronizationLib.h @@ -184,6 +184,32 @@ InterlockedDecrement ( /** + Performs an atomic compare exchange operation on a 16-bit unsigned integer. + + Performs an atomic compare exchange operation on the 16-bit unsigned integer + specified by Value. If Value is equal to CompareValue, then Value is set to + ExchangeValue and CompareValue is returned. If Value is not equal to CompareValue, + then Value is returned. The compare exchange operation must be performed using + MP safe mechanisms. + + If Value is NULL, then ASSERT(). + + @param Value A pointer to the 16-bit value for the compare exchange +operation. + @param CompareValue 16-bit value used in compare operation. + @param ExchangeValue 16-bit value used in exchange operation. + + @return The original *Value before exchange. +**/ +UINT16 +EFIAPI +InterlockedCompareExchange16 ( + IN OUT UINT16*Value, + IN UINT16CompareValue, + IN UINT16ExchangeValue + ); + +/** Performs an atomic compare exchange operation on a 32-bit unsigned integer. Performs an atomic compare exchange operation on the 32-bit unsigned integer diff --git
[Xen-devel] [PATCH 26/45] gntdev.h: include stdint.h in userspace
Fixes compilation error:
xen/gntdev.h:38:2: error: unknown type name ‘uint32_t’
Signed-off-by: Mikko Rapeli mikko.rap...@iki.fi
---
include/uapi/xen/gntdev.h | 6 ++
1 file changed, 6 insertions(+)
diff --git a/include/uapi/xen/gntdev.h b/include/uapi/xen/gntdev.h
index 5304bd3..f724f75 100644
--- a/include/uapi/xen/gntdev.h
+++ b/include/uapi/xen/gntdev.h
@@ -33,6 +33,12 @@
#ifndef __LINUX_PUBLIC_GNTDEV_H__
#define __LINUX_PUBLIC_GNTDEV_H__
+#ifdef __KERNEL__
+#include linux/types.h
+#else
+#include stdint.h
+#endif
+
struct ioctl_gntdev_grant_ref {
/* The domain ID of the grant to be mapped. */
uint32_t domid;
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 25/45] gntalloc.h: include stdint.h in userspace
Fixes compilation error: xen/gntalloc.h:22:2: error: unknown type name ‘uint16_t’ Signed-off-by: Mikko Rapeli mikko.rap...@iki.fi --- include/uapi/xen/gntalloc.h | 6 ++ 1 file changed, 6 insertions(+) diff --git a/include/uapi/xen/gntalloc.h b/include/uapi/xen/gntalloc.h index 76bd580..184df7e 100644 --- a/include/uapi/xen/gntalloc.h +++ b/include/uapi/xen/gntalloc.h @@ -11,6 +11,12 @@ #ifndef __LINUX_PUBLIC_GNTALLOC_H__ #define __LINUX_PUBLIC_GNTALLOC_H__ +#ifdef __KERNEL__ +#include linux/types.h +#else +#include stdint.h +#endif + /* * Allocates a new page and creates a new grant reference. */ -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 02/13] xen: anchor linear p2m list in shared info structure
On 02/18/2015 11:32 AM, David Vrabel wrote:
On 18/02/15 06:51, Juergen Gross wrote:
The linear p2m list should be anchored in the shared info structure
I'm not really sure what you mean by anchored.
Bad wording? What about:
The virtual address of the linear p2m list should be stored in the
shared info structure.
read by the Xen tools to be able to support 64 bit pv-domains larger
than 512 MB. Additionally the linear p2m list interface includes a
generation count which is changed prior to and after each mapping
change of the p2m list. Reading the generation count the Xen tools can
detect changes of the mappings and re-read the p2m list eventually.
[...]
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -256,6 +256,10 @@ void xen_setup_mfn_list_list(void)
HYPERVISOR_shared_info-arch.pfn_to_mfn_frame_list_list =
virt_to_mfn(p2m_top_mfn);
HYPERVISOR_shared_info-arch.max_pfn = xen_max_p2m_pfn;
+ HYPERVISOR_shared_info-arch.p2m_generation = 0;
+ HYPERVISOR_shared_info-arch.p2m_vaddr = (unsigned long)xen_p2m_addr;
+ HYPERVISOR_shared_info-arch.p2m_cr3 =
+ xen_pfn_to_cr3(virt_to_mfn(swapper_pg_dir));
}
/* Set up p2m_top to point to the domain-builder provided p2m pages */
@@ -469,8 +473,10 @@ static pte_t *alloc_p2m_pmd(unsigned long addr, pte_t
*pte_pg)
ptechk = lookup_address(vaddr, level);
if (ptechk == pte_pg) {
+ HYPERVISOR_shared_info-arch.p2m_generation++;
set_pmd(pmdp,
__pmd(__pa(pte_newpg[i]) | _KERNPG_TABLE));
+ HYPERVISOR_shared_info-arch.p2m_generation++;
Do these increments of p2m_generation need to be atomic?
Hmm, they are done under lock. I don't think the compiler is allowed to
reorder the writes to p2m_generation across set_pmd().
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH OSSTEST] Debian: Add fdt chosen to boot script
This causes u-boot to fill in the various fields in the chosen node
(specifically the bootargs) which would otherwise not be done until
the bootz command. Doing it manually means the following fdt print
/chosen will print what is actually going to be used.
This change means that instead of whatever /chosen/bootargs is
embedded in the firmware FDT we end up printing what we will actually
use.
Signed-off-by: Ian Campbell ian.campb...@citrix.com
---
Osstest/Debian.pm | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index 7633b51..f6874af 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -237,6 +237,8 @@ fdt set /chosen/module\@1 compatible xen,linux-initrd
xen,multiboot-module
fdt set /chosen/module\@1 reg \\\${ramdisk_addr_r}
${size_hex_prefix}\\\${filesize}
echo Loaded $initrd to \\\${ramdisk_addr_r} (\\\${filesize})
+fdt chosen
+
fdt print /chosen
echo Booting \\\${xen_addr_r} - \\\${fdt_addr}
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 2/2] x86/tboot: simplify DMAR table copying
There's no need for more than one variable, no need for casts, and no
point in using the type-safe xmalloc_array() here.
Signed-off-by: Jan Beulich jbeul...@suse.com
--- a/xen/arch/x86/tboot.c
+++ b/xen/arch/x86/tboot.c
@@ -435,13 +435,12 @@ int __init tboot_protect_mem_regions(voi
int __init tboot_parse_dmar_table(acpi_table_handler dmar_handler)
{
-struct acpi_table_header *dmar_table;
int rc;
uint64_t size;
uint32_t dmar_table_length;
unsigned long pa;
sinit_mle_data_t sinit_mle_data;
-unsigned char *dmar_table_raw;
+void *dmar_table;
if ( !tboot_in_measured_env() )
return acpi_table_parse(ACPI_SIG_DMAR, dmar_handler);
@@ -474,13 +473,12 @@ int __init tboot_parse_dmar_table(acpi_t
tboot_copy_memory((unsigned char *)dmar_table_length,
sizeof(dmar_table_length),
pa + sizeof(char) * ACPI_NAME_SIZE);
-dmar_table_raw = xmalloc_array(unsigned char, dmar_table_length);
-tboot_copy_memory(dmar_table_raw, dmar_table_length, pa);
-dmar_table = (struct acpi_table_header *)dmar_table_raw;
+dmar_table = xmalloc_bytes(dmar_table_length);
+tboot_copy_memory(dmar_table, dmar_table_length, pa);
__set_fixmap(FIX_TBOOT_MAP_ADDRESS, 0, 0);
rc = dmar_handler(dmar_table);
-xfree(dmar_table_raw);
+xfree(dmar_table);
/* acpi_parse_dmar() zaps APCI DMAR signature in TXT heap table */
/* but dom0 will read real table, so must zap it there too */
x86/tboot: simplify DMAR table copying
There's no need for more than one variable, no need for casts, and no
point in using the type-safe xmalloc_array() here.
Signed-off-by: Jan Beulich jbeul...@suse.com
--- a/xen/arch/x86/tboot.c
+++ b/xen/arch/x86/tboot.c
@@ -435,13 +435,12 @@ int __init tboot_protect_mem_regions(voi
int __init tboot_parse_dmar_table(acpi_table_handler dmar_handler)
{
-struct acpi_table_header *dmar_table;
int rc;
uint64_t size;
uint32_t dmar_table_length;
unsigned long pa;
sinit_mle_data_t sinit_mle_data;
-unsigned char *dmar_table_raw;
+void *dmar_table;
if ( !tboot_in_measured_env() )
return acpi_table_parse(ACPI_SIG_DMAR, dmar_handler);
@@ -474,13 +473,12 @@ int __init tboot_parse_dmar_table(acpi_t
tboot_copy_memory((unsigned char *)dmar_table_length,
sizeof(dmar_table_length),
pa + sizeof(char) * ACPI_NAME_SIZE);
-dmar_table_raw = xmalloc_array(unsigned char, dmar_table_length);
-tboot_copy_memory(dmar_table_raw, dmar_table_length, pa);
-dmar_table = (struct acpi_table_header *)dmar_table_raw;
+dmar_table = xmalloc_bytes(dmar_table_length);
+tboot_copy_memory(dmar_table, dmar_table_length, pa);
__set_fixmap(FIX_TBOOT_MAP_ADDRESS, 0, 0);
rc = dmar_handler(dmar_table);
-xfree(dmar_table_raw);
+xfree(dmar_table);
/* acpi_parse_dmar() zaps APCI DMAR signature in TXT heap table */
/* but dom0 will read real table, so must zap it there too */
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 13/13] xen: allow more than 512 GB of RAM for 64 bit pv-domains
On 02/18/2015 10:21 AM, Paul Bolle wrote:
On Wed, 2015-02-18 at 07:52 +0100, Juergen Gross wrote:
64 bit pv-domains under Xen are limited to 512 GB of RAM today. The
main reason has been the 3 level p2m tree, which was replaced by the
virtual mapped linear p2m list. Parallel to the p2m list which is
being used by the kernel itself there is a 3 level mfn tree for usage
by the Xen tools and eventually for crash dump analysis. For this tree
the linear p2m list can serve as a replacement, too. As the kernel
can't know whether the tools are capable of dealing with the p2m list
instead of the mfn tree, the limit of 512 GB can't be dropped in all
cases.
This patch replaces the hard limit by a kernel parameter which tells
the kernel to obey the 512 GB limit or not. The default is selected by
a configuration parameter which specifies whether the 512 GB limit
should be active per default for dom0 (only crash dump analysis is
affected) and/or for domUs (additionally domain save/restore/migration
are affected).
Memory above the domain limit is returned to the hypervisor instead of
being identity mapped, which was wrong anyways.
The kernel configuration parameter to specify the maximum size of a
domain can be deleted, as it is not relevant any more.
Signed-off-by: Juergen Gross jgr...@suse.com
---
Documentation/kernel-parameters.txt | 7
arch/x86/include/asm/xen/page.h | 4 ---
arch/x86/xen/Kconfig| 31 +++-
arch/x86/xen/p2m.c | 10 +++---
arch/x86/xen/setup.c| 72 ++---
5 files changed, 93 insertions(+), 31 deletions(-)
[...]
--- a/arch/x86/xen/Kconfig
+++ b/arch/x86/xen/Kconfig
@@ -23,14 +23,29 @@ config XEN_PVHVM
def_bool y
depends on XEN PCI X86_LOCAL_APIC
-config XEN_MAX_DOMAIN_MEMORY
- int
- default 500 if X86_64
- default 64 if X86_32
- depends on XEN
- help
- This only affects the sizing of some bss arrays, the unused
- portions of which are freed.
+if X86_64
Not
XEN
?
The complete directory is made only if CONFIG_XEN is set.
+choice
+ prompt Support pv-domains larger than 512GB
+ default XEN_512GB_NONE
+ help
+ Support paravirtualized domains with more than 512GB of RAM.
+
+ The Xen tools and crash dump analysis tools might not support
+ pv-domains with more than 512 GB of RAM. This option controls the
+ default setting of the kernel to use only up to 512 GB or more.
+ It is always possible to change the default via specifying the
+ boot parameter xen_512gb_limit.
+
+ config XEN_512GB_NONE
+ bool neither dom0 nor domUs can be larger than 512GB
+ config XEN_512GB_DOM0
+ bool dom0 can be larger than 512GB, domUs not
+ config XEN_512GB_DOMU
+ bool domUs can be larger than 512GB, dom0 not
+ config XEN_512GB_ALL
+ bool dom0 and domUs can be larger than 512GB
+endchoice
So there are actually two independent limits, configured through a
choice with four entries. Would using just two separate Kconfig symbols
(XEN_512GB_DOM0 and XEN_512GB_DOMU) without a choice wrapper also work?
Yes.
Because ...
+endif
config XEN_SAVE_RESTORE
bool
[...]
diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index 84a6473..16d94de 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -32,6 +32,8 @@
#include p2m.h
#include mmu.h
+#define GB(x) ((uint64_t)(x) * 1024 * 1024 * 1024)
+
/* Amount of extra memory space we add to the e820 ranges */
struct xen_memory_region xen_extra_mem[XEN_EXTRA_MEM_MAX_REGIONS] __initdata;
@@ -85,6 +87,27 @@ static struct {
*/
#define EXTRA_MEM_RATIO (10)
+static bool xen_dom0_512gb_limit __initdata =
+ IS_ENABLED(CONFIG_XEN_512GB_NONE) || IS_ENABLED(CONFIG_XEN_512GB_DOMU);
... then this could be something like:
static bool xen_dom0_512gb_limit __initdata =
!IS_ENABLED(CONFIG_XEN_512GB_DOM0);
+static bool xen_domu_512gb_limit __initdata =
+ IS_ENABLED(CONFIG_XEN_512GB_NONE) || IS_ENABLED(CONFIG_XEN_512GB_DOM0);
+
and this likewise:
static bool xen_domu_512gb_limit __initdata =
!IS_ENABLED(CONFIG_XEN_512GB_DOMU);
Correct?
Yes.
That's a matter of taste, I think.
+static int __init xen_parse_512gb(char *arg)
+{
+ bool val = false;
+
+ if (!arg)
+ val = true;
+ else if (strtobool(arg, val))
+ return 1;
+
+ xen_dom0_512gb_limit = val;
+ xen_domu_512gb_limit = val;
+
+ return 0;
+}
+early_param(xen_512gb_limit, xen_parse_512gb);
+
static void __init xen_add_extra_mem(phys_addr_t start, phys_addr_t size)
{
int i;
So one can configure these two limits separately, but the kernel
parameter is used for both. Any particular reason?
Yes. A kernel is running only either as Dom0 or as domU at a given
[Xen-devel] [xen-4.4-testing test] 34688: regressions - FAIL
flight 34688 xen-4.4-testing real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/34688/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-xend 5 xen-build fail REGR. vs. 34151 build-amd64-xend 5 xen-build fail REGR. vs. 34151 build-amd64 5 xen-build fail REGR. vs. 34151 build-i3865 xen-build fail REGR. vs. 34151 Tests which did not succeed, but are not blocking: test-amd64-amd64-pv 1 build-check(1) blocked n/a test-amd64-i386-xend-winxpsp3 1 build-check(1) blocked n/a build-i386-rumpuserxen1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-sedf-pin 1 build-check(1) blocked n/a build-amd64-libvirt 1 build-check(1) blocked n/a build-amd64-rumpuserxen 1 build-check(1) blocked n/a test-amd64-amd64-xl-winxpsp3 1 build-check(1) blocked n/a test-amd64-i386-pv1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-rumpuserxen-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-sedf 1 build-check(1) blocked n/a test-amd64-amd64-pair 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-winxpsp3 1 build-check(1) blocked n/a test-amd64-i386-xend-qemut-winxpsp3 1 build-check(1) blocked n/a test-amd64-amd64-xl-credit2 1 build-check(1) blocked n/a test-amd64-i386-xl-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-winxpsp3 1 build-check(1) blocked n/a test-amd64-i386-xl-winxpsp3-vcpus1 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 1 build-check(1) blocked n/a test-amd64-amd64-xl-multivcpu 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1)blocked n/a test-amd64-i386-freebsd10-i386 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-winxpsp3-vcpus1 1 build-check(1) blocked n/a test-amd64-amd64-xl-pcipt-intel 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-i386-pair 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-i386-rumpuserxen-i386 1 build-check(1) blocked n/a test-amd64-i386-xl1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-debianhvm-amd64 1 build-check(1)blocked n/a test-amd64-i386-rhel6hvm-intel 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 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-sedf 10 migrate-support-checkfail never pass test-armhf-armhf-xl-midway 10 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 5 xen-boot fail never pass version targeted for testing: xen 50a61de84f323e32a7ce0cfdf0ce8db39330de3d baseline version: xen 52e190cacf95046c99a52947aa12d7c0a2225b4d
Re: [Xen-devel] [PATCH 13/13] xen: allow more than 512 GB of RAM for 64 bit pv-domains
On 18.02.15 at 10:37, jgr...@suse.com wrote: On 02/18/2015 10:21 AM, Paul Bolle wrote: On Wed, 2015-02-18 at 07:52 +0100, Juergen Gross wrote: --- a/arch/x86/xen/Kconfig +++ b/arch/x86/xen/Kconfig @@ -23,14 +23,29 @@ config XEN_PVHVM def_bool y depends on XEN PCI X86_LOCAL_APIC -config XEN_MAX_DOMAIN_MEMORY - int - default 500 if X86_64 - default 64 if X86_32 - depends on XEN - help - This only affects the sizing of some bss arrays, the unused - portions of which are freed. +if X86_64 Not XEN ? The complete directory is made only if CONFIG_XEN is set. But that doesn't mean this file gets used only when XEN is enabled. I would think though that an eventual if XEN should have wider scope than just this option (i.e. likely almost the entire file). Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC v1 0/8] xen: kconfig changes
On 17/02/15 07:39, Juergen Gross wrote: If we have neither XEN_PV nor XEN_PVH set, why do we have to build enlighten.c? It will never be used. Same should apply to several other files in arch/x86/xen. Can we limit this series to only Kconfig changes? I don't really like scope-creep in patch series. David ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] dprintk() and gdprintk() to be compiled out when NDEBUG
On 18.02.15 at 11:58, ian.campb...@citrix.com wrote: On Wed, 2015-02-11 at 07:50 +, Jan Beulich wrote: Quite likely the (mis-)use of these two functions may then temporarily result in messages not meant to be debugging ones to become hidden in non-debug builds. If others agree, I'd try to make one pass through the tree to try to identify such, Thanks, that would be useful I think. Will you cover arch/arm too? I did the patch and the auditing pass already, and I skipped - as you kind of expected - arch/arm. Since we're not under pressure and everyone should be doing debug builds right now anyway, I don't think applying the to-be-posted patch without ARM adjustments will do much harm; let me know if you think otherwise. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] dprintk() and gdprintk() to be compiled out when NDEBUG
On Wed, 2015-02-18 at 11:05 +, Jan Beulich wrote: On 18.02.15 at 11:58, ian.campb...@citrix.com wrote: On Wed, 2015-02-11 at 07:50 +, Jan Beulich wrote: Quite likely the (mis-)use of these two functions may then temporarily result in messages not meant to be debugging ones to become hidden in non-debug builds. If others agree, I'd try to make one pass through the tree to try to identify such, Thanks, that would be useful I think. Will you cover arch/arm too? I did the patch and the auditing pass already, and I skipped - as you kind of expected - arch/arm. Since we're not under pressure and everyone should be doing debug builds right now anyway, I don't think applying the to-be-posted patch without ARM adjustments will do much harm; let me know if you think otherwise. No problem, please go ahead and I'll try and find a moment to audit the ARM ones separately. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 1/2] x86/tboot: invalidate FIX_TBOOT_MAP_ADDRESS mapping after use
In order for commit cbeeaa7d (x86/nmi: fix shootdown of pcpus running in VMX non-root mode)'s re-use of that fixmap entry to not cause undesirable (in crash context) cross-CPU TLB flushes, invalidate the fixmap entry right after use. Signed-off-by: Jan Beulich jbeul...@suse.com --- a/xen/arch/x86/tboot.c +++ b/xen/arch/x86/tboot.c @@ -138,6 +138,7 @@ void __init tboot_probe(void) TXT_PUB_CONFIG_REGS_BASE + TXTCR_SINIT_BASE); tboot_copy_memory((unsigned char *)sinit_size, sizeof(sinit_size), TXT_PUB_CONFIG_REGS_BASE + TXTCR_SINIT_SIZE); +__set_fixmap(FIX_TBOOT_MAP_ADDRESS, 0, 0); } /* definitions from xen/drivers/passthrough/vtd/iommu.h @@ -476,6 +477,8 @@ int __init tboot_parse_dmar_table(acpi_t dmar_table_raw = xmalloc_array(unsigned char, dmar_table_length); tboot_copy_memory(dmar_table_raw, dmar_table_length, pa); dmar_table = (struct acpi_table_header *)dmar_table_raw; +__set_fixmap(FIX_TBOOT_MAP_ADDRESS, 0, 0); + rc = dmar_handler(dmar_table); xfree(dmar_table_raw); x86/tboot: invalidate FIX_TBOOT_MAP_ADDRESS mapping after use In order for commit cbeeaa7d (x86/nmi: fix shootdown of pcpus running in VMX non-root mode)'s re-use of that fixmap entry to not cause undesirable (in crash context) cross-CPU TLB flushes, invalidate the fixmap entry right after use. Signed-off-by: Jan Beulich jbeul...@suse.com --- a/xen/arch/x86/tboot.c +++ b/xen/arch/x86/tboot.c @@ -138,6 +138,7 @@ void __init tboot_probe(void) TXT_PUB_CONFIG_REGS_BASE + TXTCR_SINIT_BASE); tboot_copy_memory((unsigned char *)sinit_size, sizeof(sinit_size), TXT_PUB_CONFIG_REGS_BASE + TXTCR_SINIT_SIZE); +__set_fixmap(FIX_TBOOT_MAP_ADDRESS, 0, 0); } /* definitions from xen/drivers/passthrough/vtd/iommu.h @@ -476,6 +477,8 @@ int __init tboot_parse_dmar_table(acpi_t dmar_table_raw = xmalloc_array(unsigned char, dmar_table_length); tboot_copy_memory(dmar_table_raw, dmar_table_length, pa); dmar_table = (struct acpi_table_header *)dmar_table_raw; +__set_fixmap(FIX_TBOOT_MAP_ADDRESS, 0, 0); + rc = dmar_handler(dmar_table); xfree(dmar_table_raw); ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V5 12/12] xen/vm_event: Add RESUME option to vm_event_op domctl
On 17.02.15 at 19:32, tamas.leng...@zentific.com wrote:
On Tue, Feb 17, 2015 at 3:31 PM, Jan Beulich jbeul...@suse.com wrote:
On 13.02.15 at 17:33, tamas.leng...@zentific.com wrote:
@@ -611,13 +611,22 @@ int vm_event_domctl(struct domain *d,
xen_domctl_vm_event_op_t *vec,
}
break;
-case XEN_VM_EVENT_PAGING_DISABLE:
+case XEN_VM_EVENT_DISABLE:
{
if ( ved-ring_page )
rc = vm_event_disable(d, ved);
}
break;
+case XEN_VM_EVENT_RESUME:
+{
+if ( ved-ring_page )
+vm_event_resume(d, ved);
+else
+rc = -ENODEV;
+}
+break;
Stray braces again.
Ack.
I also find it confusing that the same set of changes repeats three
times here - is that an indication of a problem with an earlier patch?
No it's not. There are three rings vm_event can use, thus three rings
that can be resumed.
But if the code ends up being almost identical, this loudly calls for
consolidation into e.g. a helper function.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC v1 0/8] xen: kconfig changes
On 02/18/2015 11:03 AM, David Vrabel wrote: On 17/02/15 07:39, Juergen Gross wrote: If we have neither XEN_PV nor XEN_PVH set, why do we have to build enlighten.c? It will never be used. Same should apply to several other files in arch/x86/xen. Can we limit this series to only Kconfig changes? I don't really like scope-creep in patch series. Are you sure this is possible? XEN will be configured in more cases as today: this is the result of being able to build pv-drivers for hvm domains. BTW: it was you who wanted XEN_PVHVM to be implying XEN. So today the complete directory arch/x86/xen isn't built for non-pv kernels. Do you really want to change this? I don't think this is acceptable. Juergen ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 13/13] xen: allow more than 512 GB of RAM for 64 bit pv-domains
On 18/02/15 06:52, Juergen Gross wrote: +if X86_64 +choice + prompt Support pv-domains larger than 512GB + default XEN_512GB_NONE + help + Support paravirtualized domains with more than 512GB of RAM. + + The Xen tools and crash dump analysis tools might not support + pv-domains with more than 512 GB of RAM. This option controls the + default setting of the kernel to use only up to 512 GB or more. + It is always possible to change the default via specifying the + boot parameter xen_512gb_limit. + + config XEN_512GB_NONE + bool neither dom0 nor domUs can be larger than 512GB + config XEN_512GB_DOM0 + bool dom0 can be larger than 512GB, domUs not + config XEN_512GB_DOMU + bool domUs can be larger than 512GB, dom0 not + config XEN_512GB_ALL + bool dom0 and domUs can be larger than 512GB +endchoice +endif This configuration option doesn't look useful to me. Can we get rid of it with runtime checking. e.g., If dom0, enable 512G. If domU, enable 512G if requested by command line option /or/ toolstack indicates that it supports the linear p2m. And If max_pfn 512G, populate 3-level p2m /unless/ toolstack indicates it supports the linear p2m. People using crash analysis tools that need the 3-level p2m can clamp dom0 memory with the Xen command line option. FWIW, the tool we use doesn't need this. David ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/2] arm/xen: Correctly check if the event channel interrupt is present
On Thu, 2015-02-12 at 06:34 +, Julien Grall wrote: The function irq_of_parse_and_map returns 0 when the IRQ is not found. Furthermore xen_events_irq is only read when the CPU is bring up, so it's not necessary to use the attribute __read_mostly. Part of the purpose of __read_mostly is to move such things out of sharing cachelines with other more hot read/write things, as much as it is to group all the read only things together. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 0/2] arm/arm64: Detect Xen support earlier
On Thu, 2015-02-12 at 06:34 +, Julien Grall wrote: Hello, This small patch series move the detection of running on Xen earlier. This is required in order to support earlyprintk via Xen and selecting the preferred console. Thanks for doing this, having all of the init done in an initcall (even a relatively early one) has been a niggle I've wanted address for ages, for exactly earlyprintk and preferred console reasons. I had a very minor comment on #1 but nonetheless both patches: Acked-by: Ian Campbell ian.campb...@citrix.com Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V5 06/12] x86/hvm: factor out and rename vm_event related functions
On 17.02.15 at 18:37, tamas.leng...@zentific.com wrote:
On Tue, Feb 17, 2015 at 12:56 PM, Jan Beulich jbeul...@suse.com wrote:
On 13.02.15 at 17:33, tamas.leng...@zentific.com wrote:
+static void hvm_event_cr(uint32_t reason, unsigned long value,
+unsigned long old)
+{
+vm_event_request_t req = {
+.reason = reason,
+.vcpu_id = current-vcpu_id,
+.u.mov_to_cr.new_value = value,
+.u.mov_to_cr.old_value = old
+};
+uint64_t parameters = 0;
+
+switch(reason)
Coding style. Also I continue to think using switch() here rather than
having the caller pass both VM_EVENT_* and HVM_PARAM_* is ugly/
inefficient (even if the compiler may be able to sort this out for you).
It's getting retired in the series so there isn't much point in
tweaking it here.
I realized that looking at later patches in this series, but then you
could similarly argue that the other requested adjustments are
unnecessary. But please always keep in mind that series may get
applied partially. And of course ideally a series wouldn't introduce
code just for a later patch to delete it again - i.e. if you already
find you want/need to do that, then please accept that coding
style remarks are still being made and considered relevant.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4] modify the IO_TLB_SEGSIZE and IO_TLB_DEFAULT_SIZE configurable as flexible requirement about SW-IOMMU.
On 18.02.15 at 10:09, xiaoming.w...@intel.com wrote:
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: Tuesday, February 17, 2015 6:09 PM
On 17.02.15 at 07:51, xiaoming.w...@intel.com wrote:
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -3438,10 +3438,12 @@ bytes respectively. Such letter suffixes can
also be entirely omitted.
it if 0 is given (See
Documentation/cgroups/memory.txt)
swiotlb=[ARM,IA-64,PPC,MIPS,X86]
- Format: { int | force }
+ Format: { int | force | int | int}
int -- Number of I/O TLB slabs
force -- force using of bounce buffers even if they
wouldn't be automatically used by the kernel
+ int -- Maximum allowable number of contiguous
slabs to map
+ int -- The size of SW-MMU mapped.
This makes no sense - the new numbers added aren't position independent
(nor were the previous int and force).
Use , can separate them one by one.
We do it at lib/swiotlb.c
Right, but the documentation above doesn't say so.
Also you are (supposedly) removing all uses of IO_TLB_DEFAULT_SIZE, yet
you don't seem to remove the definition itself.
I have change all uses of IO_TLB_DEFAULT_SIZE to io_tlb_default_size in
lib/swiotlb.c
Then are there any left elsewhere? If not, again - why don't you
remove the definition of IO_TLB_DEFAULT_SIZE?
Finally - are arbitrary numbers really okay for the newly added command line
options? I.e. shouldn't you add some checking of their validity?
I have validity these code is OK.
Example:
BOARD_KERNEL_CMDLINE += swiotlb=, ,512,268435456
Io_tlb_segsize has been changed from 128 to 512
Io_tlb_default_size has been changed from 64M to 268435456 (256M)
I specifically said arbitrary numbers, which in particular includes
zero and non-power-of-2 values. If there are any restrictions on
which numbers can validly be passed here (and it very much looks
like there are), such restrictions should be enforced imo.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V6 04/13] xen: Rename mem_event to vm_event
On 18.02.15 at 01:11, tamas.leng...@zentific.com wrote: diff --git a/xen/common/mem_event.c b/xen/common/vm_event.c similarity index 59% rename from xen/common/mem_event.c rename to xen/common/vm_event.c Looking at this already quite huge delta I can't really see why adjusting white space at once would make it much worse. In any case better than leaving white space damage behind. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 02/13] xen: anchor linear p2m list in shared info structure
On 18/02/15 06:51, Juergen Gross wrote:
The linear p2m list should be anchored in the shared info structure
I'm not really sure what you mean by anchored.
read by the Xen tools to be able to support 64 bit pv-domains larger
than 512 MB. Additionally the linear p2m list interface includes a
generation count which is changed prior to and after each mapping
change of the p2m list. Reading the generation count the Xen tools can
detect changes of the mappings and re-read the p2m list eventually.
[...]
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -256,6 +256,10 @@ void xen_setup_mfn_list_list(void)
HYPERVISOR_shared_info-arch.pfn_to_mfn_frame_list_list =
virt_to_mfn(p2m_top_mfn);
HYPERVISOR_shared_info-arch.max_pfn = xen_max_p2m_pfn;
+ HYPERVISOR_shared_info-arch.p2m_generation = 0;
+ HYPERVISOR_shared_info-arch.p2m_vaddr = (unsigned long)xen_p2m_addr;
+ HYPERVISOR_shared_info-arch.p2m_cr3 =
+ xen_pfn_to_cr3(virt_to_mfn(swapper_pg_dir));
}
/* Set up p2m_top to point to the domain-builder provided p2m pages */
@@ -469,8 +473,10 @@ static pte_t *alloc_p2m_pmd(unsigned long addr, pte_t
*pte_pg)
ptechk = lookup_address(vaddr, level);
if (ptechk == pte_pg) {
+ HYPERVISOR_shared_info-arch.p2m_generation++;
set_pmd(pmdp,
__pmd(__pa(pte_newpg[i]) | _KERNPG_TABLE));
+ HYPERVISOR_shared_info-arch.p2m_generation++;
Do these increments of p2m_generation need to be atomic?
David
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 2/2] x86/tboot: simplify DMAR table copying
On 18/02/15 09:03, Jan Beulich wrote:
There's no need for more than one variable, no need for casts, and no
point in using the type-safe xmalloc_array() here.
Signed-off-by: Jan Beulich jbeul...@suse.com
Reviewed-by: Andrew Cooper andrew.coop...@citrix.com
--- a/xen/arch/x86/tboot.c
+++ b/xen/arch/x86/tboot.c
@@ -435,13 +435,12 @@ int __init tboot_protect_mem_regions(voi
int __init tboot_parse_dmar_table(acpi_table_handler dmar_handler)
{
-struct acpi_table_header *dmar_table;
int rc;
uint64_t size;
uint32_t dmar_table_length;
unsigned long pa;
sinit_mle_data_t sinit_mle_data;
-unsigned char *dmar_table_raw;
+void *dmar_table;
if ( !tboot_in_measured_env() )
return acpi_table_parse(ACPI_SIG_DMAR, dmar_handler);
@@ -474,13 +473,12 @@ int __init tboot_parse_dmar_table(acpi_t
tboot_copy_memory((unsigned char *)dmar_table_length,
sizeof(dmar_table_length),
pa + sizeof(char) * ACPI_NAME_SIZE);
-dmar_table_raw = xmalloc_array(unsigned char, dmar_table_length);
-tboot_copy_memory(dmar_table_raw, dmar_table_length, pa);
-dmar_table = (struct acpi_table_header *)dmar_table_raw;
+dmar_table = xmalloc_bytes(dmar_table_length);
+tboot_copy_memory(dmar_table, dmar_table_length, pa);
__set_fixmap(FIX_TBOOT_MAP_ADDRESS, 0, 0);
rc = dmar_handler(dmar_table);
-xfree(dmar_table_raw);
+xfree(dmar_table);
/* acpi_parse_dmar() zaps APCI DMAR signature in TXT heap table */
/* but dom0 will read real table, so must zap it there too */
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 0/2] x86: tboot adjustments
1: invalidate FIX_TBOOT_MAP_ADDRESS mapping after use 2: simplify DMAR table copying Signed-off-by: Jan Beulich jbeul...@suse.com ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V5 10/12] xen/vm_event: Relocate memop checks
On 17.02.15 at 19:47, tamas.leng...@zentific.com wrote:
On Tue, Feb 17, 2015 at 3:25 PM, Jan Beulich jbeul...@suse.com wrote:
On 13.02.15 at 17:33, tamas.leng...@zentific.com wrote:
-int mem_paging_memop(struct domain *d, xen_mem_paging_op_t *mpo)
+int mem_paging_memop(unsigned long cmd,
+ XEN_GUEST_HANDLE_PARAM(xen_mem_paging_op_t) arg)
{
-int rc = -ENODEV;
+int rc;
+xen_mem_paging_op_t mpo;
+struct domain *d;
+
+rc = -EFAULT;
+if ( copy_from_guest(mpo, arg, 1) )
+return rc;
Please don't make things more complicated than they need to be:
You only use the -EFAULT once here, so no reason to assign it to
rc up front.
This return will be a goto out; where the rcu is getting unlocked as well.
How that? You didn't take the RCU lock yet (which is even visible
from the rest of the hunk above).
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 13/13] xen: allow more than 512 GB of RAM for 64 bit pv-domains
On Wed, 2015-02-18 at 10:37 +0100, Juergen Gross wrote:
On 02/18/2015 10:21 AM, Paul Bolle wrote:
On Wed, 2015-02-18 at 07:52 +0100, Juergen Gross wrote:
+choice
+ prompt Support pv-domains larger than 512GB
+ default XEN_512GB_NONE
+ help
+Support paravirtualized domains with more than 512GB of RAM.
+
+The Xen tools and crash dump analysis tools might not support
+pv-domains with more than 512 GB of RAM. This option controls the
+default setting of the kernel to use only up to 512 GB or more.
+It is always possible to change the default via specifying the
+boot parameter xen_512gb_limit.
+
+ config XEN_512GB_NONE
+ bool neither dom0 nor domUs can be larger than 512GB
+ config XEN_512GB_DOM0
+ bool dom0 can be larger than 512GB, domUs not
+ config XEN_512GB_DOMU
+ bool domUs can be larger than 512GB, dom0 not
+ config XEN_512GB_ALL
+ bool dom0 and domUs can be larger than 512GB
+endchoice
So there are actually two independent limits, configured through a
choice with four entries. Would using just two separate Kconfig symbols
(XEN_512GB_DOM0 and XEN_512GB_DOMU) without a choice wrapper also work?
Yes.
Because ...
+endif
[...]
@@ -85,6 +87,27 @@ static struct {
*/
#define EXTRA_MEM_RATIO (10)
+static bool xen_dom0_512gb_limit __initdata =
+ IS_ENABLED(CONFIG_XEN_512GB_NONE) || IS_ENABLED(CONFIG_XEN_512GB_DOMU);
... then this could be something like:
static bool xen_dom0_512gb_limit __initdata =
!IS_ENABLED(CONFIG_XEN_512GB_DOM0);
+static bool xen_domu_512gb_limit __initdata =
+ IS_ENABLED(CONFIG_XEN_512GB_NONE) || IS_ENABLED(CONFIG_XEN_512GB_DOM0);
+
and this likewise:
static bool xen_domu_512gb_limit __initdata =
!IS_ENABLED(CONFIG_XEN_512GB_DOMU);
Correct?
Yes.
That's a matter of taste, I think.
Well, my suggestion does look simpler. Anyhow, I'll be glad to let the
maintainers decide.
+static int __init xen_parse_512gb(char *arg)
+{
+ bool val = false;
+
+ if (!arg)
+ val = true;
+ else if (strtobool(arg, val))
+ return 1;
+
+ xen_dom0_512gb_limit = val;
+ xen_domu_512gb_limit = val;
+
+ return 0;
+}
+early_param(xen_512gb_limit, xen_parse_512gb);
+
static void __init xen_add_extra_mem(phys_addr_t start, phys_addr_t size)
{
int i;
So one can configure these two limits separately, but the kernel
parameter is used for both. Any particular reason?
Yes. A kernel is running only either as Dom0 or as domU at a given time.
Having two parameters here would be nonsense, as only one could apply.
I see.
And being able to configure both limits separately does make sense,
of course.
Thanks,
Paul Bolle
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 02/13] xen: anchor linear p2m list in shared info structure
On 02/18/2015 11:50 AM, Andrew Cooper wrote:
On 18/02/15 10:42, Juergen Gross wrote:
/* Set up p2m_top to point to the domain-builder provided p2m
pages */
@@ -469,8 +473,10 @@ static pte_t *alloc_p2m_pmd(unsigned long addr,
pte_t *pte_pg)
ptechk = lookup_address(vaddr, level);
if (ptechk == pte_pg) {
+HYPERVISOR_shared_info-arch.p2m_generation++;
set_pmd(pmdp,
__pmd(__pa(pte_newpg[i]) | _KERNPG_TABLE));
+HYPERVISOR_shared_info-arch.p2m_generation++;
Do these increments of p2m_generation need to be atomic?
Hmm, they are done under lock. I don't think the compiler is allowed to
reorder the writes to p2m_generation across set_pmd().
They do need smp_wmb() to guarantee that the increment is visible before
the update occurs, just as the toolstack will need smp_rmb() to read.
Okay, I'll add smp_wmb() before and after calling set_pmd().
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v18 05/16] x86/VPMU: Interface for setting PMU mode and flags
Am Montag 16 Februar 2015, 17:26:48 schrieb Boris Ostrovsky:
Add runtime interface for setting PMU mode and flags. Three main modes are
provided:
* XENPMU_MODE_OFF: PMU is not virtualized
* XENPMU_MODE_SELF: Guests can access PMU MSRs and receive PMU interrupts.
* XENPMU_MODE_HV: Same as XENPMU_MODE_SELF for non-proviledged guests, dom0
can profile itself and the hypervisor.
Note that PMU modes are different from what can be provided at Xen's boot line
with 'vpmu' argument. An 'off' (or '0') value is equivalent to
XENPMU_MODE_OFF.
Any other value, on the other hand, will cause VPMU mode to be set to
XENPMU_MODE_SELF during boot.
For feature flags only Intel's BTS is currently supported.
Mode and flags are set via HYPERVISOR_xenpmu_op hypercall.
Signed-off-by: Boris Ostrovsky boris.ostrov...@oracle.com
Acked-by: Daniel De Graaf dgde...@tycho.nsa.gov
---
tools/flask/policy/policy/modules/xen/xen.te | 3 +
xen/arch/x86/domain.c| 6 +-
xen/arch/x86/hvm/svm/vpmu.c | 25 ++-
xen/arch/x86/hvm/vmx/vmcs.c | 7 +-
xen/arch/x86/hvm/vmx/vpmu_core2.c| 27 ++-
xen/arch/x86/hvm/vpmu.c | 240
+--
xen/arch/x86/oprofile/nmi_int.c | 3 +-
xen/arch/x86/x86_64/compat/entry.S | 4 +
xen/arch/x86/x86_64/entry.S | 4 +
xen/include/asm-x86/hvm/vmx/vmcs.h | 7 +-
xen/include/asm-x86/hvm/vpmu.h | 33 +++-
xen/include/public/pmu.h | 45 +
xen/include/public/xen.h | 1 +
xen/include/xen/hypercall.h | 4 +
xen/include/xlat.lst | 1 +
xen/include/xsm/dummy.h | 15 ++
xen/include/xsm/xsm.h| 6 +
xen/xsm/dummy.c | 1 +
xen/xsm/flask/hooks.c| 18 ++
xen/xsm/flask/policy/access_vectors | 2 +
20 files changed, 417 insertions(+), 35 deletions(-)
diff --git a/tools/flask/policy/policy/modules/xen/xen.te
b/tools/flask/policy/policy/modules/xen/xen.te
index c0128aa..870ff81 100644
--- a/tools/flask/policy/policy/modules/xen/xen.te
+++ b/tools/flask/policy/policy/modules/xen/xen.te
@@ -68,6 +68,9 @@ allow dom0_t xen_t:xen2 {
resource_op
psr_cmt_op
};
+allow dom0_t xen_t:xen2 {
+pmu_ctrl
+};
allow dom0_t xen_t:mmu memorymap;
# Allow dom0 to use these domctls on itself. For domctls acting on other
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index eb8ac3a..b0e3c3d 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -1536,7 +1536,7 @@ void context_switch(struct vcpu *prev, struct vcpu
*next)
if ( is_hvm_vcpu(prev) )
{
if (prev != next)
-vpmu_save(vcpu_vpmu(prev));
+vpmu_switch_from(vcpu_vpmu(prev), vcpu_vpmu(next));
if ( !list_empty(prev-arch.hvm_vcpu.tm_list) )
pt_save_timer(prev);
@@ -1579,9 +1579,9 @@ void context_switch(struct vcpu *prev, struct vcpu
*next)
!is_hardware_domain(next-domain));
}
-if (is_hvm_vcpu(next) (prev != next) )
+if ( is_hvm_vcpu(next) (prev != next) )
/* Must be done with interrupts enabled */
-vpmu_load(vcpu_vpmu(next));
+vpmu_switch_to(vcpu_vpmu(prev), vcpu_vpmu(next));
context_saved(prev);
diff --git a/xen/arch/x86/hvm/svm/vpmu.c b/xen/arch/x86/hvm/svm/vpmu.c
index 72e2561..2cfdf08 100644
--- a/xen/arch/x86/hvm/svm/vpmu.c
+++ b/xen/arch/x86/hvm/svm/vpmu.c
@@ -253,6 +253,26 @@ static int amd_vpmu_save(struct vpmu_struct *vpmu)
return 1;
}
+static void amd_vpmu_unload(struct vpmu_struct *vpmu)
+{
+struct vcpu *v;
+
+if ( vpmu_is_set(vpmu, VPMU_CONTEXT_LOADED | VPMU_FROZEN) )
+{
+unsigned int i;
+
+for ( i = 0; i num_counters; i++ )
+wrmsrl(ctrls[i], 0);
+context_save(vpmu);
+}
+
+v = vpmu_vcpu(vpmu);
+if ( has_hvm_container_vcpu(v) is_msr_bitmap_on(vpmu) )
+amd_vpmu_unset_msr_bitmap(v);
+
+vpmu_reset(vpmu, VPMU_FROZEN);
+}
+
static void context_update(unsigned int msr, u64 msr_content)
{
unsigned int i;
@@ -471,17 +491,18 @@ struct arch_vpmu_ops amd_vpmu_ops = {
.arch_vpmu_destroy = amd_vpmu_destroy,
.arch_vpmu_save = amd_vpmu_save,
.arch_vpmu_load = amd_vpmu_load,
+.arch_vpmu_unload = amd_vpmu_unload,
.arch_vpmu_dump = amd_vpmu_dump
};
-int svm_vpmu_initialise(struct vcpu *v, unsigned int vpmu_flags)
+int svm_vpmu_initialise(struct vcpu *v)
{
struct vpmu_struct *vpmu = vcpu_vpmu(v);
uint8_t family = current_cpu_data.x86;
int ret = 0;
/* vpmu enabled? */
-if ( !vpmu_flags )
+if ( vpmu_mode == XENPMU_MODE_OFF )
return 0;
switch (
Re: [Xen-devel] [RFC] Tweaking the release process for Xen 4.6
On Tue, 2015-02-10 at 15:04 +, Wei Liu wrote: Not much to add... a couple of comments. Counting from the point that we forked the tree, it took ~11 months to ship 4.5. The time spent on development was 7 months (Feb 21 to Sept 24), and the time spent on freeze was ~4 months (Sept 24 to Jan 6). The good thing was that code quality was ensured, the downside was that such long freeze FWIW I was really starting to feel like the freeze had gone on forever by the end of it, and was feeling like there had been stuff which was pushed on at the end of the summer which had now been sitting in limbo for far too long. With the above proposal in mind, here is my proposed time frame for Xen 4.6 release: Development start: 6 Jan 2015 Feature freeze:10 Jul 2015 Release date: 9 Oct 2015 (could release earlier) This is 6 months of dev + 3 of freeze, for 9 months in total. Note that the release date is not a goal. It is more like a deadline we try to keep up with. We might be well able to release earlier if everything is in good shape. In fact I think we could reasonably aim for a two month freeze (~6 rcs) and pencil in the third month as potential slippage time which we don't plan to use. Any thought on this tweaked process? Comments are welcome. Wei. ___ 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 13/13] xen: allow more than 512 GB of RAM for 64 bit pv-domains
On Wed, 2015-02-18 at 07:52 +0100, Juergen Gross wrote:
64 bit pv-domains under Xen are limited to 512 GB of RAM today. The
main reason has been the 3 level p2m tree, which was replaced by the
virtual mapped linear p2m list. Parallel to the p2m list which is
being used by the kernel itself there is a 3 level mfn tree for usage
by the Xen tools and eventually for crash dump analysis. For this tree
the linear p2m list can serve as a replacement, too. As the kernel
can't know whether the tools are capable of dealing with the p2m list
instead of the mfn tree, the limit of 512 GB can't be dropped in all
cases.
This patch replaces the hard limit by a kernel parameter which tells
the kernel to obey the 512 GB limit or not. The default is selected by
a configuration parameter which specifies whether the 512 GB limit
should be active per default for dom0 (only crash dump analysis is
affected) and/or for domUs (additionally domain save/restore/migration
are affected).
Memory above the domain limit is returned to the hypervisor instead of
being identity mapped, which was wrong anyways.
The kernel configuration parameter to specify the maximum size of a
domain can be deleted, as it is not relevant any more.
Signed-off-by: Juergen Gross jgr...@suse.com
---
Documentation/kernel-parameters.txt | 7
arch/x86/include/asm/xen/page.h | 4 ---
arch/x86/xen/Kconfig| 31 +++-
arch/x86/xen/p2m.c | 10 +++---
arch/x86/xen/setup.c| 72
++---
5 files changed, 93 insertions(+), 31 deletions(-)
[...]
--- a/arch/x86/xen/Kconfig
+++ b/arch/x86/xen/Kconfig
@@ -23,14 +23,29 @@ config XEN_PVHVM
def_bool y
depends on XEN PCI X86_LOCAL_APIC
-config XEN_MAX_DOMAIN_MEMORY
- int
- default 500 if X86_64
- default 64 if X86_32
- depends on XEN
- help
- This only affects the sizing of some bss arrays, the unused
- portions of which are freed.
+if X86_64
Not
XEN
?
+choice
+ prompt Support pv-domains larger than 512GB
+ default XEN_512GB_NONE
+ help
+ Support paravirtualized domains with more than 512GB of RAM.
+
+ The Xen tools and crash dump analysis tools might not support
+ pv-domains with more than 512 GB of RAM. This option controls the
+ default setting of the kernel to use only up to 512 GB or more.
+ It is always possible to change the default via specifying the
+ boot parameter xen_512gb_limit.
+
+ config XEN_512GB_NONE
+ bool neither dom0 nor domUs can be larger than 512GB
+ config XEN_512GB_DOM0
+ bool dom0 can be larger than 512GB, domUs not
+ config XEN_512GB_DOMU
+ bool domUs can be larger than 512GB, dom0 not
+ config XEN_512GB_ALL
+ bool dom0 and domUs can be larger than 512GB
+endchoice
So there are actually two independent limits, configured through a
choice with four entries. Would using just two separate Kconfig symbols
(XEN_512GB_DOM0 and XEN_512GB_DOMU) without a choice wrapper also work?
Because ...
+endif
config XEN_SAVE_RESTORE
bool
[...]
diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index 84a6473..16d94de 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -32,6 +32,8 @@
#include p2m.h
#include mmu.h
+#define GB(x) ((uint64_t)(x) * 1024 * 1024 * 1024)
+
/* Amount of extra memory space we add to the e820 ranges */
struct xen_memory_region xen_extra_mem[XEN_EXTRA_MEM_MAX_REGIONS] __initdata;
@@ -85,6 +87,27 @@ static struct {
*/
#define EXTRA_MEM_RATIO (10)
+static bool xen_dom0_512gb_limit __initdata =
+ IS_ENABLED(CONFIG_XEN_512GB_NONE) || IS_ENABLED(CONFIG_XEN_512GB_DOMU);
... then this could be something like:
static bool xen_dom0_512gb_limit __initdata =
!IS_ENABLED(CONFIG_XEN_512GB_DOM0);
+static bool xen_domu_512gb_limit __initdata =
+ IS_ENABLED(CONFIG_XEN_512GB_NONE) || IS_ENABLED(CONFIG_XEN_512GB_DOM0);
+
and this likewise:
static bool xen_domu_512gb_limit __initdata =
!IS_ENABLED(CONFIG_XEN_512GB_DOMU);
Correct?
+static int __init xen_parse_512gb(char *arg)
+{
+ bool val = false;
+
+ if (!arg)
+ val = true;
+ else if (strtobool(arg, val))
+ return 1;
+
+ xen_dom0_512gb_limit = val;
+ xen_domu_512gb_limit = val;
+
+ return 0;
+}
+early_param(xen_512gb_limit, xen_parse_512gb);
+
static void __init xen_add_extra_mem(phys_addr_t start, phys_addr_t size)
{
int i;
So one can configure these two limits separately, but the kernel
parameter is used for both. Any particular reason?
Thanks,
Paul Bolle
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 13/13] xen: allow more than 512 GB of RAM for 64 bit pv-domains
On 02/18/2015 10:49 AM, Jan Beulich wrote: On 18.02.15 at 10:37, jgr...@suse.com wrote: On 02/18/2015 10:21 AM, Paul Bolle wrote: On Wed, 2015-02-18 at 07:52 +0100, Juergen Gross wrote: --- a/arch/x86/xen/Kconfig +++ b/arch/x86/xen/Kconfig @@ -23,14 +23,29 @@ config XEN_PVHVM def_bool y depends on XEN PCI X86_LOCAL_APIC -config XEN_MAX_DOMAIN_MEMORY - int - default 500 if X86_64 - default 64 if X86_32 - depends on XEN - help - This only affects the sizing of some bss arrays, the unused - portions of which are freed. +if X86_64 Not XEN ? The complete directory is made only if CONFIG_XEN is set. But that doesn't mean this file gets used only when XEN is enabled. Oh, you are right. I seem to have mixed up make and Kconfig of the directory. I would think though that an eventual if XEN should have wider scope than just this option (i.e. likely almost the entire file). Indeed. So either I'll add the XEN dependency for the new option or I do another patch adding if XEN just below configuring XEN and remove the XEN dependencies in the rest of the entries. As Luis is just doing a rework of XEN Kconfig stuff, I think I'll add the XEN dependency. Juergen ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4] modify the IO_TLB_SEGSIZE and IO_TLB_DEFAULT_SIZE configurable as flexible requirement about SW-IOMMU.
Dear Jan
-Original Message-
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: Wednesday, February 18, 2015 5:35 PM
To: Wang, Xiaoming
Cc: ch...@chris-wilson.co.uk; david.vra...@citrix.com;
lau...@codeaurora.org; heiko.carst...@de.ibm.com; li...@horizon.com;
Liu, Chuansheng; Zhang, Dongxing; takahiro.aka...@linaro.org;
a...@linux-foundation.org; linux-m...@linux-mips.org; ralf@linux-
mips.org; xen-de...@lists.xenproject.org; boris.ostrov...@oracle.com;
konrad.w...@oracle.com; d.kasat...@samsung.com; pebo...@tiscali.nl;
linux-ker...@vger.kernel.org
Subject: RE: [Xen-devel] [PATCH v4] modify the IO_TLB_SEGSIZE and
IO_TLB_DEFAULT_SIZE configurable as flexible requirement about SW-
IOMMU.
On 18.02.15 at 10:09, xiaoming.w...@intel.com wrote:
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: Tuesday, February 17, 2015 6:09 PM
On 17.02.15 at 07:51, xiaoming.w...@intel.com wrote:
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -3438,10 +3438,12 @@ bytes respectively. Such letter suffixes
can also be entirely omitted.
it if 0 is given (See
Documentation/cgroups/memory.txt)
swiotlb=[ARM,IA-64,PPC,MIPS,X86]
-Format: { int | force }
+Format: { int | force | int | int}
int -- Number of I/O TLB slabs
force -- force using of bounce buffers even if
they
wouldn't be automatically used by the
kernel
+int -- Maximum allowable number of contiguous
slabs to map
+int -- The size of SW-MMU mapped.
This makes no sense - the new numbers added aren't position
independent (nor were the previous int and force).
Use , can separate them one by one.
We do it at lib/swiotlb.c
Right, but the documentation above doesn't say so.
OK, I will add some comments on next patch version.
Also you are (supposedly) removing all uses of IO_TLB_DEFAULT_SIZE,
yet you don't seem to remove the definition itself.
I have change all uses of IO_TLB_DEFAULT_SIZE to io_tlb_default_size
in lib/swiotlb.c
Then are there any left elsewhere? If not, again - why don't you remove the
definition of IO_TLB_DEFAULT_SIZE?
There hasn't any IO_TLB_DEFAULT_SIZE left.
I check the code IO_TLB_DEFAULT_SIZE only used in lib/swiotlb.c.
And I have removed the definition of IO_TLB_DEFAULT_SIZE, in my patch
@@ -120,15 +146,13 @@ unsigned long swiotlb_nr_tbl(void) }
EXPORT_SYMBOL_GPL(swiotlb_nr_tbl);
-/* default to 64MB */
-#define IO_TLB_DEFAULT_SIZE (64UL20)
Finally - are arbitrary numbers really okay for the newly added
command line options? I.e. shouldn't you add some checking of their
validity?
I have validity these code is OK.
Example:
BOARD_KERNEL_CMDLINE += swiotlb=, ,512,268435456 Io_tlb_segsize has
been changed from 128 to 512 Io_tlb_default_size has been changed from
64M to 268435456 (256M)
I specifically said arbitrary numbers, which in particular includes zero and
non-power-of-2 values. If there are any restrictions on which numbers can
validly be passed here (and it very much looks like there are), such
restrictions should be enforced imo.
OK, we will validate for these variables' value in next patch version.
Jan
Xiaoming
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 02/13] xen: anchor linear p2m list in shared info structure
On 18/02/15 10:42, Juergen Gross wrote:
/* Set up p2m_top to point to the domain-builder provided p2m
pages */
@@ -469,8 +473,10 @@ static pte_t *alloc_p2m_pmd(unsigned long addr,
pte_t *pte_pg)
ptechk = lookup_address(vaddr, level);
if (ptechk == pte_pg) {
+HYPERVISOR_shared_info-arch.p2m_generation++;
set_pmd(pmdp,
__pmd(__pa(pte_newpg[i]) | _KERNPG_TABLE));
+HYPERVISOR_shared_info-arch.p2m_generation++;
Do these increments of p2m_generation need to be atomic?
Hmm, they are done under lock. I don't think the compiler is allowed to
reorder the writes to p2m_generation across set_pmd().
They do need smp_wmb() to guarantee that the increment is visible before
the update occurs, just as the toolstack will need smp_rmb() to read.
They also need to be protected from concurrent update inside the kernel,
for which a lock should appear to suffice.
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 02/13] xen: anchor linear p2m list in shared info structure
On 18/02/15 10:50, Andrew Cooper wrote:
On 18/02/15 10:42, Juergen Gross wrote:
/* Set up p2m_top to point to the domain-builder provided p2m
pages */
@@ -469,8 +473,10 @@ static pte_t *alloc_p2m_pmd(unsigned long addr,
pte_t *pte_pg)
ptechk = lookup_address(vaddr, level);
if (ptechk == pte_pg) {
+HYPERVISOR_shared_info-arch.p2m_generation++;
set_pmd(pmdp,
__pmd(__pa(pte_newpg[i]) | _KERNPG_TABLE));
+HYPERVISOR_shared_info-arch.p2m_generation++;
Do these increments of p2m_generation need to be atomic?
Hmm, they are done under lock. I don't think the compiler is allowed to
reorder the writes to p2m_generation across set_pmd().
They do need smp_wmb() to guarantee that the increment is visible before
the update occurs, just as the toolstack will need smp_rmb() to read.
smp_wmb() isn't good enough since you need the barrier even on non-smp
-- you need a wmb().
David
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4] modify the IO_TLB_SEGSIZE and IO_TLB_DEFAULT_SIZE configurable as flexible requirement about SW-IOMMU.
Dear Jan
-Original Message-
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: Tuesday, February 17, 2015 6:09 PM
To: Wang, Xiaoming
Cc: ch...@chris-wilson.co.uk; david.vra...@citrix.com;
lau...@codeaurora.org; heiko.carst...@de.ibm.com; li...@horizon.com;
Liu, Chuansheng; Zhang, Dongxing; takahiro.aka...@linaro.org;
a...@linux-foundation.org; linux-m...@linux-mips.org; ralf@linux-
mips.org; xen-de...@lists.xenproject.org; boris.ostrov...@oracle.com;
konrad.w...@oracle.com; d.kasat...@samsung.com; pebo...@tiscali.nl;
linux-ker...@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH v4] modify the IO_TLB_SEGSIZE and
IO_TLB_DEFAULT_SIZE configurable as flexible requirement about SW-
IOMMU.
On 17.02.15 at 07:51, xiaoming.w...@intel.com wrote:
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -3438,10 +3438,12 @@ bytes respectively. Such letter suffixes can
also be entirely omitted.
it if 0 is given (See
Documentation/cgroups/memory.txt)
swiotlb=[ARM,IA-64,PPC,MIPS,X86]
- Format: { int | force }
+ Format: { int | force | int | int}
int -- Number of I/O TLB slabs
force -- force using of bounce buffers even if they
wouldn't be automatically used by the kernel
+ int -- Maximum allowable number of contiguous
slabs to map
+ int -- The size of SW-MMU mapped.
This makes no sense - the new numbers added aren't position independent
(nor were the previous int and force).
Use , can separate them one by one.
We do it at lib/swiotlb.c
Also you are (supposedly) removing all uses of IO_TLB_DEFAULT_SIZE, yet
you don't seem to remove the definition itself.
I have change all uses of IO_TLB_DEFAULT_SIZE to io_tlb_default_size in
lib/swiotlb.c
Finally - are arbitrary numbers really okay for the newly added command line
options? I.e. shouldn't you add some checking of their validity?
I have validity these code is OK.
Example:
BOARD_KERNEL_CMDLINE += swiotlb=, ,512,268435456
Io_tlb_segsize has been changed from 128 to 512
Io_tlb_default_size has been changed from 64M to 268435456 (256M)
Jan
Xiaoming.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V5 07/12] xen: Introduce monitor_op domctl
On 17.02.15 at 19:20, tamas.leng...@zentific.com wrote:
On Tue, Feb 17, 2015 at 3:02 PM, Jan Beulich jbeul...@suse.com wrote:
On 13.02.15 at 17:33, tamas.leng...@zentific.com wrote:
rc = vm_event_enable(d, vec, ved, _VPF_mem_access,
-HVM_PARAM_MONITOR_RING_PFN,
-mem_access_notification);
-
-if ( vec-op == XEN_VM_EVENT_MONITOR_ENABLE_INTROSPECTION
- !rc )
-p2m_setup_introspection(d);
-
-}
-break;
+ HVM_PARAM_MONITOR_RING_PFN,
+ mem_access_notification);
I don't see what changes for these two lines. If it's indentation, it
should be done right when the code gets added.
Indentation can't be fixed in the code addition as it breaks git -M.
It reverts to the old format where it just removes the whole file and
adds the new one. I think its a waste to add a whole new separate
patch just to fix indentations so I just fix it here.
Considering that indentation is broken already prior to your
series, this is perhaps acceptable. But at least if indentation
was correct before the rename, it should be afterwards. You'd
have to use of git's -B option to control the resulting diff.
+#include public/domctl.h
+
+static inline
+int monitor_domctl(struct xen_domctl_monitor_op *op, struct domain *d)
The includes above are insufficient for the types used, or you should
forward declare _both_ structs and not have any includes.
Just including sched.h additionally should be enough IMHO.
Resulting in a huge pile of further dependencies. Our goal really
should be to get the dependencies down, not up - improving build
time. Hence forward declarations are very likely the better choice
here.
--- a/xen/include/asm-x86/domain.h
+++ b/xen/include/asm-x86/domain.h
@@ -241,6 +241,24 @@ struct time_scale {
u32 mul_frac;
};
+//
+/*monitor event options */
+//
+struct mov_to_cr {
+uint8_t enabled;
+uint8_t sync;
+uint8_t onchangeonly;
+};
+
+struct mov_to_msr {
+uint8_t enabled;
+uint8_t extended_capture;
+};
+
+struct debug_event {
+uint8_t enabled;
+};
These are all internal structures - is there anything wrong with using
bitfields here?
The use if bitfields is not good performance-wise AFAIK. Would there
be any benefit that would offset that?
As Andrew already said - total structure size. Also I'm pretty
convinced or $val, mem as well as and $~val,mem
aren't much worse than mov $val,mem, and the code
writing these fields shouldn't be performance critical. And
test $val,mem and cmp $val,mem (as well as
their split up alternatives, should the compiler elect to do so)
ought to be equal performance wise.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/2] x86/tboot: invalidate FIX_TBOOT_MAP_ADDRESS mapping after use
On 18/02/15 09:03, Jan Beulich wrote: In order for commit cbeeaa7d (x86/nmi: fix shootdown of pcpus running in VMX non-root mode)'s re-use of that fixmap entry to not cause undesirable (in crash context) cross-CPU TLB flushes, invalidate the fixmap entry right after use. Signed-off-by: Jan Beulich jbeul...@suse.com Reviewed-by: Andrew Cooper andrew.coop...@citrix.com --- a/xen/arch/x86/tboot.c +++ b/xen/arch/x86/tboot.c @@ -138,6 +138,7 @@ void __init tboot_probe(void) TXT_PUB_CONFIG_REGS_BASE + TXTCR_SINIT_BASE); tboot_copy_memory((unsigned char *)sinit_size, sizeof(sinit_size), TXT_PUB_CONFIG_REGS_BASE + TXTCR_SINIT_SIZE); +__set_fixmap(FIX_TBOOT_MAP_ADDRESS, 0, 0); } /* definitions from xen/drivers/passthrough/vtd/iommu.h @@ -476,6 +477,8 @@ int __init tboot_parse_dmar_table(acpi_t dmar_table_raw = xmalloc_array(unsigned char, dmar_table_length); tboot_copy_memory(dmar_table_raw, dmar_table_length, pa); dmar_table = (struct acpi_table_header *)dmar_table_raw; +__set_fixmap(FIX_TBOOT_MAP_ADDRESS, 0, 0); + rc = dmar_handler(dmar_table); xfree(dmar_table_raw); ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 02/13] xen: anchor linear p2m list in shared info structure
On 18/02/15 10:42, Juergen Gross wrote:
On 02/18/2015 11:32 AM, David Vrabel wrote:
On 18/02/15 06:51, Juergen Gross wrote:
The linear p2m list should be anchored in the shared info structure
I'm not really sure what you mean by anchored.
Bad wording? What about:
The virtual address of the linear p2m list should be stored in the
shared info structure.
This is better.
read by the Xen tools to be able to support 64 bit pv-domains larger
than 512 MB. Additionally the linear p2m list interface includes a
generation count which is changed prior to and after each mapping
change of the p2m list. Reading the generation count the Xen tools can
detect changes of the mappings and re-read the p2m list eventually.
[...]
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -256,6 +256,10 @@ void xen_setup_mfn_list_list(void)
HYPERVISOR_shared_info-arch.pfn_to_mfn_frame_list_list =
virt_to_mfn(p2m_top_mfn);
HYPERVISOR_shared_info-arch.max_pfn = xen_max_p2m_pfn;
+HYPERVISOR_shared_info-arch.p2m_generation = 0;
+HYPERVISOR_shared_info-arch.p2m_vaddr = (unsigned
long)xen_p2m_addr;
+HYPERVISOR_shared_info-arch.p2m_cr3 =
+xen_pfn_to_cr3(virt_to_mfn(swapper_pg_dir));
}
/* Set up p2m_top to point to the domain-builder provided p2m pages */
@@ -469,8 +473,10 @@ static pte_t *alloc_p2m_pmd(unsigned long addr,
pte_t *pte_pg)
ptechk = lookup_address(vaddr, level);
if (ptechk == pte_pg) {
+HYPERVISOR_shared_info-arch.p2m_generation++;
set_pmd(pmdp,
__pmd(__pa(pte_newpg[i]) | _KERNPG_TABLE));
+HYPERVISOR_shared_info-arch.p2m_generation++;
Do these increments of p2m_generation need to be atomic?
Hmm, they are done under lock.
Ok, atomic isn't necessary.
I don't think the compiler is allowed to
reorder the writes to p2m_generation across set_pmd().
Ok. but I think you also need to prevent the processor reordering the
writes so I think some write barriers are needed here. (The toolstack
would then need the corresponding read barriers when checking the
p2m_generation.)
David
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 02/13] xen: anchor linear p2m list in shared info structure
On 02/18/2015 11:54 AM, David Vrabel wrote:
On 18/02/15 10:50, Andrew Cooper wrote:
On 18/02/15 10:42, Juergen Gross wrote:
/* Set up p2m_top to point to the domain-builder provided p2m
pages */
@@ -469,8 +473,10 @@ static pte_t *alloc_p2m_pmd(unsigned long addr,
pte_t *pte_pg)
ptechk = lookup_address(vaddr, level);
if (ptechk == pte_pg) {
+HYPERVISOR_shared_info-arch.p2m_generation++;
set_pmd(pmdp,
__pmd(__pa(pte_newpg[i]) | _KERNPG_TABLE));
+HYPERVISOR_shared_info-arch.p2m_generation++;
Do these increments of p2m_generation need to be atomic?
Hmm, they are done under lock. I don't think the compiler is allowed to
reorder the writes to p2m_generation across set_pmd().
They do need smp_wmb() to guarantee that the increment is visible before
the update occurs, just as the toolstack will need smp_rmb() to read.
smp_wmb() isn't good enough since you need the barrier even on non-smp
-- you need a wmb().
Okay, will do.
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 02/13] xen: anchor linear p2m list in shared info structure
On 18/02/15 10:54, David Vrabel wrote:
On 18/02/15 10:50, Andrew Cooper wrote:
On 18/02/15 10:42, Juergen Gross wrote:
/* Set up p2m_top to point to the domain-builder provided p2m
pages */
@@ -469,8 +473,10 @@ static pte_t *alloc_p2m_pmd(unsigned long addr,
pte_t *pte_pg)
ptechk = lookup_address(vaddr, level);
if (ptechk == pte_pg) {
+HYPERVISOR_shared_info-arch.p2m_generation++;
set_pmd(pmdp,
__pmd(__pa(pte_newpg[i]) | _KERNPG_TABLE));
+HYPERVISOR_shared_info-arch.p2m_generation++;
Do these increments of p2m_generation need to be atomic?
Hmm, they are done under lock. I don't think the compiler is allowed to
reorder the writes to p2m_generation across set_pmd().
They do need smp_wmb() to guarantee that the increment is visible before
the update occurs, just as the toolstack will need smp_rmb() to read.
smp_wmb() isn't good enough since you need the barrier even on non-smp
-- you need a wmb().
Ah yes. I was thinking in the wrong context for smp. In this case we
need to guarantee interdomain consistency even with a UP guest kernel.
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] dprintk() and gdprintk() to be compiled out when NDEBUG
On Wed, 2015-02-11 at 07:50 +, Jan Beulich wrote: All, I'd like to propose to honor the 'd' in these functions' names (which I understand to mean debug) in that such functions should be no-ops in non-debug builds. I'd then be inclined to introduce a gprintk() automatically adding XENLOG_GUEST and the printing of current using the %pv format. Sounds fine to me. Quite likely the (mis-)use of these two functions may then temporarily result in messages not meant to be debugging ones to become hidden in non-debug builds. If others agree, I'd try to make one pass through the tree to try to identify such, Thanks, that would be useful I think. Will you cover arch/arm too? but I'd like to ask others to also keep an eye on that aspect. I'll certainly try. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V6 04/13] xen: Rename mem_event to vm_event
On Wed, Feb 18, 2015 at 4:55 PM, Tamas K Lengyel tamas.leng...@zentific.com wrote: On Wed, Feb 18, 2015 at 2:35 PM, Jan Beulich jbeul...@suse.com wrote: On 18.02.15 at 13:21, tamas.k.leng...@gmail.com wrote: On Wed Feb 18 2015 10:46:02 AM CET, Jan Beulich jbeul...@suse.com wrote: On 18.02.15 at 01:11, tamas.leng...@zentific.com wrote: diff --git a/xen/common/mem_event.c b/xen/common/vm_event.c similarity index 59% rename from xen/common/mem_event.c rename to xen/common/vm_event.c Looking at this already quite huge delta I can't really see why adjusting white space at once would make it much worse. In any case better than leaving white space damage behind. I did that in the first version of the patch and the feedback I got was that it is unreviewable that way. Not really - in the first version of the patch the old file gets removed as a whole, and the new file added. Same in v2 afaics, where indeed you got such a comment. Jan I would rather prefer it all being done in one patch but unfortunately git can't keep track of the code movement that way. I'm not aware of any option to git to achieve all this in one patch. Tamas So apparently this is possible if I relax the default 50% similarity index -M looks for. I'll merge the white-space fixing part into this patch in v7. Thanks, Tamas ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH for 4.6 13/13] xen/iommu: smmu: Add Xen specific code to be able to use the driver
___
From: Julien Grall julien.gr...@linaro.org
Sent: Wednesday, February 18, 2015 5:24 PM
To: Jaggi, Manish; xen-de...@lists.xenproject.org xen-devel
Cc: ian.campb...@citrix.com; t...@xen.org; stefano.stabell...@citrix.com;
Jaggi, Manish
Subject: Re: [PATCH for 4.6 13/13] xen/iommu: smmu: Add Xen specific code to be
able to use the driver
BTW, I have sent few versions of this series since then. Please comment
on the latest series as the code may have change.
[manish] Somehow I could not find your recent revision, but I am looking at
your den-unstable tree assuming it has your latest version.
Nonetheless, you are comment is still valid for the v3 :).
[manish] There are general comments on the data structures
(a) I don't see a use case where for same domain (VM) there would be different
context banks , so linked list may not be required.
(b) Also iommu group may not be relevant for the same reason.
I am curious to find the use cases.
Regards,
On 18/02/2015 11:47, Julien Grall wrote:
Hi Manish,
On 18/02/2015 01:02, Manish wrote:
On 17/12/14 1:38 am, Julien Grall wrote:
The main goal is to modify as little the Linux code to be able to port
easily new feature added in Linux repo for the driver.
To achieve that we:
- Add helpers to Linux function not implemented on Xen
- Add callbacks used by Xen to do our own stuff and call Linux ones
- Only modify when required the code which comes from Linux. If
so a
comment has been added with /* Xen: ... */ explaining why it's
necessary.
The support for PCI has been commented because it's not yet supported by
Xen ARM and therefore won't compile.
Signed-off-by: Julien Grall julien.gr...@linaro.org
---
xen/drivers/passthrough/arm/Makefile | 1 +
xen/drivers/passthrough/arm/smmu.c | 668
+++
2 files changed, 602 insertions(+), 67 deletions(-)
diff --git a/xen/drivers/passthrough/arm/Makefile
b/xen/drivers/passthrough/arm/Makefile
index 0484b79..f4cd26e 100644
--- a/xen/drivers/passthrough/arm/Makefile
+++ b/xen/drivers/passthrough/arm/Makefile
@@ -1 +1,2 @@
obj-y += iommu.o
+obj-y += smmu.o
diff --git a/xen/drivers/passthrough/arm/smmu.c
b/xen/drivers/passthrough/arm/smmu.c
index 8a6514f..3cf1773 100644
--- a/xen/drivers/passthrough/arm/smmu.c
+++ b/xen/drivers/passthrough/arm/smmu.c
@@ -18,6 +18,13 @@
*
* Author: Will Deacon will.dea...@arm.com
*
+ * Based on Linux drivers/iommu/arm-smmu.c
+ *= commit e6b5be2be4e30037eb551e0ed09dd97bd00d85d3
+ *
+ * Xen modification:
+ * Julien Grall julien.gr...@linaro.org
+ * Copyright (C) 2014 Linaro Limited.
+ *
* This driver currently supports:
*- SMMUv1 and v2 implementations
*- Stream-matching and stream-indexing
@@ -28,26 +35,154 @@
*- Context fault reporting
*/
snip
+/* Xen: Dummy iommu_domain */
+struct iommu_domain
+{
+struct arm_smmu_domain*priv;
+
+/* Used to link domain contexts for a same domain */
+struct list_headlist;
+};
+
+/* Xen: Describes informations required for a Xen domain */
+struct arm_smmu_xen_domain {
+spinlock_tlock;
+/* List of context (i.e iommu_domain) associated to this domain */
+struct list_headcontexts;
+};
+
+/* Xen: Information about each device stored in dev-archdata.iommu */
+struct arm_smmu_xen_device {
+struct iommu_domain *domain;
+struct iommu_group *group;
+};
+
+#define dev_archdata(dev) ((struct arm_smmu_xen_device
*)dev-archdata.iommu)
+#define dev_iommu_domain(dev) (dev_archdata(dev)-domain)
+#define dev_iommu_group(dev) (dev_archdata(dev)-group)
+
+/* Xen: Dummy iommu_group */
+struct iommu_group
+{
+struct arm_smmu_master_cfg *cfg;
+
+atomic_t ref;
+};
+
The naming needs to be revisited in this patch. Original driver from
Will has arm_smmu_domain. This patch adds iommu_domain,
arm_smmu_xen_domain, iommu_group.
I can't change the naming of the structure. iommu_domain and iommu_group
are from Linux. As we don't have it on Xen, I have to add dummy
structure for it.
Could you please add some description about the relation and hierarchy
of these data structures.
Good point, I will try to add more comment and explain why we have to do
it.
Regards,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2] xen: arm64: more useful logging on bad trap.
On 18/02/15 17:01, Ian Campbell wrote:
Dump the register state before panicing so we have some clue where the
issue occurred. Also decode the ESR register a bit to save having to
grab a pen and paper.
ESR_EL2 is a 32-bit register, so use SYSREG_READ32 not ..._READ64, as
we already do correctly in the main trap handler.
While here notice that do_trap_serror is never called and remove it.
Signed-off-by: Ian Campbell ian.campb...@citrix.com
Reviewed-by: Julien Grall julien.gr...@linaro.org
Tested-by: Jintack Lim jint...@cs.columbia.edu
Cc: jint...@cs.columbia.edu
---
Jintack, since you have a system which is exhibiting SError issues I
wonder if I could prevail on you to give this patch a try on your
system and report on the output. I've only compile tested this myself.
v2: Added blank line after variable declaration
Split log message into two lines.
s/code/ESR/ and reformat a little.
---
xen/arch/arm/arm64/traps.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/xen/arch/arm/arm64/traps.c b/xen/arch/arm/arm64/traps.c
index 1693b5d..31a3ca5 100644
--- a/xen/arch/arm/arm64/traps.c
+++ b/xen/arch/arm/arm64/traps.c
@@ -24,11 +24,6 @@
#include public/xen.h
-asmlinkage void do_trap_serror(struct cpu_user_regs *regs)
-{
-panic(Unhandled serror trap);
-}
-
static const char *handler[]= {
Synchronous Abort,
IRQ,
@@ -38,11 +33,14 @@ static const char *handler[]= {
asmlinkage void do_bad_mode(struct cpu_user_regs *regs, int reason)
{
-uint64_t esr = READ_SYSREG64(ESR_EL2);
-printk(Bad mode in %s handler detected, code 0x%08PRIx64\n,
- handler[reason], esr);
+union hsr hsr = { .bits = READ_SYSREG32(ESR_EL2) };
+
+printk(Bad mode in %s handler detected, handler[reason]);
+printk(ESR=0x%08PRIx32: EC=%PRIx32, IL=%PRIx32, ISS=%PRIx32\n,
+ hsr.bits, hsr.ec, hsr.len, hsr.iss);
This would be better as a single printk() call, otherwise a different
cpu issuing a printk() could interleave in the middle of the line.
Also, you appear to have dropped the space between detected and ESR
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 04/10] xen/blkfront: separate ring information to an new struct
-Original Message-
From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com]
Sent: 18 February 2015 17:38
To: Roger Pau Monne
Cc: Bob Liu; xen-devel@lists.xen.org; David Vrabel; linux-
ker...@vger.kernel.org; Felipe Franciosi; ax...@fb.com; h...@infradead.org;
avanzini.aria...@gmail.com
Subject: Re: [PATCH 04/10] xen/blkfront: separate ring information to an new
struct
On Wed, Feb 18, 2015 at 06:28:49PM +0100, Roger Pau Monné wrote:
El 15/02/15 a les 9.18, Bob Liu ha escrit:
A ring is the representation of a hardware queue, this patch
separate ring information from blkfront_info to an new struct
blkfront_ring_info to make preparation for real multi hardware queues
supporting.
Signed-off-by: Arianna Avanzini avanzini.aria...@gmail.com
Signed-off-by: Bob Liu bob@oracle.com
---
drivers/block/xen-blkfront.c | 403
+++
1 file changed, 218 insertions(+), 185 deletions(-)
diff --git a/drivers/block/xen-blkfront.c
b/drivers/block/xen-blkfront.c index 5a90a51..aaa4a0e 100644
--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -102,23 +102,15 @@ MODULE_PARM_DESC(max, Maximum amount
of
segments in indirect requests (default #define BLK_RING_SIZE
__CONST_RING_SIZE(blkif, PAGE_SIZE)
/*
- * We have one of these per vbd, whether ide, scsi or 'other'.
They
- * hang in private_data off the gendisk structure. We may end up
- * putting all kinds of interesting stuff here :-)
+ * Per-ring info.
+ * A blkfront_info structure can associate with one or more
+ blkfront_ring_info,
+ * depending on how many hardware queues supported.
*/
-struct blkfront_info
-{
+struct blkfront_ring_info {
spinlock_t io_lock;
- struct mutex mutex;
- struct xenbus_device *xbdev;
- struct gendisk *gd;
- int vdevice;
- blkif_vdev_t handle;
- enum blkif_state connected;
int ring_ref;
struct blkif_front_ring ring;
unsigned int evtchn, irq;
- struct request_queue *rq;
struct work_struct work;
struct gnttab_free_callback callback;
struct blk_shadow shadow[BLK_RING_SIZE]; @@ -126,6 +118,22 @@
struct blkfront_info
struct list_head indirect_pages;
unsigned int persistent_gnts_c;
unsigned long shadow_free;
+ struct blkfront_info *info;
AFAICT you seem to have a list of persistent grants, indirect pages
and a grant table callback for each ring, isn't this supposed to be
shared between all rings?
I don't think we should be going down that route, or else we can hoard
a large amount of memory and grants.
It does remove the lock that would have to be accessed by each ring thread to
access those. Those values (grants) can be limited to be a smaller value such
that the overall number is the same as it was with the previous version. As
in:
each ring has = MAX_GRANTS / nr_online_cpus().
We should definitely be concerned with the amount of memory consumed on the
backend for each plugged virtual disk. We have faced several problems in
XenServer around this area before; it drastically affects VBD scalability per
host.
This makes me think that all the persistent grants work was done as a
workaround while we were facing several performance problems around concurrent
grant un/mapping operations. Given all the recent submissions made around this
(grant ops) area, is this something we should perhaps revisit and discuss
whether we want to continue offering persistent grants as a feature?
Thanks,
Felipe
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 02/10] xen/blkfront: drop legacy block layer support
On Sun, Feb 15, 2015 at 04:18:57PM +0800, Bob Liu wrote: As Christoph suggested, remove the legacy support similar to most drivers coverted (virtio, mtip, and nvme). Please merge this into the previous patch. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V2 2/3] xen: scsiback: add LUN of restored domain
On 02/17/2015 02:02 AM, Juergen Gross wrote:
When a xen domain is being restored the LUN state of a pvscsi device
is Connected and not Initialising as in case of attaching a new
pvscsi LUN.
This must be taken into account when adding a new pvscsi device for
a domain as otherwise the pvscsi LUN won't be connected to the
SCSI target associated with it.
scsiback_do_add_lun() is being called from scsiback_frontend_changed()
which eventually sets the state to Connected. Is the added test of
'try' an optimization or is it needed for correctness?
-boris
Signed-off-by: Juergen Gross jgr...@suse.com
---
drivers/xen/xen-scsiback.c | 19 ++-
1 file changed, 14 insertions(+), 5 deletions(-)
diff --git a/drivers/xen/xen-scsiback.c b/drivers/xen/xen-scsiback.c
index 9faca6a..9d60176 100644
--- a/drivers/xen/xen-scsiback.c
+++ b/drivers/xen/xen-scsiback.c
@@ -992,7 +992,7 @@ found:
}
static void scsiback_do_add_lun(struct vscsibk_info *info, const char *state,
- char *phy, struct ids_tuple *vir)
+ char *phy, struct ids_tuple *vir, int try)
{
if (!scsiback_add_translation_entry(info, phy, vir)) {
if (xenbus_printf(XBT_NIL, info-dev-nodename, state,
@@ -1000,7 +1000,7 @@ static void scsiback_do_add_lun(struct vscsibk_info
*info, const char *state,
pr_err(xen-pvscsi: xenbus_printf error %s\n, state);
scsiback_del_translation_entry(info, vir);
}
- } else {
+ } else if (!try) {
xenbus_printf(XBT_NIL, info-dev-nodename, state,
%d, XenbusStateClosed);
}
@@ -1060,10 +1060,19 @@ static void scsiback_do_1lun_hotplug(struct
vscsibk_info *info, int op,
switch (op) {
case VSCSIBACK_OP_ADD_OR_DEL_LUN:
- if (device_state == XenbusStateInitialising)
- scsiback_do_add_lun(info, state, phy, vir);
- if (device_state == XenbusStateClosing)
+ switch (device_state) {
+ case XenbusStateInitialising:
+ scsiback_do_add_lun(info, state, phy, vir, 0);
+ break;
+ case XenbusStateConnected:
+ scsiback_do_add_lun(info, state, phy, vir, 1);
+ break;
+ case XenbusStateClosing:
scsiback_do_del_lun(info, state, vir);
+ break;
+ default:
+ break;
+ }
break;
case VSCSIBACK_OP_UPDATEDEV_STATE:
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] BUG - xen-netback stats interface limited to 32-bit values on 64 bit systems
Am 18.02.15 um 16:24 schrieb Ian Campbell: create ^ thanks On Thu, 2015-02-12 at 20:47 +0100, Atom2 wrote: Hi guys, I am forwarding this message after initially having confirmed with Ian Campbell on the user list that there's really an issue - please see further below. I am currently running xen-4.3.3 on gentoo (dom0 is based on kernel 3.17.7) and I am happy to help out by applying and testing patches on my version. FWIW based on e00f85bec0a9 this seems like it would be a reasonably straight forward introductory kernel hacking exercise (mostly copying e00f85bec0a9) if you are interested I could help guide/mentor you through it. Ian. Ian, thanks for your initiative in moving this forward. Based on your comment and your offer to help/guide me in the process, I am happy to give this a try. In the end this excercise might be more work for you than just fixing it yourself, but it might pay off in the long run. I did actually have a look at the relevant source for the xen netback code already a couple of days ago and think that I have already identified (at least parts of) the code that requires change. Unfortunately I failed miserable in finding the commit e00f85bec0a9 you were/are referring to in your mails (I used google to search, but nothing came up) and therefore thought it being too risky to just change what I thought needs changing - albeit that's part of the kernel and could just bring down a system if changed inappropriately. So if you could provide me with a link to that commit, I have something to start from and make myself familiar with the required changes. Thanks Atom2 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC PATCH 00/10] Multi-queue support for xen-block driver
On Sun, Feb 15, 2015 at 04:18:55PM +0800, Bob Liu wrote: History: It's based on the result of Arianna's internship for GNOME's Outreach Program for Women, in which she was mentored by Konrad Rzeszutek Wilk. I also worked on this patchset with her at that time, and now fully take over this task. I've got her authorization to change authorship or SoB to the patches as you like. The standard way to credit this original author is: - if the patch is unchanged just keep her as the From: and Signed-off-by. - if you add small changes add your Signed-off-by to hers, and a note like [bob: fix foobarbaz] before it. - if you substantially rewrite a patch add it as From and Signed-off-by you, but add a note to the patch text that mentions the original work it is based on. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3] modify the IO_TLB_SEGSIZE and IO_TLB_DEFAULT_SIZE configurable as flexible requirement about SW-IOMMU.
static int __init
+setup_io_tlb_segsize(char *str)
+{
+ get_option(str, io_tlb_segsize);
+ return 0;
+}
+__setup(io_tlb_segsize=, setup_io_tlb_segsize);
This should be folded in swiotlb=XYZ parsing please.
I am not very clear about this comment.
1,Do you mean it should use early_param instead of __setup?
As I known early_param can't help to assign the parameter that we changed at
kernel cmdline because we have the default value here.
int io_tlb_segsize = 128;
unsigned long io_tlb_default_size = (64UL20);
The code in 'setup_io_tlb_npages' - which is run when 'swiotlb=' parameter
is passed on the command line, can be modified to parse other extra
values. That is what I meant.
As in right now it assumes you want only to change the size of the
IOTLB buffer (64MB default). You can make the code be smarter and
accept two values, say:
32768,128
Which should make the size by the default of 64MB with an io_tlb_segsize of 128.
Or you can do:
32768,256
for also an 64MB with a io_tlb_segsize of 256 instead.
This offers users to manipulate these values as well as the initial
arch code which can modify 'io_tlb_nslabs' and 'io_tlb_segsize' during
bootup to their preferred values.
2,Or do you mean use iotlbsegsize instead of io_tlb_segsize?
No. Just fold it all under 'swiotlb' parameter please.
Also you will need to update the Documentaiton/kernel-parameters.txt file.
And naturally that will have to be updated.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 1/2] xen/arm: vgic: Keep track of vIRQ used by a domain
Hi Ian,
On 02/02/2015 15:09, Ian Campbell wrote:
On Thu, 2015-01-29 at 15:51 +, Julien Grall wrote:
- Move the retry after looking for first/end. I keep the goto
rather than a loop because it's more clear that we retry because
we were unable to set the bit
Then I think a do {} while (!successfully allocated) is what is
wanted, maybe with a comment.
I though about it and I find the do {} while more difficult to read than
the goto in this specific case.
I find more explicit with the goto that we will unlikely retry.
y. Adding a comment in the code doesn't really help.
the do {} while version would look like:
do {
virq = find_next_zero_bit(d-arch.vgic.allocated_irqs, end, first);
if ( virq = end )
return -1;
ret = test_and_set_bit(virq, d-arch.vgic.allocated_irqs);
/* There is no spinlock to protect allocated_irqs, therefore
* test_and_set_bit may unlikely fail. If so retry it.
*/
} while ( unlikely(ret) )
Regards,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC v1 0/8] xen: kconfig changes
On Tue, Feb 17, 2015 at 11:31:08AM -0800, Luis R. Rodriguez wrote: On Mon, Feb 16, 2015 at 11:26 PM, Juergen Gross jgr...@suse.com wrote: On 02/17/2015 01:25 AM, Luis R. Rodriguez wrote: On Mon, Feb 16, 2015 at 4:20 PM, Luis R. Rodriguez mcg...@do-not-panic.com wrote: As it is per our agreed upon changes we can in theory enable a XEN_PVHVM system without XEN_PV or XEN_PVH. If this is indeed desirable this poses an issue at build time And this also raises the question of whether or not we should make XEN_PVHVM a user selectable option, right now it is a def_bool and is therefore not human selectable. You can implicitly disable it by disabling PCI for example though. If we want that to be exposed to the user we can then enable some description of what that means, and the user will then be able to read / select / enable XEN_PV., XEN_PVHVM, XEN_PVH. Right now they'd only be able to select XEN_PV and/or XEN_PVH, XEN_PVHVM is implicit. I think making XEN_PVHVM user selectable is okay. OK I'll enable this then. Please don't. We had bugs in the past because distros did not select it (they made it an module) and the PV drivers were not loaded. There should be an history in the git tree behind the desire to make it non selectable. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RFC 4/5] pvh: dom0 add rw mapping for dom0_iommu_rwmem boot opt
On Wed, Feb 18, 2015 at 07:55:16AM +, Jan Beulich wrote: On 17.02.15 at 19:25, elena.ufimts...@oracle.com wrote: On Tue, Feb 17, 2015 at 12:33:12PM +, Jan Beulich wrote: For all further changes done here, I'd really like to first understand why you don't simply add extra RMRRs based on the command line option introduced in the next patch, as that would appear to make most of what you do here unnecessary. I discussed it with Konrad and it was an option, but I used that approach. Now looks like everyone is agree with adding extra RMRRs derived from command-line to existing list of RMRRs, I will post next version and will do it this way. I am not sure though if there is need to distinguish between these extra RMRRs regions and the ones derived from ACPI. Did anyone suggest you'd need to make a distinction? Yes me. We were thinking in terms of the blacklist of RMRR regions to a guest that Intel is looking at. And that these command-driven blacklist needn't be blacklisted in the guest RMRR region.. The theory was that: 1). The system admin might just want the real RMRR regions blacklisted. 2). The other regions that are blacklisted could be blacklisted or not depending on the desires of the system admin. As in, we would want the system admin to make this choice and by defualt blacklist it. That would require either keeping those two RMRR regions in two seperate buckets or perhaps have the RMRR list have an extra bit (cmd_line:yes). But all of that is a bit of hand-waving because the RMRR patches aren't yet ready and we thought it might be just easier to address this once those patches are in (or being posted as non-RFC). Um, but if this comes up - then the code can be redone to address it when the RMRR patches are ready. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V6 08/13] xen: Introduce monitor_op domctl
+int monitor_domctl(struct domain *d, struct xen_domctl_monitor_op *mop)
+{
+int rc;
+
+rc = xsm_vm_event_control(XSM_PRIV, d, vec-mode, vec-op);
+if ( rc )
+return rc;
The XSM check here has the wrong variable name and has been fixed - I seem
to have rushed a bit and missed the build error on v6. Please ignore this
patch and sorry for the noise.
Tamas
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RFC 5/5] pvh: dom0 boot option to specify iommu rw ranges
On Tue, Feb 17, 2015 at 02:14:20PM +, Andrew Cooper wrote: On 17/02/15 13:39, Jan Beulich wrote: On 17.02.15 at 14:32, andrew.coop...@citrix.com wrote: On 17/02/15 12:36, Jan Beulich wrote: On 14.02.15 at 00:21, elena.ufimts...@oracle.com wrote: On Fri, Feb 13, 2015 at 10:09:39PM +, Andrew Cooper wrote: If I understand the problem correctly, I believe that the correct solution would be to add a dmar_rmrr[ command line parameter along the same lines as ivrs_hpet[ and ivrs_ioapic[ which allows the user to inject corrections to the ACPI tables via the command line. Yes, if we agree to classify those magic locations as being not reported by ACPI machinery. One fundamental problem for someone to use this proposed option in practice is - how does(s)he learn which region(s) to specify? Trial and improvement, or find a manual for the affected system. If such an address range would appear in a manual, it would almost certainly also appear in the ACPI tables In an ideal world. (unless by manual you mean errata documentation). Also a valid source of information. The way Elena found it is by looking at the EPT violations. Perhaps that should be also mentioned in the Documentation for said parameter? ~Andrew ___ 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 v9 06/13] xen: Add ring 3 vmware_port support
On 02/17/15 09:38, Andrew Cooper wrote:
On 16/02/15 23:05, Don Slutz wrote:
Summary is that VMware treats in (%dx),%eax (or out %eax,(%dx))
to port 0x5658 specially. Note: since many operations return data
in EAX, in (%dx),%eax is the one to use. The other lengths like
in (%dx),%al will still do things, only AL part of EAX will be
changed. For out %eax,(%dx) of all lengths, EAX will remain
unchanged.
This instruction is allowed to be used from ring 3. To
support this the vmexit for GP needs to be enabled. I have not
fully tested that nested HVM is doing the right thing for this.
The support included is enough to allow VMware tools to install in a
HVM domU.
Enable no-fault of pio in x86_emulate for VMware port
Also adjust the emulation registers after doing a VMware
backdoor operation.
Add new routine hvm_emulate_one_gp() to be used by the #GP fault
handler.
Some of the best info is at:
https://sites.google.com/site/chitchatvmback/backdoor
Signed-off-by: Don Slutz dsl...@verizon.com
---
v9:
Split #GP handling (or skipping of #GP) code out of previous
patch to help with the review process.
Switch to x86_emulator to handle #GP
I think the hvm_emulate_ops_gp() covers all needed ops. Not able to validate
all paths though _hvm_emulate_one().
xen/arch/x86/hvm/emulate.c | 62 --
xen/arch/x86/hvm/svm/svm.c | 27 +++
xen/arch/x86/hvm/svm/vmcb.c| 2 ++
xen/arch/x86/hvm/vmware/vmport.c | 11 ++
xen/arch/x86/hvm/vmx/vmcs.c| 2 ++
xen/arch/x86/hvm/vmx/vmx.c | 38 +
xen/arch/x86/x86_emulate/x86_emulate.c | 25 +++---
xen/arch/x86/x86_emulate/x86_emulate.h | 8 +
xen/include/asm-x86/hvm/emulate.h | 2 ++
xen/include/asm-x86/hvm/vmport.h | 1 +
10 files changed, 172 insertions(+), 6 deletions(-)
diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
index 636c909..a6a6a5c 100644
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -22,6 +22,7 @@
#include asm/hvm/trace.h
#include asm/hvm/support.h
#include asm/hvm/svm/svm.h
+#include asm/hvm/vmport.h
static void hvmtrace_io_assist(int is_mmio, ioreq_t *p)
{
@@ -776,6 +777,7 @@ static int hvmemul_read_io_discard(
unsigned long *val,
struct x86_emulate_ctxt *ctxt)
{
+ctxt-do_vmport = 0;
This looks horribly invasive.
Why are emulation changes needed? What is wrong with the normal
handling with a registered ioport handler?
Because VMware made a bad way to provide a hyper call. They decided to
allow user access to this. So when a #GP fault should have been
reported, they instead do the hyper call.
From older thread:
Message-ID: 540f5376.6020...@oracle.com
Date: Tue, 9 Sep 2014 15:22:30 -0400
From: Boris Ostrovsky boris.ostrov...@oracle.com
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
rv:24.0) Gecko/20100101 Thunderbird/24.2.0
To: Don Slutz dsl...@verizon.com, Ian Campbell ian.campb...@citrix.com
References: 1409585629-25840-1-git-send-email-dsl...@verizon.com
1409585629-25840-4-git-send-email-dsl...@verizon.com
1410183310.3680.28.ca...@kazak.uk.xensource.com
540ddffb.2090...@terremark.com
1410255363.8217.62.ca...@kazak.uk.xensource.com
540f3967.5060...@terremark.com
In-Reply-To: 540f3967.5060...@terremark.com
...
On 09/09/2014 01:31 PM, Don Slutz wrote:
On 09/09/14 05:36, Ian Campbell wrote:
On Mon, 2014-09-08 at 12:57 -0400, Don Slutz wrote:
Also this instruction is allowed to be used from ring 3. To
support this the vmexit for GP needs to be enabled.
Isn't that quite costly?
Yes. But since that is how VMware does it, I need to do the same slow
thing.
Sounds from other subthreads like there might be other better ways? It's
hard to believe that vmware is really trapping every #GP.
I have not found a better way. The simplest statement I have come
up with is that this is not a pass thru of the VMware device. Or the
statement (in AMD land): Generate an IOIO #VMEXIT not a GP
#VMWEXIT for ioport x (or all ports).
-Don Slutz
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 04/10] xen/blkfront: separate ring information to an new struct
El 15/02/15 a les 9.18, Bob Liu ha escrit:
A ring is the representation of a hardware queue, this patch separate ring
information from blkfront_info to an new struct blkfront_ring_info to make
preparation for real multi hardware queues supporting.
Signed-off-by: Arianna Avanzini avanzini.aria...@gmail.com
Signed-off-by: Bob Liu bob@oracle.com
---
drivers/block/xen-blkfront.c | 403
+++
1 file changed, 218 insertions(+), 185 deletions(-)
diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
index 5a90a51..aaa4a0e 100644
--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -102,23 +102,15 @@ MODULE_PARM_DESC(max, Maximum amount of segments in
indirect requests (default
#define BLK_RING_SIZE __CONST_RING_SIZE(blkif, PAGE_SIZE)
/*
- * We have one of these per vbd, whether ide, scsi or 'other'. They
- * hang in private_data off the gendisk structure. We may end up
- * putting all kinds of interesting stuff here :-)
+ * Per-ring info.
+ * A blkfront_info structure can associate with one or more
blkfront_ring_info,
+ * depending on how many hardware queues supported.
*/
-struct blkfront_info
-{
+struct blkfront_ring_info {
spinlock_t io_lock;
- struct mutex mutex;
- struct xenbus_device *xbdev;
- struct gendisk *gd;
- int vdevice;
- blkif_vdev_t handle;
- enum blkif_state connected;
int ring_ref;
struct blkif_front_ring ring;
unsigned int evtchn, irq;
- struct request_queue *rq;
struct work_struct work;
struct gnttab_free_callback callback;
struct blk_shadow shadow[BLK_RING_SIZE];
@@ -126,6 +118,22 @@ struct blkfront_info
struct list_head indirect_pages;
unsigned int persistent_gnts_c;
unsigned long shadow_free;
+ struct blkfront_info *info;
AFAICT you seem to have a list of persistent grants, indirect pages and
a grant table callback for each ring, isn't this supposed to be shared
between all rings?
I don't think we should be going down that route, or else we can hoard a
large amount of memory and grants.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 04/10] xen/blkfront: separate ring information to an new struct
On Wed, Feb 18, 2015 at 06:28:49PM +0100, Roger Pau Monné wrote:
El 15/02/15 a les 9.18, Bob Liu ha escrit:
A ring is the representation of a hardware queue, this patch separate ring
information from blkfront_info to an new struct blkfront_ring_info to make
preparation for real multi hardware queues supporting.
Signed-off-by: Arianna Avanzini avanzini.aria...@gmail.com
Signed-off-by: Bob Liu bob@oracle.com
---
drivers/block/xen-blkfront.c | 403
+++
1 file changed, 218 insertions(+), 185 deletions(-)
diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
index 5a90a51..aaa4a0e 100644
--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -102,23 +102,15 @@ MODULE_PARM_DESC(max, Maximum amount of segments in
indirect requests (default
#define BLK_RING_SIZE __CONST_RING_SIZE(blkif, PAGE_SIZE)
/*
- * We have one of these per vbd, whether ide, scsi or 'other'. They
- * hang in private_data off the gendisk structure. We may end up
- * putting all kinds of interesting stuff here :-)
+ * Per-ring info.
+ * A blkfront_info structure can associate with one or more
blkfront_ring_info,
+ * depending on how many hardware queues supported.
*/
-struct blkfront_info
-{
+struct blkfront_ring_info {
spinlock_t io_lock;
- struct mutex mutex;
- struct xenbus_device *xbdev;
- struct gendisk *gd;
- int vdevice;
- blkif_vdev_t handle;
- enum blkif_state connected;
int ring_ref;
struct blkif_front_ring ring;
unsigned int evtchn, irq;
- struct request_queue *rq;
struct work_struct work;
struct gnttab_free_callback callback;
struct blk_shadow shadow[BLK_RING_SIZE];
@@ -126,6 +118,22 @@ struct blkfront_info
struct list_head indirect_pages;
unsigned int persistent_gnts_c;
unsigned long shadow_free;
+ struct blkfront_info *info;
AFAICT you seem to have a list of persistent grants, indirect pages and
a grant table callback for each ring, isn't this supposed to be shared
between all rings?
I don't think we should be going down that route, or else we can hoard a
large amount of memory and grants.
It does remove the lock that would have to be accessed by each
ring thread to access those. Those values (grants) can be limited to be a
smaller
value such that the overall number is the same as it was with the previous
version. As in: each ring has = MAX_GRANTS / nr_online_cpus().
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH for 4.6 13/13] xen/iommu: smmu: Add Xen specific code to be able to use the driver
On 18/02/2015 17:30, Jaggi, Manish wrote: [manish] There are general comments on the data structures (a) I don't see a use case where for same domain (VM) there would be different context banks , so linked list may not be required. I guess you mean the list in arm_smmu_xen_domain? All the devices pass-through to a domain may not be protected by the same SMMU. Therefore the context banks are different. Also, for now a context is allocated per-device. It should be rework to share the context between multiple device protected by the same SMMU and pass-through to the same domain. (b) Also iommu group may not be relevant for the same reason. I am curious to find the use cases. The iommu_group is used to store the configuration of the device protected by an SMMU (i.e the stream ids associated to this domain). I'm a bit surprised that you think they are not useful... Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v4] tools/libxc: Implement writev_exact() in the same style as write_exact()
This implementation of writev_exact() will cope with an iovcnt greater than
IOV_MAX because glibc will actually let this work anyway, and it is very
useful not to have to work about this in the caller of writev_exact(). The
caller is still required to ensure that the sum of iov_len's doesn't overflow
a ssize_t.
Signed-off-by: Andrew Cooper andrew.coop...@citrix.com
CC: Ian Campbell ian.campb...@citrix.com
CC: Ian Jackson ian.jack...@eu.citrix.com
CC: Wei Liu wei.l...@citrix.com
---
v4:
* Allow this to compile in a stubdom environment.
v3:
* Re-add adjustment for partial writes.
* Split min/max adjustment into separate patch.
v2:
* Remove adjustment for partial writes of a specific iov[] entry.
---
tools/libxc/xc_private.c | 79 ++
tools/libxc/xc_private.h | 14
2 files changed, 93 insertions(+)
diff --git a/tools/libxc/xc_private.c b/tools/libxc/xc_private.c
index df6cd9b..35c514a 100644
--- a/tools/libxc/xc_private.c
+++ b/tools/libxc/xc_private.c
@@ -860,6 +860,85 @@ int write_exact(int fd, const void *data, size_t size)
return 0;
}
+#if defined(__MINIOS__)
+/*
+ * MiniOS's libc doesn't know about writev(). Implement it as multiple
write()s.
+ */
+int writev_exact(int fd, const struct iovec *iov, int iovcnt)
+{
+int rc, i;
+
+for ( i = 0; i iovcnt; ++i )
+{
+rc = write_exact(fd, iov[i].iov_base, iov[i].iov_len);
+if ( rc )
+return rc;
+}
+
+return 0;
+}
+#else
+int writev_exact(int fd, const struct iovec *iov, int iovcnt)
+{
+struct iovec *local_iov = NULL;
+int rc = 0, iov_idx = 0, saved_errno = 0;
+ssize_t len;
+
+while ( iov_idx iovcnt )
+{
+/* Skip over iov[] entries with 0 length. */
+while ( iov[iov_idx].iov_len == 0 )
+if ( ++iov_idx == iovcnt )
+goto out;
+
+len = writev(fd, iov[iov_idx], min(iovcnt - iov_idx, IOV_MAX));
+saved_errno = errno;
+
+if ( (len == -1) (errno == EINTR) )
+continue;
+if ( len = 0 )
+{
+rc = -1;
+goto out;
+}
+
+/* Check iov[] to see whether we had a partial or complete write. */
+while ( len 0 (iov_idx iovcnt) )
+{
+if ( len = iov[iov_idx].iov_len )
+len -= iov[iov_idx++].iov_len;
+else
+{
+/* Partial write of iov[iov_idx]. Copy iov so we can adjust
+ * element iov_idx and resubmit the rest. */
+if ( !local_iov )
+{
+local_iov = malloc(iovcnt * sizeof(*iov));
+if ( !local_iov )
+{
+saved_errno = ENOMEM;
+goto out;
+}
+
+iov = memcpy(local_iov, iov, iovcnt * sizeof(*iov));
+}
+
+local_iov[iov_idx].iov_base += len;
+local_iov[iov_idx].iov_len -= len;
+break;
+}
+}
+}
+
+saved_errno = 0;
+
+ out:
+free(local_iov);
+errno = saved_errno;
+return rc;
+}
+#endif
+
int xc_ffs8(uint8_t x)
{
int i;
diff --git a/tools/libxc/xc_private.h b/tools/libxc/xc_private.h
index 45b8644..f74f7d7 100644
--- a/tools/libxc/xc_private.h
+++ b/tools/libxc/xc_private.h
@@ -42,6 +42,19 @@
#define VALGRIND_MAKE_MEM_UNDEFINED(addr, len) /* addr, len */
#endif
+#if defined(__MINIOS__)
+/*
+ * MiniOS's libc doesn't know about sys/uio.h or writev().
+ * Declare enough of sys/uio.h to compile.
+ */
+struct iovec {
+void *iov_base;
+size_t iov_len;
+};
+#else
+#include sys/uio.h
+#endif
+
#define DECLARE_HYPERCALL privcmd_hypercall_t hypercall
#define DECLARE_DOMCTL struct xen_domctl domctl
#define DECLARE_SYSCTL struct xen_sysctl sysctl
@@ -395,6 +408,7 @@ int xc_add_mmu_update(xc_interface *xch, struct xc_mmu *mmu,
/* Return 0 on success; -1 on error setting errno. */
int read_exact(int fd, void *data, size_t size); /* EOF = -1, errno=0 */
int write_exact(int fd, const void *data, size_t size);
+int writev_exact(int fd, const struct iovec *iov, int iovcnt);
int xc_ffs8(uint8_t x);
int xc_ffs16(uint16_t x);
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC PATCH 00/10] Multi-queue support for xen-block driver
-Original Message- From: Bob Liu [mailto:bob@oracle.com] Sent: 15 February 2015 08:19 To: xen-devel@lists.xen.org Cc: David Vrabel; linux-ker...@vger.kernel.org; Roger Pau Monne; konrad.w...@oracle.com; Felipe Franciosi; ax...@fb.com; h...@infradead.org; avanzini.aria...@gmail.com; Bob Liu Subject: [RFC PATCH 00/10] Multi-queue support for xen-block driver This patchset convert the Xen PV block driver to the multi-queue block layer API by sharing and using multiple I/O rings between the frontend and backend. History: It's based on the result of Arianna's internship for GNOME's Outreach Program for Women, in which she was mentored by Konrad Rzeszutek Wilk. I also worked on this patchset with her at that time, and now fully take over this task. I've got her authorization to change authorship or SoB to the patches as you like. A few words on block multi-queue layer: Multi-queue block layer improved block scalability a lot by split single request queue to per-processor software queues and hardware dispatch queues. The linux blk-mq API will handle software queues, while specific block driver must deal with hardware queues. IIUC, the main motivation around the blk-mq work was around locking issues on a block device's request queue when accessed concurrently from different NUMA nodes. I believe we are not stressing enough on the main benefit of taking such approach on Xen. Many modern storage systems (e.g. NVMe devices) will respond much better (especially when it comes to IOPS) to a high number of outstanding requests. That can be achieved by having a single thread sustaining a high IO depth _and/or_ several different threads issuing requests at the same time. The former approach is often limited by CPU capacity; that is, we can suffer from only being able to handle so many interrupts being delivered to the (v)CPU that the single thread is running on (also simply observable by 'top' showing the thread smoking at 100%). The latter approach is more flexible, given that many threads can run over several different (v)CPUs. I have a lot of data around this topic and am happy to share if people are interested. We can therefore use the multi-queue block layer in a guest to have more than one request queue associated with block front. These can be mapped over several rings to the backend, making it very easy for us to run multiple threads on the backend for a single virtual disk. I believe this is why Bob is seeing massive improvements when running 'fio' in a guest with an increased number of jobs. In my opinion, this motivation should be highlighted behind the blk-mq adoption by Xen. Thanks, Felipe The xen/block implementation: 1) Convert to blk-mq api with only one hardware queue. 2) Use more rings to act as multi hardware queues. 3) Negotiate number of hardware queues, the same as xen-net driver. The backend notify multi-queue-max-queues to frontend, then the front write back final number to multi-queue-num-queues. Test result: fio's IOmeter emulation on a 16 cpus domU with a null_blk device, hardware queue number was 16. nr_fio_jobs IOPS(before) IOPS(after) Diff 1 57k 58k 0% 4 95k201k+210% 8 89k372k+410% 16 68k284k+410% 32 65k196k+300% 64 63k183k+290% More results are coming, there was also big improvement on both write-IOPS and latency. Any comments or suggestions are welcome. Thank you, -Bob Liu Bob Liu (10): xen/blkfront: convert to blk-mq API xen/blkfront: drop legacy block layer support xen/blkfront: reorg info-io_lock after using blk-mq API xen/blkfront: separate ring information to an new struct xen/blkback: separate ring information out of struct xen_blkif xen/blkfront: pseudo support for multi hardware queues xen/blkback: pseudo support for multi hardware queues xen/blkfront: negotiate hardware queue number with backend xen/blkback: get hardware queue number from blkfront xen/blkfront: use work queue to fast blkif interrupt return drivers/block/xen-blkback/blkback.c | 370 --- drivers/block/xen- blkback/common.h | 54 ++- drivers/block/xen-blkback/xenbus.c | 415 +++-- drivers/block/xen-blkfront.c| 894 +--- 4 files changed, 1018 insertions(+), 715 deletions(-) -- 1.8.3.1 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 04/10] xen/blkfront: separate ring information to an new struct
AFAICT you seem to have a list of persistent grants, indirect pages and a grant table callback for each ring, isn't this supposed to be shared between all rings? I don't think we should be going down that route, or else we can hoard a large amount of memory and grants. It does remove the lock that would have to be accessed by each ring thread to access those. Those values (grants) can be limited to be a smaller value such that the overall number is the same as it was with the previous version. As in: each ring has = MAX_GRANTS / nr_online_cpus(). We should definitely be concerned with the amount of memory consumed on the backend for each plugged virtual disk. We have faced several problems in XenServer around this area before; it drastically affects VBD scalability per host. This makes me think that all the persistent grants work was done as a workaround while we were facing several performance problems around concurrent grant un/mapping operations. Given all the recent submissions made around this (grant ops) area, is this something we should perhaps revisit and discuss whether we want to continue offering persistent grants as a feature? Certainly. Perhaps as a talking point at XenHackathon? Thanks, Felipe ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC v1 0/8] xen: kconfig changes
On Wed, Feb 18, 2015 at 2:12 AM, Juergen Gross jgr...@suse.com wrote: On 02/18/2015 11:03 AM, David Vrabel wrote: On 17/02/15 07:39, Juergen Gross wrote: If we have neither XEN_PV nor XEN_PVH set, why do we have to build enlighten.c? It will never be used. Same should apply to several other files in arch/x86/xen. Can we limit this series to only Kconfig changes? I don't really like scope-creep in patch series. Are you sure this is possible? I do not think so. We can only do the smaller cleanups, the frontend stuff and the backend stuff however will remain constrained due to existing relationships being assumed under the big CONFIG_XEN. More details on this below. XEN will be configured in more cases as today: this is the result of being able to build pv-drivers for hvm domains. BTW: it was you who wanted XEN_PVHVM to be implying XEN. So today the complete directory arch/x86/xen isn't built for non-pv kernels. Do you really want to change this? I don't think this is acceptable. A simple issue example to think about: The arch/x86/kernel/head_[64|32].S file includes arch/x86/xen/xen-head.S. Now this file is #ifdef's over CONFIG_XEN. As per our agreed upon changes the frontend drivers depend on CONFIG_XEN but without CONFIG_XEN_PV and CONFIG_XEN_PVH this won't build correctly after the other changes we've discussed. What I can do, if folks like, is to pursue the split only as expected RFCs only as evaluation just to get a better idea of what changes are really required for what we discussed, I am not sure the required code changes had been scoped out before. Luis ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC v1 0/8] xen: kconfig changes
On Wed, Feb 18, 2015 at 10:11 AM, Konrad Rzeszutek Wilk konrad.w...@oracle.com wrote: On Tue, Feb 17, 2015 at 11:31:08AM -0800, Luis R. Rodriguez wrote: On Mon, Feb 16, 2015 at 11:26 PM, Juergen Gross jgr...@suse.com wrote: On 02/17/2015 01:25 AM, Luis R. Rodriguez wrote: On Mon, Feb 16, 2015 at 4:20 PM, Luis R. Rodriguez mcg...@do-not-panic.com wrote: As it is per our agreed upon changes we can in theory enable a XEN_PVHVM system without XEN_PV or XEN_PVH. If this is indeed desirable this poses an issue at build time And this also raises the question of whether or not we should make XEN_PVHVM a user selectable option, right now it is a def_bool and is therefore not human selectable. You can implicitly disable it by disabling PCI for example though. If we want that to be exposed to the user we can then enable some description of what that means, and the user will then be able to read / select / enable XEN_PV., XEN_PVHVM, XEN_PVH. Right now they'd only be able to select XEN_PV and/or XEN_PVH, XEN_PVHVM is implicit. I think making XEN_PVHVM user selectable is okay. OK I'll enable this then. Please don't. We had bugs in the past because distros did not select it (they made it an module) and the PV drivers were not loaded. Oy vey. There should be an history in the git tree behind the desire to make it non selectable. OK how about we enable the user selection only under CONFIG_EXPERT, otherwise make it hidden. Luis ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH for-4.6 0/5] xen: arm: Parse PCI DT nodes' ranges and interrupt-map
On 2/18/2015 6:48 AM, Julien Grall wrote:
Hi Suravee,
On 18/02/2015 05:28, Suravee Suthikulanit wrote:
Actually, that seems to be more related to the PCI pass-through devices.
Isn't the Cavium guys already done that work to support their PCI device
pass-through?
They were working on it, but so far there is no patch series on the ML.
It would be nice to come with a common solution (i.e between GICv2m and
GICv3 ITS) for MSI.
Agree, although for supporting Dom0 MSI, I don't see anything that could
be shared since this would totally be two separate drivers/interfaces.
Anyways, at this point, I am able to generated Dom0 device tree with
correct v2m node, and I can see Dom0 gicv2m driver probing and
initializing correctly as it would on bare-metal.
# Snippet from /sys/firmware/fdt showing dom0 GIC node
interrupt-controller {
compatible = arm,gic-400, arm,cortex-a15-gic;
#interrupt-cells = 0x3;
interrupt-controller;
reg = 0x0 0xe111 0x0 0x1000 0x0 0xe112f000 0x0 0x2000;
phandle = 0x1;
#address-cells = 0x2;
#size-cells = 0x2;
ranges = 0x0 0x0 0x0 0xe110 0x0 0x10;
v2m {
compatible = arm,gic-v2m-frame;
msi-controller;
arm,msi-base-spi = 0x40;
arm,msi-num-spis = 0x100;
phandle = 0x5;
reg = 0x0 0x8 0x0 0x1000;
};
};
linux:~ # dmesg | grep v2m
[0.00] GICv2m: Overriding V2M MSI_TYPER (base:64, num:256)
[0.00] GICv2m: Node v2m: range[0xe118:0xe1180fff],
SPI[64:320]
So, during setting up v2m in hypervisor, I also call
route_irq_to_guest() for the all SPIs used for MSI (i.e. 64-320 on
Seattle), which will force the MSIs to Dom0. However, we would need to
figure out how to detach and re-route certain interrupts to a specific
DomU in case of passing through PCI devices in the future.
Who decide to assign the MSI n to the SPI x? DOM0 or Xen?
For v2m, each MSI is tied to a specific SPI. The range of SPIs is
specified in the GIC V2M_MSI_TYPER register. In Xen, we need to make
sure that these are routed to Dom0 initially since Dom0 GICv2m driver is
the one handling all MSI assignments.
Wouldn't it be possible to route the SPI dynamically when the domain
decide to use the MSI n? We would need to implement PHYSDEVOP_map_pirq
for MSI.
Enabling MSI is done by each end-point PCI device drivers in the guest.
In Linux, this would mean that when the driver tries to allocate an MSI
interrupt, it would need to communicate back to Xen (possibly via
hypercall as you pointed out) to get the next available SPI. It is not
necessary for now. I am planning to revisit this when we try to
implement pass-through support. Lemme know if you think this should be
handled differently.
Cheers,
Suravee
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC v1 0/8] xen: kconfig changes
On Wed, Feb 18, 2015 at 12:01:43PM -0800, Luis R. Rodriguez wrote: On Wed, Feb 18, 2015 at 10:11 AM, Konrad Rzeszutek Wilk konrad.w...@oracle.com wrote: On Tue, Feb 17, 2015 at 11:31:08AM -0800, Luis R. Rodriguez wrote: On Mon, Feb 16, 2015 at 11:26 PM, Juergen Gross jgr...@suse.com wrote: On 02/17/2015 01:25 AM, Luis R. Rodriguez wrote: On Mon, Feb 16, 2015 at 4:20 PM, Luis R. Rodriguez mcg...@do-not-panic.com wrote: As it is per our agreed upon changes we can in theory enable a XEN_PVHVM system without XEN_PV or XEN_PVH. If this is indeed desirable this poses an issue at build time And this also raises the question of whether or not we should make XEN_PVHVM a user selectable option, right now it is a def_bool and is therefore not human selectable. You can implicitly disable it by disabling PCI for example though. If we want that to be exposed to the user we can then enable some description of what that means, and the user will then be able to read / select / enable XEN_PV., XEN_PVHVM, XEN_PVH. Right now they'd only be able to select XEN_PV and/or XEN_PVH, XEN_PVHVM is implicit. I think making XEN_PVHVM user selectable is okay. OK I'll enable this then. Please don't. We had bugs in the past because distros did not select it (they made it an module) and the PV drivers were not loaded. Oy vey. There should be an history in the git tree behind the desire to make it non selectable. OK how about we enable the user selection only under CONFIG_EXPERT, otherwise make it hidden. The CONFIG_EXPERT is gone from the kernel.. Luis ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC v1 0/8] xen: kconfig changes
On Wed, Feb 18, 2015 at 1:24 PM, Konrad Rzeszutek Wilk konrad.w...@oracle.com wrote: On Wed, Feb 18, 2015 at 01:11:57PM -0800, Luis R. Rodriguez wrote: On Wed, Feb 18, 2015 at 12:20 PM, Konrad Rzeszutek Wilk konrad.w...@oracle.com wrote: On Wed, Feb 18, 2015 at 12:01:43PM -0800, Luis R. Rodriguez wrote: On Wed, Feb 18, 2015 at 10:11 AM, Konrad Rzeszutek Wilk konrad.w...@oracle.com wrote: On Tue, Feb 17, 2015 at 11:31:08AM -0800, Luis R. Rodriguez wrote: On Mon, Feb 16, 2015 at 11:26 PM, Juergen Gross jgr...@suse.com wrote: On 02/17/2015 01:25 AM, Luis R. Rodriguez wrote: On Mon, Feb 16, 2015 at 4:20 PM, Luis R. Rodriguez mcg...@do-not-panic.com wrote: As it is per our agreed upon changes we can in theory enable a XEN_PVHVM system without XEN_PV or XEN_PVH. If this is indeed desirable this poses an issue at build time And this also raises the question of whether or not we should make XEN_PVHVM a user selectable option, right now it is a def_bool and is therefore not human selectable. You can implicitly disable it by disabling PCI for example though. If we want that to be exposed to the user we can then enable some description of what that means, and the user will then be able to read / select / enable XEN_PV., XEN_PVHVM, XEN_PVH. Right now they'd only be able to select XEN_PV and/or XEN_PVH, XEN_PVHVM is implicit. I think making XEN_PVHVM user selectable is okay. OK I'll enable this then. Please don't. We had bugs in the past because distros did not select it (they made it an module) and the PV drivers were not loaded. Oy vey. There should be an history in the git tree behind the desire to make it non selectable. OK how about we enable the user selection only under CONFIG_EXPERT, otherwise make it hidden. The CONFIG_EXPERT is gone from the kernel.. I see it as of next-20150218, is there a proposal to remove it? I am misremembering what was . AH, http://lwn.net/Articles/421304/ CONFIG_EMBEDDED! Sorry about the noise. So whatyda think? If that is not enough to prevent *stupid* from doing something dumb by adding own CONFIG_XEN_BUILD_EXPERT which will depend on EXPERT but default to n. That will prevent folks that typically enable EXPERT from going on venturing to disable what is visible unless they *really* want it. Luis ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC v1 0/8] xen: kconfig changes
On Wed, Feb 18, 2015 at 01:11:57PM -0800, Luis R. Rodriguez wrote: On Wed, Feb 18, 2015 at 12:20 PM, Konrad Rzeszutek Wilk konrad.w...@oracle.com wrote: On Wed, Feb 18, 2015 at 12:01:43PM -0800, Luis R. Rodriguez wrote: On Wed, Feb 18, 2015 at 10:11 AM, Konrad Rzeszutek Wilk konrad.w...@oracle.com wrote: On Tue, Feb 17, 2015 at 11:31:08AM -0800, Luis R. Rodriguez wrote: On Mon, Feb 16, 2015 at 11:26 PM, Juergen Gross jgr...@suse.com wrote: On 02/17/2015 01:25 AM, Luis R. Rodriguez wrote: On Mon, Feb 16, 2015 at 4:20 PM, Luis R. Rodriguez mcg...@do-not-panic.com wrote: As it is per our agreed upon changes we can in theory enable a XEN_PVHVM system without XEN_PV or XEN_PVH. If this is indeed desirable this poses an issue at build time And this also raises the question of whether or not we should make XEN_PVHVM a user selectable option, right now it is a def_bool and is therefore not human selectable. You can implicitly disable it by disabling PCI for example though. If we want that to be exposed to the user we can then enable some description of what that means, and the user will then be able to read / select / enable XEN_PV., XEN_PVHVM, XEN_PVH. Right now they'd only be able to select XEN_PV and/or XEN_PVH, XEN_PVHVM is implicit. I think making XEN_PVHVM user selectable is okay. OK I'll enable this then. Please don't. We had bugs in the past because distros did not select it (they made it an module) and the PV drivers were not loaded. Oy vey. There should be an history in the git tree behind the desire to make it non selectable. OK how about we enable the user selection only under CONFIG_EXPERT, otherwise make it hidden. The CONFIG_EXPERT is gone from the kernel.. I see it as of next-20150218, is there a proposal to remove it? I am misremembering what was . AH, http://lwn.net/Articles/421304/ CONFIG_EMBEDDED! Sorry about the noise. Hm, maybe I m Luis ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC v1 0/8] xen: kconfig changes
On Wed, Feb 18, 2015 at 01:31:15PM -0800, Luis R. Rodriguez wrote: On Wed, Feb 18, 2015 at 1:24 PM, Konrad Rzeszutek Wilk konrad.w...@oracle.com wrote: On Wed, Feb 18, 2015 at 01:11:57PM -0800, Luis R. Rodriguez wrote: On Wed, Feb 18, 2015 at 12:20 PM, Konrad Rzeszutek Wilk konrad.w...@oracle.com wrote: On Wed, Feb 18, 2015 at 12:01:43PM -0800, Luis R. Rodriguez wrote: On Wed, Feb 18, 2015 at 10:11 AM, Konrad Rzeszutek Wilk konrad.w...@oracle.com wrote: On Tue, Feb 17, 2015 at 11:31:08AM -0800, Luis R. Rodriguez wrote: On Mon, Feb 16, 2015 at 11:26 PM, Juergen Gross jgr...@suse.com wrote: On 02/17/2015 01:25 AM, Luis R. Rodriguez wrote: On Mon, Feb 16, 2015 at 4:20 PM, Luis R. Rodriguez mcg...@do-not-panic.com wrote: As it is per our agreed upon changes we can in theory enable a XEN_PVHVM system without XEN_PV or XEN_PVH. If this is indeed desirable this poses an issue at build time And this also raises the question of whether or not we should make XEN_PVHVM a user selectable option, right now it is a def_bool and is therefore not human selectable. You can implicitly disable it by disabling PCI for example though. If we want that to be exposed to the user we can then enable some description of what that means, and the user will then be able to read / select / enable XEN_PV., XEN_PVHVM, XEN_PVH. Right now they'd only be able to select XEN_PV and/or XEN_PVH, XEN_PVHVM is implicit. I think making XEN_PVHVM user selectable is okay. OK I'll enable this then. Please don't. We had bugs in the past because distros did not select it (they made it an module) and the PV drivers were not loaded. Oy vey. There should be an history in the git tree behind the desire to make it non selectable. OK how about we enable the user selection only under CONFIG_EXPERT, otherwise make it hidden. The CONFIG_EXPERT is gone from the kernel.. I see it as of next-20150218, is there a proposal to remove it? I am misremembering what was . AH, http://lwn.net/Articles/421304/ CONFIG_EMBEDDED! Sorry about the noise. So whatyda think? If that is not enough to prevent *stupid* from doing something dumb by adding own CONFIG_XEN_BUILD_EXPERT which will depend on EXPERT but default to n. That will prevent folks that typically enable EXPERT from going on venturing to disable what is visible unless they *really* want it. I can't think of a reason somebody would want this disabled - they already have enabled CONFIG_HYPERVISOR so obviously they want PV drivers. And if one really really wants the PV drivers disabled there is an boot line command to disable it all. Luis ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC v1 0/8] xen: kconfig changes
On Wed, Feb 18, 2015 at 12:20 PM, Konrad Rzeszutek Wilk konrad.w...@oracle.com wrote: On Wed, Feb 18, 2015 at 12:01:43PM -0800, Luis R. Rodriguez wrote: On Wed, Feb 18, 2015 at 10:11 AM, Konrad Rzeszutek Wilk konrad.w...@oracle.com wrote: On Tue, Feb 17, 2015 at 11:31:08AM -0800, Luis R. Rodriguez wrote: On Mon, Feb 16, 2015 at 11:26 PM, Juergen Gross jgr...@suse.com wrote: On 02/17/2015 01:25 AM, Luis R. Rodriguez wrote: On Mon, Feb 16, 2015 at 4:20 PM, Luis R. Rodriguez mcg...@do-not-panic.com wrote: As it is per our agreed upon changes we can in theory enable a XEN_PVHVM system without XEN_PV or XEN_PVH. If this is indeed desirable this poses an issue at build time And this also raises the question of whether or not we should make XEN_PVHVM a user selectable option, right now it is a def_bool and is therefore not human selectable. You can implicitly disable it by disabling PCI for example though. If we want that to be exposed to the user we can then enable some description of what that means, and the user will then be able to read / select / enable XEN_PV., XEN_PVHVM, XEN_PVH. Right now they'd only be able to select XEN_PV and/or XEN_PVH, XEN_PVHVM is implicit. I think making XEN_PVHVM user selectable is okay. OK I'll enable this then. Please don't. We had bugs in the past because distros did not select it (they made it an module) and the PV drivers were not loaded. Oy vey. There should be an history in the git tree behind the desire to make it non selectable. OK how about we enable the user selection only under CONFIG_EXPERT, otherwise make it hidden. The CONFIG_EXPERT is gone from the kernel.. I see it as of next-20150218, is there a proposal to remove it? Luis ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH for-4.6 0/5] xen: arm: Parse PCI DT nodes' ranges and interrupt-map
On 19/02/15 1:43 am, Suravee Suthikulanit wrote:
On 2/18/2015 6:48 AM, Julien Grall wrote:
Hi Suravee,
On 18/02/2015 05:28, Suravee Suthikulanit wrote:
Actually, that seems to be more related to the PCI pass-through
devices.
Isn't the Cavium guys already done that work to support their PCI
device
pass-through?
They were working on it, but so far there is no patch series on the ML.
It would be nice to come with a common solution (i.e between GICv2m and
GICv3 ITS) for MSI.
Agree, although for supporting Dom0 MSI, I don't see anything that
could be shared since this would totally be two separate
drivers/interfaces.
Anyways, at this point, I am able to generated Dom0 device tree with
correct v2m node, and I can see Dom0 gicv2m driver probing and
initializing correctly as it would on bare-metal.
# Snippet from /sys/firmware/fdt showing dom0 GIC node
interrupt-controller {
compatible = arm,gic-400, arm,cortex-a15-gic;
#interrupt-cells = 0x3;
interrupt-controller;
reg = 0x0 0xe111 0x0 0x1000 0x0 0xe112f000 0x0 0x2000;
phandle = 0x1;
#address-cells = 0x2;
#size-cells = 0x2;
ranges = 0x0 0x0 0x0 0xe110 0x0 0x10;
v2m {
compatible = arm,gic-v2m-frame;
msi-controller;
arm,msi-base-spi = 0x40;
arm,msi-num-spis = 0x100;
phandle = 0x5;
reg = 0x0 0x8 0x0 0x1000;
};
};
linux:~ # dmesg | grep v2m
[0.00] GICv2m: Overriding V2M MSI_TYPER (base:64, num:256)
[0.00] GICv2m: Node v2m: range[0xe118:0xe1180fff],
SPI[64:320]
So, during setting up v2m in hypervisor, I also call
route_irq_to_guest() for the all SPIs used for MSI (i.e. 64-320 on
Seattle), which will force the MSIs to Dom0. However, we would need to
figure out how to detach and re-route certain interrupts to a specific
DomU in case of passing through PCI devices in the future.
Who decide to assign the MSI n to the SPI x? DOM0 or Xen?
For v2m, each MSI is tied to a specific SPI. The range of SPIs is
specified in the GIC V2M_MSI_TYPER register. In Xen, we need to make
sure that these are routed to Dom0 initially since Dom0 GICv2m driver
is the one handling all MSI assignments.
Wouldn't it be possible to route the SPI dynamically when the domain
decide to use the MSI n? We would need to implement PHYSDEVOP_map_pirq
for MSI.
Enabling MSI is done by each end-point PCI device drivers in the
guest. In Linux, this would mean that when the driver tries to
allocate an MSI interrupt, it would need to communicate back to Xen
(possibly via hypercall as you pointed out) to get the next available
SPI. It is not necessary for now. I am planning to revisit this when
we try to implement pass-through support. Lemme know if you think this
should be handled differently.
For cavium we are doing it differently. In the frontend bus we have
added its. I am planning to send RFC patches soon.
Cheers,
Suravee
___
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 for 4.6 13/13] xen/iommu: smmu: Add Xen specific code to be able to use the driver
On 19/02/2015 02:55, Manish wrote: On 18/02/15 11:52 pm, Julien Grall wrote: On 18/02/2015 17:30, Jaggi, Manish wrote: [manish] There are general comments on the data structures (a) I don't see a use case where for same domain (VM) there would be different context banks , so linked list may not be required. I guess you mean the list in arm_smmu_xen_domain? All the devices pass-through to a domain may not be protected by the same SMMU. Therefore the context banks are different. you are right. For each smmu the context bank instance for a xen domain is duplicated with just a change in context bank id. I was thinking can it be minimized. Also, for now a context is allocated per-device. It should be rework to share the context between multiple device protected by the same SMMU and pass-through to the same domain. Yes, this is exactly I an doing at my end. (b) Also iommu group may not be relevant for the same reason. I am curious to find the use cases. The iommu_group is used to store the configuration of the device protected by an SMMU (i.e the stream ids associated to this domain). I'm a bit surprised that you think they are not useful... How do we create an iommu_group in xen ? AFAIK an iommu group is a vfio group in linux which is assigned to a a VM. lkvm run -m 512 -k home/Image ... --vfio-groups=48, 51 For Xen There are 2 ways of attaching devices using xl pci-attach or in domU cfg file. Should they create different iommu_groups ? Why are you talking about VFIO? The iommu_group is created by the SMMU when a new device is added (see arm_smmu_device). At the time we are speaking, Linux and Xen use one iommu group per-device. No matters what VFIO does. Even though we have two ways to attach PCI on the toolstack, both are using the same hypercall at the end. Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH] xen/arm: Implement dynamic allocation of irq descriptors
From: Vijaya Kumar K vijaya.ku...@caviumnetworks.com
For arm memory for 1024 irq descriptors are allocated
statically irrespective of number of interrupt supported
by the platform.
With this patch, irq descriptors are allocated at run time
and managed using red-black tree. Functions to insert, search
and delete irq descriptor are implemented in xen/common/irq.c.
Signed-off-by: Vijaya Kumar Kvijaya.ku...@caviumnetworks.com
---
xen/arch/arm/irq.c| 83 +++--
xen/common/irq.c | 58 ++
xen/include/xen/irq.h |6
3 files changed, 130 insertions(+), 17 deletions(-)
diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c
index cb9c99b..856aecf 100644
--- a/xen/arch/arm/irq.c
+++ b/xen/arch/arm/irq.c
@@ -30,6 +30,7 @@
static unsigned int local_irqs_type[NR_LOCAL_IRQS];
static DEFINE_SPINLOCK(local_irqs_type_lock);
+static DEFINE_SPINLOCK(rb_tree_desc_lock);
static void ack_none(struct irq_desc *irq)
{
@@ -48,33 +49,35 @@ hw_irq_controller no_irq_type = {
.end = end_none
};
-static irq_desc_t irq_desc[NR_IRQS];
+static struct rb_root desc_root;
+
static DEFINE_PER_CPU(irq_desc_t[NR_LOCAL_IRQS], local_irq_desc);
irq_desc_t *__irq_to_desc(int irq)
{
+struct irq_desc *desc;
+
if (irq NR_LOCAL_IRQS) return this_cpu(local_irq_desc)[irq];
-return irq_desc[irq-NR_LOCAL_IRQS];
+
+spin_lock(rb_tree_desc_lock);
+desc = find_irq_desc(desc_root, irq);
+spin_unlock(rb_tree_desc_lock);
+
+return desc;
}
-int __init arch_init_one_irq_desc(struct irq_desc *desc)
+int arch_init_one_irq_desc(struct irq_desc *desc)
{
desc-arch.type = DT_IRQ_TYPE_INVALID;
return 0;
}
-
-static int __init init_irq_data(void)
+static int init_irq_data(int irq, struct irq_desc *desc)
{
-int irq;
-
-for (irq = NR_LOCAL_IRQS; irq NR_IRQS; irq++) {
-struct irq_desc *desc = irq_to_desc(irq);
-init_one_irq_desc(desc);
-desc-irq = irq;
-desc-action = NULL;
-}
-
+ init_one_irq_desc(desc);
+ desc-irq = irq;
+ desc-action = NULL;
+
return 0;
}
@@ -114,7 +117,8 @@ void __init init_IRQ(void)
spin_unlock(local_irqs_type_lock);
BUG_ON(init_local_irq_data() 0);
-BUG_ON(init_irq_data() 0);
+
+desc_root = RB_ROOT;
}
void __cpuinit init_secondary_IRQ(void)
@@ -265,6 +269,7 @@ void release_irq(unsigned int irq, const void *dev_id)
desc = irq_to_desc(irq);
+ASSERT(desc != NULL);
spin_lock_irqsave(desc-lock,flags);
action_ptr = desc-action;
@@ -301,6 +306,11 @@ void release_irq(unsigned int irq, const void *dev_id)
if ( action-free_on_release )
xfree(action);
+
+spin_lock(rb_tree_desc_lock);
+delete_irq_desc(desc_root, irq);
+xfree(desc);
+spin_unlock(rb_tree_desc_lock);
}
static int __setup_irq(struct irq_desc *desc, unsigned int irqflags,
@@ -339,6 +349,8 @@ int setup_irq(unsigned int irq, unsigned int irqflags,
struct irqaction *new)
desc = irq_to_desc(irq);
+ASSERT(desc != NULL);
+
spin_lock_irqsave(desc-lock, flags);
if ( test_bit(_IRQ_GUEST, desc-status) )
@@ -382,7 +394,7 @@ int route_irq_to_guest(struct domain *d, unsigned int irq,
const char * devname)
{
struct irqaction *action;
-struct irq_desc *desc = irq_to_desc(irq);
+struct irq_desc *desc = NULL;
unsigned long flags;
int retval = 0;
@@ -394,6 +406,23 @@ int route_irq_to_guest(struct domain *d, unsigned int irq,
action-name = devname;
action-free_on_release = 1;
+spin_lock(rb_tree_desc_lock);
+desc = find_irq_desc(desc_root, irq);
+
+if ( desc == NULL )
+{
+/* Allocate descriptor and add to rb tree */
+desc = xzalloc(struct irq_desc);
+if ( desc == NULL )
+{
+spin_unlock(rb_tree_desc_lock);
+return -ENOMEM;
+}
+init_irq_data(irq, desc);
+insert_irq_desc(desc_root, irq, desc);
+}
+spin_unlock(rb_tree_desc_lock);
+
spin_lock_irqsave(desc-lock, flags);
/* If the IRQ is already used by someone
@@ -470,13 +499,16 @@ static bool_t irq_validate_new_type(unsigned int curr,
unsigned new)
int irq_set_spi_type(unsigned int spi, unsigned int type)
{
unsigned long flags;
-struct irq_desc *desc = irq_to_desc(spi);
+struct irq_desc *desc = NULL;
int ret = -EBUSY;
/* This function should not be used for other than SPIs */
if ( spi NR_LOCAL_IRQS )
return -EINVAL;
+desc = irq_to_desc(spi);
+ASSERT(desc != NULL);
+
spin_lock_irqsave(desc-lock, flags);
if ( !irq_validate_new_type(desc-arch.type, type) )
@@ -532,6 +564,7 @@ int platform_get_irq(const struct dt_device_node *device,
int index)
{
struct dt_irq dt_irq;
unsigned int type, irq;
+struct irq_desc *desc;
int res;
res = dt_device_get_irq(device, index, dt_irq);
@@ -541,6
Re: [Xen-devel] [PATCH for 4.6 13/13] xen/iommu: smmu: Add Xen specific code to be able to use the driver
On 19/02/15 11:31 am, Julien Grall wrote: On 19/02/2015 02:55, Manish wrote: On 18/02/15 11:52 pm, Julien Grall wrote: On 18/02/2015 17:30, Jaggi, Manish wrote: [manish] There are general comments on the data structures (a) I don't see a use case where for same domain (VM) there would be different context banks , so linked list may not be required. I guess you mean the list in arm_smmu_xen_domain? All the devices pass-through to a domain may not be protected by the same SMMU. Therefore the context banks are different. you are right. For each smmu the context bank instance for a xen domain is duplicated with just a change in context bank id. I was thinking can it be minimized. Also, for now a context is allocated per-device. It should be rework to share the context between multiple device protected by the same SMMU and pass-through to the same domain. Yes, this is exactly I an doing at my end. (b) Also iommu group may not be relevant for the same reason. I am curious to find the use cases. The iommu_group is used to store the configuration of the device protected by an SMMU (i.e the stream ids associated to this domain). I'm a bit surprised that you think they are not useful... How do we create an iommu_group in xen ? AFAIK an iommu group is a vfio group in linux which is assigned to a a VM. lkvm run -m 512 -k home/Image ... --vfio-groups=48, 51 For Xen There are 2 ways of attaching devices using xl pci-attach or in domU cfg file. Should they create different iommu_groups ? Why are you talking about VFIO? The iommu_group is created by the SMMU when a new device is added (see arm_smmu_device). At the time we are speaking, Linux and Xen use one iommu group per-device. No matters what VFIO does. Even though we have two ways to attach PCI on the toolstack, both are using the same hypercall at the end. Regards, I think we can have a discussion over it, parallely I will send RFC patches on your current state of xen-unstable smmu code. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [xen-4.4-testing test] 34737: regressions - FAIL
flight 34737 xen-4.4-testing real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/34737/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-xend 5 xen-build fail REGR. vs. 34151 build-amd64-xend 5 xen-build fail REGR. vs. 34151 build-amd64 5 xen-build fail REGR. vs. 34151 build-i3865 xen-build fail REGR. vs. 34151 Tests which did not succeed, but are not blocking: test-amd64-amd64-pv 1 build-check(1) blocked n/a build-i386-rumpuserxen1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-winxpsp3 1 build-check(1) blocked n/a test-amd64-i386-pv1 build-check(1) blocked n/a test-amd64-amd64-xl-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-xend-qemut-winxpsp3 1 build-check(1) blocked n/a test-amd64-i386-xl-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-sedf-pin 1 build-check(1) blocked n/a build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-winxpsp3 1 build-check(1) blocked n/a test-amd64-i386-xl-winxpsp3-vcpus1 1 build-check(1) blocked n/a build-amd64-rumpuserxen 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 1 build-check(1) blocked n/a test-amd64-i386-xend-winxpsp3 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-sedf 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-winxpsp3 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1)blocked n/a test-amd64-i386-freebsd10-i386 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-winxpsp3-vcpus1 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-i386-pair 1 build-check(1) blocked n/a test-amd64-amd64-pair 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-i386-rumpuserxen-i386 1 build-check(1) blocked n/a test-amd64-i386-xl1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-debianhvm-amd64 1 build-check(1)blocked n/a test-amd64-i386-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-amd64-xl-credit2 1 build-check(1) blocked n/a test-amd64-amd64-xl-multivcpu 1 build-check(1) blocked n/a test-amd64-amd64-xl-pcipt-intel 1 build-check(1) blocked n/a test-amd64-amd64-rumpuserxen-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 9 guest-start fail never pass test-armhf-armhf-xl-multivcpu 10 migrate-support-checkfail never pass test-armhf-armhf-xl-sedf-pin 10 migrate-support-checkfail never pass test-armhf-armhf-xl 10 migrate-support-checkfail never pass test-armhf-armhf-xl-sedf 10 migrate-support-checkfail never pass test-armhf-armhf-xl-midway 10 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 5 xen-boot fail never pass version targeted for testing: xen 50a61de84f323e32a7ce0cfdf0ce8db39330de3d baseline version: xen 52e190cacf95046c99a52947aa12d7c0a2225b4d
[Xen-devel] [PATCH v4 03/11] osstest: store a path runvar for built_stash_file
This mimics the behaviour of built_stash.
Signed-off-by: Roger Pau Monné roger@citrix.com
Cc: Ian Jackson ian.jack...@eu.citrix.com
Cc: Ian Campbell ian.campb...@citrix.com
---
Osstest/TestSupport.pm | 1 +
1 file changed, 1 insertion(+)
diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index 0c72faa..4d35a19 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -1221,6 +1221,7 @@ sub built_stash_file (;$) {
target_getfile($ho, 300,
$builddir/$fname,
$stash/$stashleaf);
+store_runvar(path_$item, $stashleaf);
}
sub built_compress_stashed($) {
--
1.9.3 (Apple Git-50)
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v4 01/11] osstest: allow to disable the usage of a know_host file
This is only used by target_cmd_root and target_putfile_root and will be
needed for mfsBSD which generates new keys on each boot.
Signed-off-by: Roger Pau Monné roger@citrix.com
Cc: Ian Jackson ian.jack...@eu.citrix.com
Cc: Ian Campbell ian.campb...@citrix.com
---
Osstest/TestSupport.pm | 25 -
1 file changed, 16 insertions(+), 9 deletions(-)
diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index 5ac66e5..d930e55 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -374,14 +374,21 @@ sub remote_perl_script_done ($) {
sub sshuho ($$) { my ($user,$ho)= @_; return $user\@$ho-{Ip}; }
-sub sshopts () {
+sub sshopts {
+my ($disable_hosts) = @_;
+my $hosts = tmp/t.known_hosts_$flight.$job;
+
+if (defined $disable_hosts) {
+$hosts = /dev/null;
+}
+
return [ qw(-o StrictHostKeyChecking=no
-o BatchMode=yes
-o ConnectTimeout=100
-o ServerAliveInterval=100
-o PasswordAuthentication=no
-o ChallengeResponseAuthentication=no),
- '-o', UserKnownHostsFile=tmp/t.known_hosts_$flight.$job
+ '-o', UserKnownHostsFile=$hosts
];
}
@@ -412,16 +419,16 @@ sub target_getfile_root () {
}
sub tputfileex {
-my ($ruser, $ho,$timeout, $lsrc,$rdst, $rsync) = @_;
+my ($ruser, $ho,$timeout, $lsrc,$rdst, $rsync, $disable_hosts) = @_;
my @args= ($lsrc, sshuho($ruser,$ho).:$rdst);
if (!defined $rsync) {
tcmdex($timeout,undef,
- 'scp', sshopts(),
+ 'scp', sshopts($disable_hosts),
@args);
} else {
unshift @args, $rsync if length $rsync;
tcmdex($timeout,undef,
- 'rsync', [ '-e', 'ssh '.join(' ',@{ sshopts() }) ],
+ 'rsync', [ '-e', 'ssh '.join(' ',@{ sshopts($disable_hosts) })
],
@args);
}
}
@@ -429,7 +436,7 @@ sub target_putfile (;$) {
# $ho,$timeout,$lsrc,$rdst,[$rsync_opt]
tputfileex('osstest', @_);
}
-sub target_putfile_root (;$) {
+sub target_putfile_root (;$$) {
tputfileex('root', @_);
}
sub target_run_apt {
@@ -569,14 +576,14 @@ sub target_await_down ($$) {
}
sub tcmd { # $tcmd will be put between '' but not escaped
-my ($stdout,$user,$ho,$tcmd,$timeout) = @_;
+my ($stdout,$user,$ho,$tcmd,$timeout,$disable_hosts) = @_;
$timeout=30 if !defined $timeout;
tcmdex($timeout,$stdout,
- 'ssh', sshopts(),
+ 'ssh', sshopts($disable_hosts),
sshuho($user,$ho), $tcmd);
}
sub target_cmd ($$;$) { tcmd(undef,'osstest',@_); }
-sub target_cmd_root ($$;$) { tcmd(undef,'root',@_); }
+sub target_cmd_root ($$;$$) { tcmd(undef,'root',@_); }
sub tcmdout {
my $stdout= IO::File::new_tmpfile();
--
1.9.3 (Apple Git-50)
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v4 07/11] osstest: add freebsd installer update script
This script allows moving a FreeBSD build (as produced by
ts-freebsd-create-mfsbsd) so it's usable by other test/build jobs.
Signed-off-by: Roger Pau Monné roger@citrix.com
Cc: Ian Jackson ian.jack...@eu.citrix.com
Cc: Ian Campbell ian.campb...@citrix.com
---
mg-freebsd-installer-update | 59 +
1 file changed, 59 insertions(+)
create mode 100755 mg-freebsd-installer-update
diff --git a/mg-freebsd-installer-update b/mg-freebsd-installer-update
new file mode 100755
index 000..b55d9e0
--- /dev/null
+++ b/mg-freebsd-installer-update
@@ -0,0 +1,59 @@
+#!/bin/bash
+# usage
+# ./mg-freebsd-installer-update flight job
+
+# This is part of osstest, an automated testing framework for Xen.
+# Copyright (C) 2009-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/.
+
+
+set -e
+
+. cri-getconfig
+
+flight=$1
+job=$2
+
+fail () { echo 2 $0: $1; exit 1; }
+
+case $job in
+*amd64*)
+arch=amd64
+;;
+*i386*)
+arch=i386
+;;
+*)
+fail Unsupported arch
+;;
+esac
+
+date=`date +%Y-%m-%d`
+images=`getconfig Images`
+dst=$images/freebsd/$date/$arch/
+src=logs/$flight/$job/build/
+
+mkdir -p $dst
+
+# Copy sets and mfsBSD image
+cp $src/*.txz $dst
+cp $src/MANIFEST $dst
+cp $src/mfsbsd.img $dst
+
+# Set current to point to the new version
+rm -rf $images/freebsd/current
+ln -s $date $images/freebsd/current
+
+echo Produced version: $date
--
1.9.3 (Apple Git-50)
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v4 09/11] osstest: make ts-xen-build work on FreeBSD
This patch contains a new subroutine that guesses the right make
command to use (gmake on BSDs, make otherwise).
Signed-off-by: Roger Pau Monné roger@citrix.com
Cc: Ian Jackson ian.jack...@eu.citrix.com
Cc: Ian Campbell ian.campb...@citrix.com
---
ts-xen-build | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/ts-xen-build b/ts-xen-build
index 661f186..d800396 100755
--- a/ts-xen-build
+++ b/ts-xen-build
@@ -28,6 +28,16 @@ selectbuildhost(\@ARGV);
# remaining arguments are passed as targets to make
builddirsprops();
+sub get_make_cmd() {
+my $uname = target_cmd_output_root($ho, 'uname -a', 200);
+
+if ($uname =~ m/BSD/) {
+return gmake;
+} else {
+return make;
+}
+}
+
sub checkout () {
prepbuilddirs();
@@ -91,6 +101,7 @@ END
}
sub build () {
+my $make_cmd = get_make_cmd();
my $xend_opt= $r{enable_xend} =~ m/true/ ? --enable-xend :
--disable-xend;
my $ovmf_opt= $r{enable_ovmf} =~ m/true/ ? --enable-ovmf :
--disable-ovmf;
@@ -112,7 +123,7 @@ END
END
#/;
buildcmd_stamped_logged(9000, 'build', '',END,'');
-$make_prefix make $makeflags @ARGV
+$make_prefix $make_cmd $makeflags @ARGV
END
}
--
1.9.3 (Apple Git-50)
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v4 04/11] osstest: add support for installing bare metal FreeBSD
This is done using mfsBSD, which can be booted from pxelinux and
contains a script to automatically install FreeBSD using ZFS on root.
After the install the host is set to boot from the local disk.
Signed-off-by: Roger Pau Monné roger@citrix.com
Cc: Ian Jackson ian.jack...@eu.citrix.com
Cc: Ian Campbell ian.campb...@citrix.com
---
Changes since RFC:
- Set the bridge to use the MAC from the first added interface
instead of generating a random one.
- Launch DHCP on the bridge instead of the nic.
- Add a list of FreeBSD ftp mirrors and iterate over them in order to
find a working one.
- Add support for finding the primary disk and nic automatically.
- Switch shell to sh (instead of the default csh), and use set -e in
order to exit if a command fails.
- Replace echo -Dh with printf %s -Dh.
- Copy installer keys into the installed system in order to prevent
it from generating new keys on the first boot.
---
production-config | 2 +
ts-freebsd-host-install | 283
2 files changed, 285 insertions(+)
create mode 100755 ts-freebsd-host-install
diff --git a/production-config b/production-config
index 515bd98..fefc467 100644
--- a/production-config
+++ b/production-config
@@ -86,6 +86,8 @@ HostProp_GenEtherPrefixBase 5a:36:0e:00
# :00:01 guest number in job appended
#^^ xor'd with low 8 bits of flight
+FreeBSDVersion current
+
AuthorizedKeysAppend= 'END'
ssh-rsa
B3NzaC1yc2EBIwAAAQEAq8eHHFJ+XHYgpHxfSdciq0b3tYPdMhHf9CgtwdKGSqCyDyocbn1jX6P0Z535K/JcVaxvaRQbGDl9FZ25neQw6lysE8pGf+G353mgLAE7Lw6xKqlTXDcR0GpKHiZUyY8Ck5AJlGF2MO0cDEzMBx+xkOahDBvAozikUcDHJsTNP+UUIGoRaPeQK0DfgprPkoaLzXFDiZvEoBtYcUUieuNygJt+QVM+ovyTXC68wg5Xb5Ou2PopmDaVMX6/A1HxziTWc3XdhOF5ocuRF/kfWpZL223Auuu/xvNQDly13DhuVlQiU3gRIP7BSCwCdsQC/K68Q6SgfBklKRiqHquYo/QyNQ==
osst...@woking.xci-test.com
ssh-rsa
B3NzaC1yc2EBIwAAAQEAs6FF9nfzWIlLPeYdqNteJBoYJAcgGxQgeNi7FHYDgWNFhoYPlMPXWOuXhgNxA2/vkX9tUMVZaAh+4WTL1iRBW5B/AS/Ek2O7uM2Uq8v68D2aU9/XalLVnIxssr84pewUmKW8hZfjNnRm99RTQ2Knr2BvtwcHqXtdGYdTYCJkel+FPYQ51yXGRU7dS0D59WapkDFU1tH1Y8s+dRZcRZNRJ5f1w/KO1zx1tOrZRkO3fPlEGNZHVUYfpZLPxz0VX8tOeoaOXhKZO8vSp1pD0L/uaD6FOmugMZxbtq9wEjhZciNCq61ynRf2yt2v9DMu4EAzbW/Ws7OBvWtYj/RHcSxKbw==
i...@woking.xci-test.com
diff --git a/ts-freebsd-host-install b/ts-freebsd-host-install
new file mode 100755
index 000..2097c66
--- /dev/null
+++ b/ts-freebsd-host-install
@@ -0,0 +1,283 @@
+#!/usr/bin/perl -w
+# This is part of osstest, an automated testing framework for Xen.
+# Copyright (C) 2009-2014 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 POSIX;
+
+use Osstest;
+use Osstest::TestSupport;
+use Osstest::Logtailer;
+
+use File::Basename;
+use File::Copy;
+use File::Path;
+use Cwd 'abs_path';
+
+tsreadconfig();
+
+our ($whhost) = grep /host=/, @ARGV;
+$whhost ||= 'host';
+our $ho= selecthost($whhost);
+exit 0 if $ho-{Flags}{'no-reinstall'};
+exit 0 if $ho-{SharedReady};
+
+our %timeout= qw(ReadPreseed 350
+ Sshd2400);
+
+our @disk_names = qw(ada0 da0 ad0);
+our @sets = qw(kernel.txz base.txz MANIFEST);
+
+defined($r{freebsd_buildjob}) or defined($c{FreeBSDVersion}) or
+die don't know which FreeBSD version to install;
+
+sub get_mfsbsd() {
+
+# Figure out the path to the mfsBSD image we have to use.
+# This can either come from a previous buildjob or from
+# a pre-seeded image.
+
+if ($r{freebsd_buildjob}) {
+# We are going to use the build output from a previous job.
+return get_stashed('path_mfsbsd.img', $r{freebsd_buildjob});
+} else {
+# We are going to use a pre-seeded version.
+return $c{Images}/freebsd/$c{FreeBSDVersion}/$r{arch}/mfsbsd.img;
+}
+}
+
+sub get_set($) {
+my ($set) = @_;
+
+if ($r{freebsd_buildjob}) {
+# We are going to use the build output from a previous job.
+return get_stashed(path_$set, $r{freebsd_buildjob});
+} else {
+# We are going to use a pre-seeded version.
+return $c{Images}/freebsd/$c{FreeBSDVersion}/$r{arch}/$set;
+}
+}
+
+sub setup_sets() {
+my $webfolder = $c{WebspaceFile}/$c{WebspaceCommon}/freebsd/$ho-{Name};
+
+# Link the sets to the public http folder
+rmtree($webfolder);
+
[Xen-devel] [PATCH v4 02/11] osstest: add routine to execute ssh with password
This is needed when bootstrapping FreeBSD, since the installer has ssh
enabled with the root password set to 'root' by default.
Signed-off-by: Roger Pau Monné roger@citrix.com
Cc: Ian Jackson ian.jack...@eu.citrix.com
Cc: Ian Campbell ian.campb...@citrix.com
---
Changes since RFC:
- Place the temp filename in a local variable.
- Add error checks.
---
Osstest/TestSupport.pm | 43 ++-
1 file changed, 38 insertions(+), 5 deletions(-)
diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index d930e55..0c72faa 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -60,6 +60,7 @@ BEGIN {
target_install_packages target_install_packages_norec
target_jobdir target_extract_jobdistpath_subdir
target_extract_jobdistpath target_guest_lv_name
+ target_cmd_root_with_password
poll_loop tcpconnect await_tcp
contents_make_cpio file_simple_write_contents
@@ -314,12 +315,11 @@ END
#-- running commands eg on targets --
sub cmd {
-my ($timeout,$stdout,@cmd) = @_;
+my ($timeout,$child_sub,@cmd) = @_;
my $child= fork; die $! unless defined $child;
if (!$child) {
-if (defined $stdout) {
-open STDOUT, '', $stdout
-or die STDOUT $stdout $cmd[0] $!;
+if (defined $child_sub) {
+$child_sub-();
}
exec @cmd;
die $cmd[0]: $!;
@@ -585,9 +585,42 @@ sub tcmd { # $tcmd will be put between '' but not escaped
sub target_cmd ($$;$) { tcmd(undef,'osstest',@_); }
sub target_cmd_root ($$;$$) { tcmd(undef,'root',@_); }
+sub target_cmd_root_with_password {
+my ($ho,$tcmd,$timeout,$password, $disable_hosts) = @_;
+my $temp_name = tmp/t.ssh-password-helper.$flight.$job;
+
+open(my $temp_fh, '', $temp_name)
+ or die Cannot open $temp_name: $!;
+print $temp_fh #!/bin/sh\n\necho \$password\\n
+ or die Cannot write to $temp_name: $!;
+chmod 0755, $temp_name
+ or die Cannot chmod $temp_name: $!;
+close $temp_fh
+ or die Cannot close $temp_name: $!;
+
+my $child_sub = sub {
+ $ENV{DISPLAY} = :0;
+ $ENV{SSH_ASKPASS} =
tmp/t.ssh-password-helper.$flight.$job;
+ setsid or die Can't start a new session: $!;
+};
+
+my $ssh_opts = [qw(-o BatchMode=no
+ -o PasswordAuthentication=yes
+ -o ChallengeResponseAuthentication=yes),
+@{ sshopts($disable_hosts) }];
+
+tcmdex($timeout,$child_sub,
+ 'ssh', $ssh_opts,
+ sshuho(root,$ho), $tcmd);
+
+unlink $temp_fh;
+}
+
sub tcmdout {
my $stdout= IO::File::new_tmpfile();
-tcmd($stdout,@_);
+my $stdout_sub = sub { open STDOUT, '', $stdout
+ or die STDOUT $stdout $!; };
+tcmd($stdout_sub,@_);
$stdout-seek(0,0) or die $stdout $!;
my $r;
{ local ($/) = undef;
--
1.9.3 (Apple Git-50)
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v4 00/11] osstest: add a FreeBSD host
Hello, The following series enables setting up a FreeBSD PVH Dom0 host. Although this is marked as v4 it should clearly have the RFC tag. The flow is based on the following diagram: http://xenbits.xen.org/people/royger/osstest_freebsd.jpg Patch 7 introduces a new management script, mg-freebsd-installer-update, but since this should be automatically executed when the FreeBSD/mfsBSD pushgate is updated it needs to be moved somewhere else, it's just that I'm not sure how the pushgate stuff works in order to integrate it. Also the last patch, which adds two FreeBSD specific buildjobs, is dodgy and needs some close review. Thanks, Roger. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC PATCH v2 00/29] libxl: Cancelling asynchronous operations
Euan Harris writes (Re: [RFC PATCH v2 00/29] libxl: Cancelling asynchronous operations): On Tue, Feb 10, 2015 at 08:09:47PM +, Ian Jackson wrote: I have rebased this onto current staging. I have compiled it but NOT EXECUTED IT AT ALL. Euan, I thought it would be useful to give you something you could start to work on building against. I wouldn't recommend testing it yet until I've at least smoke tested it to see that things still work if you don't cancel them. We had a chat about testing these changes, and integrating them into xenopsd. We agreed that we each had slightly different expectations of what we were going to do, and when. I think we came to the following major conclusions: - I will start work on a simple test framework for cancellation, hopefully to have first results in a fortnight or so. - Once the test framework is available you will fix whatever bugs it unearths, then we will rinse and repeat. - You will think some more about the possibility of adding cancellation to the xl command line tool, but since this is tricky there is no expectation of when it might happen. In the slightly longer term, we expect: - More testing and integration effort from Xapi project members in March or April. - Investigation of the idea of a xenopsd-based push gate, similar to the current libvirt push gate. Have I got the main points right, or forgotten anything important? That seems about right, thanks. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v4 06/11] osstest: fix ts-build-check to work with freebsd_buildjob
The output of the FreeBSD buildjob generates several files that are stashed
independently, so check each of them individually.
Signed-off-by: Roger Pau Monné roger@citrix.com
Cc: Ian Jackson ian.jack...@eu.citrix.com
Cc: Ian Campbell ian.campb...@citrix.com
---
ts-build-check | 20
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/ts-build-check b/ts-build-check
index 0ae3be8..a3dc1ef 100755
--- a/ts-build-check
+++ b/ts-build-check
@@ -24,12 +24,24 @@ die if @ARGV $ARGV[0] =~ m/^-/;
logm(checking builds ...);
+sub check_path($$) {
+my ($path, $job) = @_;
+logm(checking $job $path);
+get_stashed($path, $r{$job});
+}
+
foreach my $k (sort keys %r) {
next unless $k =~ m/^(?:.*_)?([^_]*)buildjob$/;
-my $part= $1;
-my $path= path_${part}dist;
-logm(checking $k $path);
-get_stashed($path, $r{$k});
+
+if ($k =~ m/^freebsd/) {
+my @check = qw(MANIFEST kernel.txz base.txz mfsbsd.img);
+foreach my $elem (@check) {
+check_path(path_$elem, $k);
+}
+} else {
+my $part= $1;
+check_path(path_${part}dist, $k);
+}
}
logm(all ok.);
--
1.9.3 (Apple Git-50)
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v4 05/11] osstest: add script for building custom mfsBSD images
In order to test FreeBSD HEAD we need to build a mfsBSD installer and
sets based on the version that we want to test. This patch adds support for
building such mfsBSD image and sets.
In order to build the images sources from two different repositories are
needed. The first ones of course are the FreeBSD sources which can be
fetched from the official github mirror at:
https://github.com/freebsd/freebsd.git
And the mfsBSD sources which can be downloaded from:
https://github.com/mmatuska/mfsbsd.git
We would need to have a local copy of them in order to have a push gate like
we do for Linux, Qemu or SeaBIOS.
The workflow of this would be:
1. Setup a FreeBSD host using a RELEASE image (10.1 right now).
2. Fetch upstream FreeBSD sources and compile a fresh FreeBSD world +
kernel.
3. Generate a mfsBSD image using the output from the FreeBSD build process.
4. Stash all the resulting build files (MANIFEST, kernel.txz, base.txz and
mfsbsd.img).
5. Use the newly created mfsBSD image in order to boot and the uploaded
install sets with zfsinstall.
Signed-off-by: Roger Pau Monné roger@citrix.com
Cc: Ian Jackson ian.jack...@eu.citrix.com
Cc: Ian Campbell ian.campb...@citrix.com
---
ts-freebsd-create-mfsbsd | 140 +++
1 file changed, 140 insertions(+)
create mode 100755 ts-freebsd-create-mfsbsd
diff --git a/ts-freebsd-create-mfsbsd b/ts-freebsd-create-mfsbsd
new file mode 100755
index 000..561766f
--- /dev/null
+++ b/ts-freebsd-create-mfsbsd
@@ -0,0 +1,140 @@
+#!/usr/bin/perl -w
+# This is part of osstest, an automated testing framework for Xen.
+# Copyright (C) 2009-2014 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 POSIX;
+
+use Osstest;
+use Osstest::TestSupport;
+use Osstest::BuildSupport;
+
+tsreadconfig();
+selectbuildhost(\@ARGV);
+builddirsprops();
+
+sub pkg_install {
+
+logm(Installing git);
+target_cmd_root($ho, END, 1000);
+set -e
+export ASSUME_ALWAYS_YES=YES
+pkg install -y git
+END
+}
+
+sub build_freebsd {
+
+# Since the build processes requires root access, we need to remove
+# the folder as root also.
+target_cmd_root($ho, END, 2400);
+chflags -R noschg $builddir/freebsd
+rm -rf $builddir/freebsd
+END
+
+logm(Fetching FreeBSD sources);
+build_clone($ho, 'freebsd', $builddir, 'freebsd');
+
+logm(Building FreeBSD world);
+target_cmd_root($ho, END, 1000);
+set -e
+chflags -R noschg /usr/obj
+rm -rf /usr/obj/*
+chmod 777 /usr/obj
+END
+
+target_cmd_build($ho, 9000, $builddir, END);
+rm -rf build-ok-stamp
+cd freebsd
+(make $makeflags buildworld 21 touch ../build-ok-stamp) |tee
../log-buildworld
+test -f ../build-ok-stamp
+echo ok.
+END
+
+logm(Building FreeBSD kernel);
+target_cmd_build($ho, 9000, $builddir, END);
+rm -rf build-ok-stamp
+cd freebsd
+(make $makeflags buildkernel 21 touch ../build-ok-stamp) |tee
../log-buildkernel
+test -f ../build-ok-stamp
+echo ok.
+END
+
+logm(Packing release files);
+# Needs to be done as root...
+target_cmd_root($ho, END, 2400);
+cd $builddir
+rm -rf build-ok-stamp
+cd freebsd/release
+(make ftp 21 touch ../../build-ok-stamp) |tee ../../log-release
+test -f ../../build-ok-stamp
+echo ok.
+END
+}
+
+sub build_mfsbsd {
+
+# Since the build processes requires root access, we need to remove
+# the folder as root also.
+target_cmd_root($ho, END, 1000);
+chflags -R noschg $builddir/mfsbsd
+rm -rf $builddir/mfsbsd
+END
+
+logm(Fetching mfsBSD sources);
+build_clone($ho, 'mfsbsd', $builddir, 'mfsbsd');
+target_cmd_build($ho, 100, $builddir, END);
+set -e
+cd mfsbsd
+printf %s -Dh conf/boot.config
+cp conf/loader.conf.sample conf/loader.conf
+cp conf/ttys.sample conf/ttys
+sed -i .bak 's/std.[^]*/std.$c{Baud}/' conf/ttys
+cat ENDB conf/loader.conf
+mfsbsd.rootpw=root
+boot_multicons=YES
+boot_serial=YES
+comconsole_speed=$c{Baud}
+console=comconsole,vidconsole
+boot_verbose=YES
+ENDB
+END
+
+target_cmd_root($ho, END, 2400);
+cd $builddir
+rm -rf build-ok-stamp
+cd mfsbsd
+(make
Re: [Xen-devel] [PATCH v3] vsprintf: Make sure argument to %pX specifier is valid
On 18.02.15 at 16:39, boris.ostrov...@oracle.com wrote:
--- a/xen/common/vsprintf.c
+++ b/xen/common/vsprintf.c
@@ -269,7 +269,28 @@ static char *pointer(char *str, char *end, const char
**fmt_ptr,
{
const char *fmt = *fmt_ptr, *s;
-/* Custom %p suffixes. See XEN_ROOT/docs/misc/printk-formats.txt */
+/*
+ * For custom %p suffixes (see XEN_ROOT/docs/misc/printk-formats.txt)
+ * if arg pointer is bogus then print pointer value in parentheses.
+ */
+if ( (unsigned long)arg HYPERVISOR_VIRT_START )
+{
+switch (fmt[1])
+{
+case 'h':
+case 's':
+case 'S':
+case 'v':
+++*fmt_ptr;
+if ( str end )
+*str++ = '(';
+str = number(str, end, (unsigned long)arg, 16, -1, -1, ZEROPAD);
+if ( str end )
+*str++ = ')';
You should take existing code as reference when adding to it:
Both increments above need to happen unconditionally.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 20/29] libxl: cancellation: Note that driver domain task cannot be usefully cancelled
El 10/02/15 a les 21.10, Ian Jackson ha escrit: In practice, cancelling this task will cause all subsequent actual backend operations to fail, but will not actually cause the libxl_device_events_handler operation to complete. Signed-off-by: Ian Jackson ian.jack...@eu.citrix.com Acked-by: Roger Pau Monné roger@citrix.com ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 01/29] libxl: Further fix exit paths from libxl_device_events_handler
El 10/02/15 a les 21.09, Ian Jackson ha escrit: On the success path, do not call GC_FREE explicitly. Instead, call AO_INPROGRESS. GC_FREE will free the gc underlying the long-term ao, which is then subsequently referenced in backend_watch_callback's call to libxl__nested_ao_create. It is a miracle that this ever works at all. Also, add an `if (rc) goto out;' after the xswatch registration. After this, libxl_device_events_handler has the conventional and correct ao initiation pattern. Signed-off-by: Ian Jackson ian.jack...@eu.citrix.com Acked-by: Roger Pau Monné roger@citrix.com ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v4 10/11] osstest: add a script to install Xen on FreeBSD hosts
This scripts takes care of installing the run-time dependencies, unpacking
the Xen files and setup the right configuration in order to boot a FreeBSD
PVH Dom0.
Signed-off-by: Roger Pau Monné roger@citrix.com
Cc: Ian Jackson ian.jack...@eu.citrix.com
Cc: Ian Campbell ian.campb...@citrix.com
---
ts-xen-install-freebsd | 128 +
1 file changed, 128 insertions(+)
create mode 100644 ts-xen-install-freebsd
diff --git a/ts-xen-install-freebsd b/ts-xen-install-freebsd
new file mode 100644
index 000..2e0c35d
--- /dev/null
+++ b/ts-xen-install-freebsd
@@ -0,0 +1,128 @@
+#!/usr/bin/perl -w
+# This is part of osstest, an automated testing framework for Xen.
+# Copyright (C) 2009-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 POSIX;
+use Osstest::TestSupport;
+
+my $checkmode= 0;
+
+tsreadconfig();
+
+our @hos;
+
+if (@ARGV and $ARGV[0] eq '--check') {
+$checkmode= 1;
+shift @ARGV;
+logm(checking builds are done...);
+} else {
+if (!@ARGV) {
+ push @ARGV, 'host';
+}
+foreach my $k (@ARGV) {
+push @hos, selecthost($k);
+}
+}
+
+our $ho;
+
+my %distpath;
+
+our $run_deps = yajl python curl glib gettext pixman libiconv;
+
+sub packages () {
+logm('Installing Xen runtime dependencies');
+target_cmd_root($ho, END, 2400);
+set -e
+export ASSUME_ALWAYS_YES=YES
+pkg install -y $run_deps
+END
+}
+
+sub extract () {
+my @parts = ('', 'xen');
+
+foreach my $part (@parts) {
+target_extract_jobdistpath($ho, $part, path_${part}dist,
+ $r{${part}buildjob}, \%distpath);
+}
+target_cmd_root($ho, 'gunzip -c `readlink -f /boot/xen.gz` /boot/xen',
100);
+}
+
+sub adjustconfig () {
+target_cmd_root($ho, END, 100);
+set -e
+mkdir -p /usr/local/etc/rc.conf.d
+echo 'XENCONSOLED_TRACE=guest' /usr/local/etc/rc.conf.d/xencommons
+mkdir -p /var/log/xen/console
+mkdir -p /var/lock
+mkdir -p /var/run/xen
+echo 'vm.max_wired=-1' /etc/sysctl.conf
+echo 'xc0 /usr/libexec/getty Pc xterm on secure'
/etc/ttys
+echo 'xencommons_enable=YES' /etc/rc.conf
+END
+}
+
+sub setupboot () {
+my $xenhopt = dom0pvh=1;
+
+my $cons= get_host_property($ho, 'XenSerialConsole', 'com1');
+
+if ( $cons eq com1 ) {
+ $xenhopt .= com1=$c{Baud},8n1 console=com1,vga gdb=com1;
+} elsif ( $cons eq dtuart ) {
+ $xenhopt .= console=dtuart;
+ my $dtuart= get_host_property($ho, 'XenDTUARTPath', undef);
+ $xenhopt .= dtuart=$dtuart if $dtuart;
+} else {
+ logm(No Xen console device defined for host);
+}
+if (toolstack()-{Dom0MemFixed}) {
+$xenhopt .= dom0_mem=2048M,max:2048M;
+}
+my $append= $r{xen_boot_append};
+$xenhopt .= $append if defined $append;
+$append = get_host_property($ho, 'xen-commandline-append', undef);
+$xenhopt .= $append if defined $append;
+
+die pci-passthrough is not supported if
host_involves_pcipassthrough($ho);
+
+target_cmd_root($ho, END, 100);
+set -e
+cat ENDB /boot/loader.conf
+vfs.zfs.arc_max=1G
+xen_cmdline=$xenhopt
+xen_kernel=/boot/xen
+ENDB
+END
+
+logm(ready to boot Xen);
+}
+
+if ($checkmode) {
+extract();
+} else {
+die if @hos 1;
+$ho= $hos[0];
+
+packages();
+extract();
+adjustconfig();
+setupboot();
+}
--
1.9.3 (Apple Git-50)
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen: arm64: more useful logging on bad trap.
On Wed, Feb 18, 2015 at 11:00 AM, Julien Grall julien.gr...@linaro.org wrote: On 18/02/2015 15:47, Jintack Lim wrote: On Wed, Feb 18, 2015 at 10:19 AM, Ian Campbell ian.campb...@citrix.com wrote: Dump the register state before panicing so we have some clue where the issue occurred. Also decode the ESR register a bit to save having to grab a pen and paper. ESR_EL2 is a 32-bit register, so use SYSREG_READ32 not ..._READ64, as we already do correctly in the main trap handler. While here notice that do_trap_serror is never called and remove it. Signed-off-by: Ian Campbell ian.campb...@citrix.com Cc: jint...@cs.columbia.edu --- Jintack, since you have a system which is exhibiting SError issues I wonder if I could prevail on you to give this patch a try on your system and report on the output. I've only compile tested this myself. --- Hi Ian, Hi Jintack, Hi Julien, this is the output I got from the machine. OOI, what is the machine? It is a Seattle machine. Xen 4.5.0 (c/s Mon Jan 12 11:30:05 2015 -0500 git:a8ac229-dirty) EFI loader Using configuration file 'xen.cfg' vmlinuz-3.18.0+: 0x0083fbd8f000-0x0083fc5195c0 Xen 4.5.0 (XEN) Xen version 4.5.0 (jintack@) (gcc (Ubuntu/Linaro 4.8.2-19ubuntu1) 4.8.2) debug=n Wed Feb 18 5 (XEN) Latest ChangeSet: Mon Jan 12 11:30:05 2015 -0500 git:a8ac229-dirty You tree is marked dirty, did you made other changes than this patch? No. This patch is the only change. Basically, I checked out to RELEASE-4.5.0, and applied the patch there. (XEN) Processor: 410fd070: ARM Limited, variant: 0x0, part 0xd07, rev 0x0 (XEN) 64-bit Execution: (XEN) Processor Features: (XEN) Exception Levels: EL3:64+32 EL2:64+32 EL1:64+32 EL0:64+32 (XEN) Extensions: FloatingPoint AdvancedSIMD (XEN) Debug Features: 10305106 (XEN) Auxiliary Features: (XEN) Memory Model Features: 1124 (XEN) ISA Features: 00011120 (XEN) 32-bit Execution: (XEN) Processor Features: 0131:00011011 (XEN) Instruction Sets: AArch32 A32 Thumb Thumb-2 Jazelle (XEN) Extensions: GenericTimer Security (XEN) Debug Features: 03010066 (XEN) Auxiliary Features: (XEN) Memory Model Features: 10101105 4000 0126 02102211 (XEN) ISA Features: 02101110 13112111 21232042 01112131 00011142 00011121 (XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27 (XEN) Using generic timer at 187500 KHz (XEN) GICv2 initialization: (XEN) gic_dist_addr=e111 (XEN) gic_cpu_addr=e112f000 (XEN) gic_hyp_addr=e114 (XEN) gic_vcpu_addr=e116 (XEN) gic_maintenance_irq=24 (XEN) GICv2: 448 lines, 8 cpus, secure (IID 0200143b). (XEN) Using scheduler: SMP Credit Scheduler (credit) (XEN) Bad mode in Error handler detected, code 0xbf00, EC=2f, IL=1 ISS=100 (XEN) [ Xen-4.5.0 arm64 debug=n Not tainted ] (XEN) CPU:0 (XEN) PC: 002770f0 start_xen+0x920/0xc98 Can you try to get the line of code related to this PC? You could do it with addr2line. Please see below comments. [..] (XEN) Xen call trace: (XEN)[002770f0] start_xen+0x920/0xc98 (PC) (XEN)[002770e8] start_xen+0x918/0xc98 (LR) It might be good to get those 2 too. [jintack@seattle_2 ~/xen_4.5]$addr2line -C -f -e xen/xen-syms 0x002770f0 start_xen /home/jintack/xen_4.5/xen/arch/arm/setup.c:786 -- PC is iommu_setup() [jintack@seattle_2 ~/xen_4.5]$addr2line -C -f -e xen/xen-syms 0x002770e8 start_xen /home/jintack/xen_4.5/xen/arch/arm/setup.c:783 -- LR is local_irq_enable() It's a bit weird that PC is ahead of LR. Thanks, Jintack Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen: arm64: more useful logging on bad trap.
On Wed, Feb 18, 2015 at 11:01 AM, Ian Campbell ian.campb...@citrix.com wrote: On Wed, 2015-02-18 at 10:47 -0500, Jintack Lim wrote: On Wed, Feb 18, 2015 at 10:19 AM, Ian Campbell ian.campb...@citrix.com wrote: Dump the register state before panicing so we have some clue where the issue occurred. Also decode the ESR register a bit to save having to grab a pen and paper. ESR_EL2 is a 32-bit register, so use SYSREG_READ32 not ..._READ64, as we already do correctly in the main trap handler. While here notice that do_trap_serror is never called and remove it. Signed-off-by: Ian Campbell ian.campb...@citrix.com Cc: jint...@cs.columbia.edu --- Jintack, since you have a system which is exhibiting SError issues I wonder if I could prevail on you to give this patch a try on your system and report on the output. I've only compile tested this myself. --- Hi Ian, this is the output I got from the machine. Thanks, may I add a Tested-by: Jintack Lim jint...@cs.columbia.edu please? Yes!, Thanks. (XEN) Bad mode in Error handler detected, code 0xbf00, EC=2f, IL=1 ISS=100 I notice I missed a , here after IL=1, which I'll fix for v2. The line is also a bit long so I've split into two lines. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v4 11/11] osstest: add FreeBSD build recipe
This patch introduces two new buildjobs:
build-arch-freebsd-xen: sets up a FreeBSD host and builds Xen.
build-arch-freebsd-freebsd: sets up a FreeBSD host and builds FreeBSD sets
and a mfsBSD installer image.
Signed-off-by: Roger Pau Monné roger@citrix.com
Cc: Ian Jackson ian.jack...@eu.citrix.com
Cc: Ian Campbell ian.campb...@citrix.com
---
ap-common | 2 ++
mfi-common | 22 ++
sg-run-job | 25 +
3 files changed, 45 insertions(+), 4 deletions(-)
diff --git a/ap-common b/ap-common
index 96cbd14..8987637 100644
--- a/ap-common
+++ b/ap-common
@@ -27,6 +27,8 @@
#: ${TREE_QEMU:=git://mariner.uk.xensource.com/qemu-$xenbranch.git}
: ${TREE_QEMU:=git://xenbits.xen.org/staging/qemu-$xenbranch.git}
+: ${TREE_FREEBSD:=https://github.com/freebsd/freebsd.git}
+: ${TREE_MFSBSD:=https://github.com/mmatuska/mfsbsd.git}
: ${GIT_KERNEL_ORG:=git://git.kernel.org}
: ${KERNEL_SCM:=${GIT_KERNEL_ORG}/pub/scm/linux/kernel/git}
diff --git a/mfi-common b/mfi-common
index e167606..636052e 100644
--- a/mfi-common
+++ b/mfi-common
@@ -153,6 +153,28 @@ create_build_jobs () {
revision_qemuu=$REVISION_QEMU_UPSTREAM \
revision_seabios=$REVISION_SEABIOS
+./cs-job-create $flight build-$arch-freebsd-freebsd build-freebsd\
+arch=$arch \
+tree_freebsd=$TREE_FREEBSD \
+tree_mfsbsd=$TREE_MFSBSD \
+$RUNVARS $BUILD_RUNVARS $arch_runvars\
+host_hostflags=$build_hostflags \
+revision_freebsd=$REVISION_FREEBSD \
+revision_mfsbsd=$REVISION_MFSBSD
+
+./cs-job-create $flight build-$arch-freebsd-xen build\
+arch=$arch enable_xend=false enable_ovmf=false \
+tree_qemu=$TREE_QEMU \
+tree_qemuu=$TREE_QEMU_UPSTREAM \
+tree_xen=$TREE_XEN \
+tree_seabios=$TREE_SEABIOS \
+$RUNVARS $BUILD_RUNVARS $BUILD_XEN_RUNVARS $arch_runvars \
+host_hostflags=$build_hostflags \
+revision_xen=$REVISION_XEN \
+revision_qemu=$REVISION_QEMU \
+revision_qemuu=$REVISION_QEMU_UPSTREAM \
+revision_seabios=$REVISION_SEABIOS
+
if [ $build_extraxend = true ] ; then
./cs-job-create $flight build-$arch-xend build \
arch=$arch enable_xend=true enable_ovmf=$enable_ovmf \
diff --git a/sg-run-job b/sg-run-job
index 2cf810a..d8d75ba 100755
--- a/sg-run-job
+++ b/sg-run-job
@@ -50,8 +50,13 @@ proc run-job {job} {
if {$ok} { setstatus running }
-per-host-ts broken host-install/@(*) ts-host-install-twice
-per-host-ts . xen-install/@ ts-xen-install
+if {[string match *freebsd* $job]} {
+per-host-ts broken host-install/@(*) ts-freebsd-host-install
+per-host-ts . xen-install/@ ts-xen-install-freebsd
+} else {
+per-host-ts broken host-install/@(*) ts-host-install-twice
+per-host-ts . xen-install/@ ts-xen-install
+}
per-host-ts . xen-boot/@ts-host-reboot
per-host-ts . =(*) {ts-leak-check basis}
@@ -327,6 +332,7 @@ proc need-hosts/build {} { return BUILD }
proc need-hosts/build-kern {} { return BUILD }
proc need-hosts/build-libvirt {} { return BUILD }
proc need-hosts/build-rumpuserxen {} { return BUILD }
+proc need-hosts/build-freebsd {} { return BUILD }
proc run-job/build {} {
run-ts . = ts-xen-build
@@ -345,11 +351,22 @@ proc run-job/build-rumpuserxen {} {
run-ts . = ts-xen-build + host tools
}
+proc run-job/build-freebsd {} {
+run-ts . = ts-freebsd-create-mfsbsd
+}
+
proc prepare-build-host {} {
global jobinfo
run-ts broken = ts-hosts-allocate + host
-run-ts broken host-install(*) ts-host-install-twice
-run-ts . host-build-prep ts-xen-build-prep
+if {[string match *freebsd-xen* $jobinfo(job)]} {
+run-ts broken host-install(*) ts-freebsd-host-install
+run-ts . host-build-prep ts-xen-build-prep-freebsd
+} elseif {[string match *freebsd-freebsd* $jobinfo(job)]} {
+run-ts broken host-install(*) ts-freebsd-host-install
+} else {
+run-ts broken host-install(*) ts-host-install-twice
+run-ts . host-build-prep ts-xen-build-prep
+}
}
#-- main program
Re: [Xen-devel] [PATCH 13/13] xen: allow more than 512 GB of RAM for 64 bit pv-domains
On 18/02/15 11:51, Juergen Gross wrote: People using crash analysis tools that need the 3-level p2m can clamp dom0 memory with the Xen command line option. FWIW, the tool we use doesn't need this. Interesting. Which tool are you using? https://github.com/xenserver/xen-crashdump-analyser It walks dom0 by locating the real pagetables from struct vcpu, so needs no p2m/m2p fiddling at all. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH OSSTEST] Debian: Add fdt chosen to boot script
Ian Campbell writes ([PATCH OSSTEST] Debian: Add fdt chosen to boot script): This causes u-boot to fill in the various fields in the chosen node (specifically the bootargs) which would otherwise not be done until the bootz command. Doing it manually means the following fdt print /chosen will print what is actually going to be used. This change means that instead of whatever /chosen/bootargs is embedded in the firmware FDT we end up printing what we will actually use. FWIW Acked-by: Ian Jackson ian.jack...@eu.citrix.com but really I mean that although I have no knowledge of what this does or why it is helpful beyond what you have written, I have no objection to the patch :-). Maybe this should be combined with Wei's XSM series ? Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH] x86: Adjust rdtsc inline assembly
Currently there are three related rdtsc macros, all of which are lowercase and
not obviously macros, which write by value to their parameters.
This is non-intuitive to program which, being contrary to C semantics for code
appearing to be a regular function call. It is also causes Coverity to
conclude that __udelay() has an infinite loop, as all of its loop conditions
are constant.
Two of these macros (rdtsc() and rdtscl()) have only a handful of uses while
the vast majority of code uses the rdtscll() variant. rdtsc() and rdtscll()
are equivalent, while rdtscl() discards the high word.
Replace all 3 macros with a static inline which returns the complete tsc.
Most of this patch is a mechanical change of
- rdtscll($FOO);
+ $FOO = rdtsc();
And a diff of the generated assembly confirms that this is no change at all.
The single use of the old rdtsc() in emulate_privileged_op() is altered to use
the new rdtsc() and the rdmsr_writeback path to set eax/edx appropriately.
The pair of use of rdtscl() in __udelay() are extended to use full 64bit
values, which makes the overflow edge condition (and early exit from the loop)
far rarer.
Signed-off-by: Andrew Cooper andrew.coop...@citrix.com
CC: Keir Fraser k...@xen.org
CC: Jan Beulich jbeul...@suse.com
---
xen/arch/x86/apic.c |4 ++--
xen/arch/x86/cpu/mcheck/mce.c |2 +-
xen/arch/x86/delay.c |4 ++--
xen/arch/x86/hvm/hvm.c|4 ++--
xen/arch/x86/hvm/save.c |4 ++--
xen/arch/x86/hvm/svm/svm.c|2 +-
xen/arch/x86/platform_hypercall.c |4 ++--
xen/arch/x86/smpboot.c|2 +-
xen/arch/x86/time.c | 31 +++
xen/arch/x86/traps.c |5 -
xen/include/asm-x86/msr.h | 15 ++-
xen/include/asm-x86/time.h|4 +---
12 files changed, 39 insertions(+), 42 deletions(-)
diff --git a/xen/arch/x86/apic.c b/xen/arch/x86/apic.c
index 39cd9e5..3217bdf 100644
--- a/xen/arch/x86/apic.c
+++ b/xen/arch/x86/apic.c
@@ -1148,7 +1148,7 @@ static int __init calibrate_APIC_clock(void)
* We wrapped around just now. Let's start:
*/
if (cpu_has_tsc)
-rdtscll(t1);
+t1 = rdtsc();
tt1 = apic_read(APIC_TMCCT);
/*
@@ -1159,7 +1159,7 @@ static int __init calibrate_APIC_clock(void)
tt2 = apic_read(APIC_TMCCT);
if (cpu_has_tsc)
-rdtscll(t2);
+t2 = rdtsc();
/*
* The APIC bus clock counter is 32 bits only, it
diff --git a/xen/arch/x86/cpu/mcheck/mce.c b/xen/arch/x86/cpu/mcheck/mce.c
index 05a86fb..3a3b4dc 100644
--- a/xen/arch/x86/cpu/mcheck/mce.c
+++ b/xen/arch/x86/cpu/mcheck/mce.c
@@ -235,7 +235,7 @@ static void mca_init_bank(enum mca_source who,
if (who == MCA_CMCI_HANDLER) {
mib-mc_ctrl2 = mca_rdmsr(MSR_IA32_MC0_CTL2 + bank);
-rdtscll(mib-mc_tsc);
+mib-mc_tsc = rdtsc();
}
}
diff --git a/xen/arch/x86/delay.c b/xen/arch/x86/delay.c
index bc1772e..ef6bc5d 100644
--- a/xen/arch/x86/delay.c
+++ b/xen/arch/x86/delay.c
@@ -21,10 +21,10 @@ void __udelay(unsigned long usecs)
unsigned long ticks = usecs * (cpu_khz / 1000);
unsigned long s, e;
-rdtscl(s);
+s = rdtsc();
do
{
rep_nop();
-rdtscl(e);
+e = rdtsc();
} while ((e-s) ticks);
}
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index a52c6e0..72e383f 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -292,7 +292,7 @@ void hvm_set_guest_tsc_fixed(struct vcpu *v, u64 guest_tsc,
u64 at_tsc)
}
else
{
-rdtscll(tsc);
+tsc = rdtsc();
}
delta_tsc = guest_tsc - tsc;
@@ -326,7 +326,7 @@ u64 hvm_get_guest_tsc_fixed(struct vcpu *v, uint64_t at_tsc)
}
else
{
-rdtscll(tsc);
+tsc = rdtsc();
}
return tsc + v-arch.hvm_vcpu.cache_tsc_offset;
diff --git a/xen/arch/x86/hvm/save.c b/xen/arch/x86/hvm/save.c
index 6af19be..61f780d 100644
--- a/xen/arch/x86/hvm/save.c
+++ b/xen/arch/x86/hvm/save.c
@@ -36,7 +36,7 @@ void arch_hvm_save(struct domain *d, struct hvm_save_header
*hdr)
hdr-gtsc_khz = d-arch.tsc_khz;
/* Time when saving started */
-rdtscll(d-arch.hvm_domain.sync_tsc);
+d-arch.hvm_domain.sync_tsc = rdtsc();
}
int arch_hvm_load(struct domain *d, struct hvm_save_header *hdr)
@@ -71,7 +71,7 @@ int arch_hvm_load(struct domain *d, struct hvm_save_header
*hdr)
hvm_set_rdtsc_exiting(d, 1);
/* Time when restore started */
-rdtscll(d-arch.hvm_domain.sync_tsc);
+d-arch.hvm_domain.sync_tsc = rdtsc();
/* VGA state is not saved/restored, so we nobble the cache. */
d-arch.hvm_domain.stdvga.cache = 0;
diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index 018dd70..c83c483 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -805,7 +805,7 @@ static void svm_set_tsc_offset(struct vcpu *v,
Re: [Xen-devel] [PATCH 13/13] xen: allow more than 512 GB of RAM for 64 bit pv-domains
On 02/18/2015 12:18 PM, David Vrabel wrote: On 18/02/15 06:52, Juergen Gross wrote: +if X86_64 +choice + prompt Support pv-domains larger than 512GB + default XEN_512GB_NONE + help + Support paravirtualized domains with more than 512GB of RAM. + + The Xen tools and crash dump analysis tools might not support + pv-domains with more than 512 GB of RAM. This option controls the + default setting of the kernel to use only up to 512 GB or more. + It is always possible to change the default via specifying the + boot parameter xen_512gb_limit. + + config XEN_512GB_NONE + bool neither dom0 nor domUs can be larger than 512GB + config XEN_512GB_DOM0 + bool dom0 can be larger than 512GB, domUs not + config XEN_512GB_DOMU + bool domUs can be larger than 512GB, dom0 not + config XEN_512GB_ALL + bool dom0 and domUs can be larger than 512GB +endchoice +endif This configuration option doesn't look useful to me. Can we get rid of it with runtime checking. e.g., If dom0, enable 512G. If domU, enable 512G if requested by command line option /or/ toolstack indicates that it supports the linear p2m. How is the toolstack supposed to indicate this? I'd be more than happy to get rid of that option. For Dom0 you seem to have changed your mind (you rejected enabling 512GB as default last year). Doing some more tests I found the command line option is problematic: The option seems to be evaluated only after it is needed (I did the first tests using the config option). Can we get rid of the option even for domU? Or do I have to pre-scan the command line for the option? And If max_pfn 512G, populate 3-level p2m /unless/ toolstack indicates it supports the linear p2m. What about Dom0? People using crash analysis tools that need the 3-level p2m can clamp dom0 memory with the Xen command line option. FWIW, the tool we use doesn't need this. Interesting. Which tool are you using? Juergen ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH OSSTEST] Debian: Add fdt chosen to boot script
On Wed, 2015-02-18 at 11:56 +, Ian Jackson wrote: Ian Campbell writes ([PATCH OSSTEST] Debian: Add fdt chosen to boot script): This causes u-boot to fill in the various fields in the chosen node (specifically the bootargs) which would otherwise not be done until the bootz command. Doing it manually means the following fdt print /chosen will print what is actually going to be used. This change means that instead of whatever /chosen/bootargs is embedded in the firmware FDT we end up printing what we will actually use. FWIW Acked-by: Ian Jackson ian.jack...@eu.citrix.com but really I mean that although I have no knowledge of what this does or why it is helpful beyond what you have written, I have no objection to the patch :-). ;-) Would you like me to try and clarify or do you not really care? Maybe this should be combined with Wei's XSM series ? That's as good a place as any. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 0/2] arm/arm64: Detect Xen support earlier
On 18/02/2015 12:03, Ian Campbell wrote: On Wed, 2015-02-18 at 11:51 +, Julien Grall wrote: Hi Ian, On 18/02/2015 11:30, Ian Campbell wrote: On Thu, 2015-02-12 at 06:34 +, Julien Grall wrote: Hello, This small patch series move the detection of running on Xen earlier. This is required in order to support earlyprintk via Xen and selecting the preferred console. Thanks for doing this, having all of the init done in an initcall (even a relatively early one) has been a niggle I've wanted address for ages, for exactly earlyprintk and preferred console reasons. I had a very minor comment on #1 but nonetheless both patches: Acked-by: Ian Campbell ian.campb...@citrix.com Can I keep you ack on the first one with the __read_mostly dropped? Sure. BTW, when reposting you might want to CC the arch/arm* maintainers on this intro mail as well as just the second patch. Ok. I wasn't sure if this patches should go via the Xen tree or ARM one. -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 0/3] Add ThunderX platform support
From: Vijaya Kumar K vijaya.ku...@caviumnetworks.com Changes in v2: - Updated patch 3 commit message - Updated processor_implementers[] with implementor info in xen/arch/arm/setup.c Changes in v1: - Add support for ThunderX platform - Add early printk support - Add psci-0.2 check while parsing dt node Vijaya Kumar K (3): xen/arm: Add ThunderX platform support xen/arm: Add early printk support for ThunderX platform xen/arm: Skip parsing psci-0.2 from host device tree xen/arch/arm/Rules.mk |4 +++ xen/arch/arm/domain_build.c |1 + xen/arch/arm/platforms/Makefile |1 + xen/arch/arm/platforms/thunderx.c | 66 + xen/arch/arm/setup.c |1 + 5 files changed, 73 insertions(+) create mode 100644 xen/arch/arm/platforms/thunderx.c -- 1.7.9.5 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
