Re: [Xen-devel] [PATCH 2/5] allow domain heap allocations to specify more than one NUMA node
On 02.03.15 at 18:12, ian.campb...@citrix.com wrote: On Thu, 2015-02-26 at 13:53 +, Jan Beulich wrote: ... using struct domain as a container for passing the respective affinity mask: Quite a number of allocations are domain specific, yet not to be accounted for that domain. Introduce a flag suppressing the accounting altogether (i.e. going beyond MEMF_no_refcount) and use it right away in common code (x86 and IOMMU code will get adjusted subsequently). Signed-off-by: Jan Beulich jbeul...@suse.com Acked-by: Ian Campbell ian.campb...@citrix.com Thanks. Does this patch constitute all the not just(x86) from the initial mail? I'll assume so unless I hear otherwise. No, this part of patch 1 Note that this gives meaning to MEMF_exact_node specified alone (i.e. implicitly combined with NUMA_NO_NODE): In such a case any node inside the domain's node mask is acceptable, but no other node. This changed behavior is (implicitly) being exposed through the memop hypercalls. does too. (Patches 4 and 5 are only indirectly x86-specific, as the IOMMU code touched there is used on x86 only. But that's of no concern to you anyway.) Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v10 4/4] tools, docs: add total/local memory bandwith monitoring
On Mon, Mar 02, 2015 at 01:48:43PM +, Ian Campbell wrote:
On Thu, 2015-02-26 at 16:45 +0800, Chao Peng wrote:
Add Memory Bandwidth Monitoring(MBM) for VMs. Two types of monitoring
are supported: total and local memory bandwidth monitoring. To use it,
CMT should be enabled in hypervisor.
Signed-off-by: Chao Peng chao.p.p...@linux.intel.com
This looks good. I have one question and one small comment/idea:
[...]
diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 09d819f..54043ee 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -2688,6 +2688,8 @@ int xc_resource_op(xc_interface *xch, uint32_t
nr_ops, xc_resource_op_t *ops);
#if defined(__i386__) || defined(__x86_64__)
enum xc_psr_cmt_type {
XC_PSR_CMT_L3_OCCUPANCY,
+XC_PSR_CMT_TOTAL_MEM_BANDWIDTH,
+XC_PSR_CMT_LOCAL_MEM_BANDWIDTH,
Is bandwidth still the correct term here (and more importantly in the
libxl interface e.g. enum), given that we now do the sampling at the
application level and just expose the current count from Xen via libxl?
I feel comfortable either changing it or not. The reason to change it is
what you said here that we do return the counter value to the caller, so
a consistent name would be nice. While the reason to keep it is: the
names are listed as the monitoring event type from spec, so the caller
perhaps knows that the returned data is the sample value from event
counter register related to that type.
Anyway, if you feel it's better to change, then I will do.
I'm not sure what I better term would be though. count?
The returned value is actually read from monitor event counter, so
count you suggested or sample both sound OK to me, e.g.:
XC_PSR_CMT_TOTAL_MEM_BANDWIDTH = XC_PSR_CMT_TOTAL_MEM_BANDWIDTH_COUNT
XC_PSR_CMT_LOCAL_MEM_BANDWIDTH = XC_PSR_CMT_LOCAL_MEM_BANDWIDTH_COUNT
@@ -167,6 +194,16 @@ int xc_psr_cmt_get_data(xc_interface *xch, uint32_t
rmid, uint32_t cpu,
entries[nr].rsvd = 0;
nr++;
+if ( tsc != NULL )
+{
+tsc_entry = entries[nr];
+entries[nr].u.cmd = XEN_RESOURCE_OP_MSR_READ;
+entries[nr].idx = MSR_IA32_TSC;
+entries[nr].val = 0;
+entries[nr].rsvd = 0;
+nr++;
+}
Perhaps consider an assertion here that nr = the number of elements in
the array (i.e. ARRAY_SIZE(entries))? (Either added here or in the patch
which switched to using nr++)
Agreed. Given that patch (switched to using nr++) is aleady in, so will
add it here.
Chao
___
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 17/18] x86/efi: create new early memory allocator
On 02.03.15 at 21:25, roy.fr...@linaro.org wrote:
On Mon, Mar 2, 2015 at 9:23 AM, Jan Beulich jbeul...@suse.com wrote:
On 30.01.15 at 18:54, daniel.ki...@oracle.com wrote:
@@ -192,12 +218,7 @@ static void __init
efi_arch_process_memory_map(EFI_SYSTEM_TABLE *SystemTable,
static void *__init efi_arch_allocate_mmap_buffer(UINTN *map_size)
{
-place_string(mbi.mem_upper, NULL);
-mbi.mem_upper -= *map_size;
-mbi.mem_upper = -__alignof__(EFI_MEMORY_DESCRIPTOR);
-if ( mbi.mem_upper xen_phys_start )
-return NULL;
-return (void *)(long)mbi.mem_upper;
+return __malloc(*map_size);
}
Which then even suggests that _if_ we go this route, this could be
shared with ARM (and hence become common code again).
We could do the same thing on ARM. For ARM, 2 allocations are done: 1
for the FDT, and
this one for the EFI memory map. Both of these are currently
allocated with EFI allocation
functions, so don't have fixed size limits. If we go with the fixed
size pool, I don't think that 64k
will be enough for the ARM case, as FDTs can be 20-50k in size.
The 64k size here is to be debated anyway I think. We currently have
about 1Mb in the x86 variant, and I'd much rather see the pool be
this size initially, properly taking care of releasing to the allocator any
unused portions of it.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v5] modify the IO_TLB_SEGSIZE and IO_TLB_DEFAULT_SIZE configurable as flexible requirement about SW-IOMMU.
The maximum of SW-IOMMU is limited to 2^11*128 = 256K.
And the size of IO_TLB_DEFAULT_SIZE is limited to (64UL20) 64M now.
While in different platform and different requirement this seems improper.
So modifing the IO_TLB_SEGSIZE to io_tlb_segsize and IO_TLB_DEFAULT_SIZE
to io_tlb_default_size which can configure by kernel cmdline.
This can meet different requirement.
Signed-off-by: Chuansheng Liu chuansheng@intel.com
Signed-off-by: Zhang Dongxing dongxing.zh...@intel.com
Signed-off-by: Wang Xiaoming xiaoming.w...@intel.com
---
patch v1 make this change at Kconfig
which needs to edit the .config manually.
https://lkml.org/lkml/2015/1/25/571
patch v2 only change IO_TLB_SEGSIZE configurable.
https://lkml.org/lkml/2015/2/5/812
patch v3 parsing io_tlb_segsize and
io_tlb_default_size independently.
https://lkml.org/lkml/2015/2/15/217
patch v4 hasn't validated the data from
command line.
https://lkml.org/lkml/2015/2/17/114
Documentation/kernel-parameters.txt |9 -
arch/mips/cavium-octeon/dma-octeon.c |2 +-
arch/mips/netlogic/common/nlm-dma.c |2 +-
drivers/xen/swiotlb-xen.c|6 +--
include/linux/swiotlb.h |8 +---
lib/swiotlb.c| 68 +-
6 files changed, 65 insertions(+), 30 deletions(-)
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index 4df73da..1f50e86 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -3438,10 +3438,17 @@ 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.
+ Using , to separate them one by one.
+ Example:
+ BOARD_KERNEL_CMDLINE +=
swiotlb=32768,force,512,268435456
+ io_tlb_nslabs=32768, swiotlb_force=1,
+ io_tlb_segsize=512, io_tlb_default_size=268435456
switches= [HW,M68k]
diff --git a/arch/mips/cavium-octeon/dma-octeon.c
b/arch/mips/cavium-octeon/dma-octeon.c
index 3778655..a521af6 100644
--- a/arch/mips/cavium-octeon/dma-octeon.c
+++ b/arch/mips/cavium-octeon/dma-octeon.c
@@ -312,7 +312,7 @@ void __init plat_swiotlb_setup(void)
swiotlbsize = 64 * (120);
#endif
swiotlb_nslabs = swiotlbsize IO_TLB_SHIFT;
- swiotlb_nslabs = ALIGN(swiotlb_nslabs, IO_TLB_SEGSIZE);
+ swiotlb_nslabs = ALIGN(swiotlb_nslabs, io_tlb_segsize);
swiotlbsize = swiotlb_nslabs IO_TLB_SHIFT;
octeon_swiotlb = alloc_bootmem_low_pages(swiotlbsize);
diff --git a/arch/mips/netlogic/common/nlm-dma.c
b/arch/mips/netlogic/common/nlm-dma.c
index f3d4ae8..eeffa8f 100644
--- a/arch/mips/netlogic/common/nlm-dma.c
+++ b/arch/mips/netlogic/common/nlm-dma.c
@@ -99,7 +99,7 @@ void __init plat_swiotlb_setup(void)
swiotlbsize = 1 20; /* 1 MB for now */
swiotlb_nslabs = swiotlbsize IO_TLB_SHIFT;
- swiotlb_nslabs = ALIGN(swiotlb_nslabs, IO_TLB_SEGSIZE);
+ swiotlb_nslabs = ALIGN(swiotlb_nslabs, io_tlb_segsize);
swiotlbsize = swiotlb_nslabs IO_TLB_SHIFT;
nlm_swiotlb = alloc_bootmem_low_pages(swiotlbsize);
diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index 810ad41..3b3e9fe 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -164,11 +164,11 @@ xen_swiotlb_fixup(void *buf, size_t size, unsigned long
nslabs)
dma_addr_t dma_handle;
phys_addr_t p = virt_to_phys(buf);
- dma_bits = get_order(IO_TLB_SEGSIZE IO_TLB_SHIFT) + PAGE_SHIFT;
+ dma_bits = get_order(io_tlb_segsize IO_TLB_SHIFT) + PAGE_SHIFT;
i = 0;
do {
- int slabs = min(nslabs - i, (unsigned long)IO_TLB_SEGSIZE);
+ int slabs = min(nslabs - i, (unsigned long)io_tlb_segsize);
do {
rc = xen_create_contiguous_region(
@@ -187,7 +187,7 @@ static unsigned long xen_set_nslabs(unsigned long nr_tbl)
{
if (!nr_tbl) {
xen_io_tlb_nslabs = (64 * 1024 * 1024 IO_TLB_SHIFT);
- xen_io_tlb_nslabs = ALIGN(xen_io_tlb_nslabs, IO_TLB_SEGSIZE);
+ xen_io_tlb_nslabs = ALIGN(xen_io_tlb_nslabs, io_tlb_segsize);
} else
xen_io_tlb_nslabs = nr_tbl;
diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h
index e7a018e..13506db 100644
---
Re: [Xen-devel] [PATCH v2] sched: credit2: respect per-vcpu hard affinity
On 03.03.15 at 04:15, dario.faggi...@citrix.com wrote:
On Sun, 2015-02-08 at 17:45 -1000, Justin T. Weaver wrote:
--- a/xen/common/sched_credit2.c
+++ b/xen/common/sched_credit2.c
@@ -194,6 +194,12 @@ int opt_overload_balance_tolerance=-3;
integer_param(credit2_balance_over, opt_overload_balance_tolerance);
/*
+ * Use this to avoid having too many cpumask_t structs on the stack
+ */
+static cpumask_t **cpumask = NULL;
Not just 'cpumask', please... It's too generic a name. Let's pick up
something that makes it easier to understand what's the purpose of this.
I'm not really sure right now what something like that could be...
Credit has balance_mask, but we're not going as far as introducing
multiple step load balancing here (not with this patch, at least).
Maybe affinity_cpumask, or hard_affinity_cpumask (and we'll rename to
something else when introducing soft affinity, if needed).
+#define csched2_cpumask cpumask[smp_processor_id()]
+
I like the idea, but put the right side between parentheses.
Parentheses? Why? There's no operator with higher precedence
than postfix ones.
Of course,
what just said about the name applies here too. :-)
Right. Suitably done, variable and macro can actually share names.
+static int get_safe_pcpu(struct csched2_vcpu *svc)
+{
I also don't like the name... __choose_cpu() maybe ?
Why is everyone liking these double underscore prefixed names so
much? They're in conflict with the library name space and hence
should be avoided. Single underscore prefixed names (and the
underscore not followed by an upper case letter) is what the
standard sets aside for file scope (i.e. static) identifiers.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] freemem-slack and large memory environments
On Mon, 2015-03-02 at 15:49 -0700, Mike Latimer wrote: On Monday, March 02, 2015 04:15:41 PM Stefano Stabellini wrote: On Mon, 2 Mar 2015, Ian Campbell wrote: ? Continue as long as progress is being made is exactly what 2563bca1154 libxl: Wait for ballooning if free memory is increasing was trying to implement, so it certainly was the idea behind the current implementation (it may well not have managed to implement the idea it was trying to). I don't think so: pre-2563bca1154 it wasn't and 2563bca1154 doesn't implement it properly. I think we should revert it. I agree. The intent was there, but we are not aware of any known problem cases that the changes will effect. Reverting seems like the right thing to do. I agree with the suggestion continue as long as progress is being made. I disagree that continue as long as progress is being made is the current logic of freemem. I don't have an opinion on whether that logic should be implemented in freemem or libxl_wait_for_memory_target. The code below implements it in libxl_wait_for_memory_target. Seems like it should wait in libxl_wait_for_memory_target, as you have implemented. Please can someone submit a series with the revert and the change to libxl_wait_for_memory_tareget in which ever order makes sense. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/2] xen: arm: log warning for interrupt configuration mismatch
Hi Ian, On 02/03/2015 17:01, Ian Campbell wrote: On Mon, 2015-03-02 at 12:56 +, Julien Grall wrote: From 852f6e3fe49f7fab801f2857b8b505922556d746 Mon Sep 17 00:00:00 2001 From: Ian Campbell ian.campb...@citrix.com Date: Mon, 2 Mar 2015 11:09:35 + Subject: [PATCH] xen: arm: Assume level triggered means high, not low. When reading back the ICFG register we cannot know the polarity of the configuration, just that it is level or edge. Since falling edge and low level are invalid for SPIs we should assume rising edge and high level (we have no better information for PPIs, so it'll have to do). We already assumed rising edge, switch to high level as well. Signed-off-by: Ian Campbell ian.campb...@citrix.com Given the usage of desc-arch.type in Xen, I think this is the right solution: Reviewed-by: Julien Grall julien.gr...@linaro.org Applied, thanks. With your don't warn if high-level patch[*] is that all of the fallout from this series, other than making desc-arch.type just track level vs edge without polarity? Yes. Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5] xen/iommu: smmu: Advertise when the SMMU support coherent table walk
On 02/03/2015 17:04, Ian Campbell wrote: On Mon, 2015-03-02 at 15:42 +, Julien Grall wrote: I've just noticed that the support on the previous driver (i.e in Xen 4.5) may incorrectly expose this feature when all the SMMUs is not supporting coherent table walk. I'm not sure, if I should send a patch for it. Probably not a lot of point given the dearth of hardware where it would actually matter? IGiven there is a lake of PCI support in the SMMU for Xen 4.5, I guess we can consider the driver not usable in new hardware. Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RFC] xen: arm: context switch vtimer PPI state.
On Tue, 2015-03-03 at 12:18 +, Ian Campbell wrote:
+/* Xen s/w state */
+unsigned long inprogress:1;
+};
Using a uint32_t bitmask would be more in line the rest of the code
style, but it is just a matter of taste.
You mean uint32_t inprogress:1 for each? Or
#define ENAVBLED 1
#define PENDING 2
etc
and test_set_bit stuff?
Something like status in xen/include/asm-arm/vgic.h:struct pending_irq
OK.
Actually, what is the benefit? I think pending_irq.status is done this
way because it is used lock free from multiple contexts and this allows
for test_and_set_bit etc to be used.
The hwppi state isn't accessed like that, so I think using the normal
appropriate types like we do in stuct arch_{domain,vcpu} is the
appropriate style. struct hwppi_state is even defined in domain.h.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 00/18] x86: multiboot2 protocol support
On Tue, Mar 03, 2015 at 12:10:35PM +, Ian Campbell wrote: On Fri, 2015-01-30 at 18:54 +0100, Daniel Kiper wrote: xen/arch/x86/Makefile | 17 ++-- xen/arch/x86/boot/Makefile|3 +- xen/arch/x86/boot/head.S | 291 ++ xen/arch/x86/boot/reloc.c | 219 ++--- xen/arch/x86/dmi_scan.c |4 +- xen/arch/x86/domain_page.c|2 +- xen/arch/x86/e820.c | 29 ++ xen/arch/x86/efi/Makefile | 12 +-- xen/arch/x86/efi/efi-boot.h | 66 +++-- xen/arch/x86/efi/stub.c | 41 xen/arch/x86/mpparse.c|4 +- xen/arch/x86/setup.c | 30 +++--- xen/arch/x86/shutdown.c |3 +- xen/arch/x86/time.c |2 +- xen/arch/x86/x86_64/asm-offsets.c |8 ++ xen/arch/x86/xen.lds.S|2 - xen/common/efi/boot.c | 441 +- xen/common/efi/runtime.c | 11 ++- xen/drivers/acpi/osl.c|2 +- xen/include/xen/efi.h |6 +- xen/include/xen/multiboot2.h | 169 21 files changed, 1018 insertions(+), 344 deletions(-) From the diffstat I'm not sure: is there any ARM impact I should worry about reviewing? Any patches in particular my feedback is needed on? There are not any functional changes in ARM here. There are some small changes which are needed to make new x86 stuff coexist with ARM. Additionally, I thought that you are still interested in x86 things. Am I right? If you do not have a time right now ignore this patch series. New thing will appear in 3-4 weeks. Or if you completely not interested in that stuff just drop me a line and I will drop you from distribution list. Daniel ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 00/18] x86: multiboot2 protocol support
On Tue, 2015-03-03 at 13:36 +0100, Daniel Kiper wrote: On Tue, Mar 03, 2015 at 12:10:35PM +, Ian Campbell wrote: On Fri, 2015-01-30 at 18:54 +0100, Daniel Kiper wrote: xen/arch/x86/Makefile | 17 ++-- xen/arch/x86/boot/Makefile|3 +- xen/arch/x86/boot/head.S | 291 ++ xen/arch/x86/boot/reloc.c | 219 ++--- xen/arch/x86/dmi_scan.c |4 +- xen/arch/x86/domain_page.c|2 +- xen/arch/x86/e820.c | 29 ++ xen/arch/x86/efi/Makefile | 12 +-- xen/arch/x86/efi/efi-boot.h | 66 +++-- xen/arch/x86/efi/stub.c | 41 xen/arch/x86/mpparse.c|4 +- xen/arch/x86/setup.c | 30 +++--- xen/arch/x86/shutdown.c |3 +- xen/arch/x86/time.c |2 +- xen/arch/x86/x86_64/asm-offsets.c |8 ++ xen/arch/x86/xen.lds.S|2 - xen/common/efi/boot.c | 441 +- xen/common/efi/runtime.c | 11 ++- xen/drivers/acpi/osl.c|2 +- xen/include/xen/efi.h |6 +- xen/include/xen/multiboot2.h | 169 21 files changed, 1018 insertions(+), 344 deletions(-) From the diffstat I'm not sure: is there any ARM impact I should worry about reviewing? Any patches in particular my feedback is needed on? There are not any functional changes in ARM here. There are some small changes which are needed to make new x86 stuff coexist with ARM. Additionally, I thought that you are still interested in x86 things. Not totally disinterested in x86 things, but not especially interested in x86/EFI/multiboot unless I have to be. Am I right? If you do not have a time right now ignore this patch series. New thing will appear in 3-4 weeks. OK, thanks. Or if you completely not interested in that stuff just drop me a line and I will drop you from distribution list. If you could just CC me on the bits which impact ARM (or generic code) that would be ok, but otherwise I can cope with ignoring irrelevant parts of a series. Thanks, Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH] xsm/policy: remove gawk-ism line in Makefile
Translate gawk regex to mawk regex to allow using mawk. The new regex
works on both gawk and mawk.
Signed-off-by: Wei Liu wei.l...@citrix.com
Cc: Ian Campbell ian.campb...@citrix.com
Cc: Ian Jackson ian.jack...@eu.citrix.com
Cc: Daniel De Graaf dgde...@tycho.nsa.gov
---
tools/flask/policy/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/flask/policy/Makefile b/tools/flask/policy/Makefile
index 54a845b..58d9ce1 100644
--- a/tools/flask/policy/Makefile
+++ b/tools/flask/policy/Makefile
@@ -86,7 +86,7 @@ DETECTED_MODS := $(sort $(foreach
dir,$(ALL_LAYERS),$(wildcard $(dir)/*.te)))
MODENABLED := on
# extract settings from modules.conf
-ENABLED_MODS := $(foreach mod,$(shell awk '/^[[:blank:]]*[[:alpha:]]/{ if ($$3
== $(MODENABLED)) print $$1 }' $(MOD_CONF) 2 /dev/null),$(subst ./,,$(shell
find -iname $(mod).te)))
+ENABLED_MODS := $(foreach mod,$(shell awk '/^[ \t]*[a-z]/{ if ($$3 ==
$(MODENABLED)) print $$1 }' $(MOD_CONF) 2 /dev/null),$(subst ./,,$(shell
find -iname $(mod).te)))
ALL_MODULES := $(filter $(ENABLED_MODS),$(DETECTED_MODS))
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [xen-unstable test] 35257: regressions - FAIL
On Thu, 2015-02-26 at 20:14 +, xen.org wrote:
flight 35257 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/35257/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt 12 guest-start.2 fail REGR. vs.
34629
libvirt is unreliable right now, Ian already added to allow.all:
@@-libvirt@@ guest-start
Ian is going to push a change to the allow file to make at least libvirt
guest-state.* and guest-destroy allowable fails but in the meantime:
[...]
version targeted for testing:
xen 24b2b8dea180098a3acc809a91cde6c0cc4c8607
I have force pushed this revision.
Ian.
osstest@osstest:~/branches/for-xen-unstable.git$
OSSTEST_CONFIG=production-config ./ap-push
24b2b8dea180098a3acc809a91cde6c0cc4c8607
+ branch=24b2b8dea180098a3acc809a91cde6c0cc4c8607
+ revision=
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{Repos} or die $!;
'
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push
24b2b8dea180098a3acc809a91cde6c0cc4c8607
+ branch=24b2b8dea180098a3acc809a91cde6c0cc4c8607
+ revision=
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{Repos} or die $!;
'
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock
']'
+ . cri-common
++ . cri-getconfig
++ umask 002
+ select_xenbranch
+ case $branch in
+ '[' x = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-
+ : tested/2.6.39.x
+ . ap-common
++ : osst...@xenbits.xensource.com
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xensource.com:/home/xen/git/xen.git
++ : git://xenbits.xen.org/staging/qemu-.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://libvirt.org/libvirt.git
++ : osst...@xenbits.xensource.com:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : https://github.com/rumpkernel/rumprun-xen
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
getconfig GitCacheProxy
perl -e '
use Osstest;
readglobalconfig();
print $c{GitCacheProxy} or die $!;
'
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo
'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ :
'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xensource.com:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osst...@xenbits.xensource.com:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osst...@xenbits.xensource.com:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' x = x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ '[' x = x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-arm-xen
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.24b2b8dea180098a3acc809a91cde6c0cc4c8607
++ : daily-cron.24b2b8dea180098a3acc809a91cde6c0cc4c8607
++ : daily-cron.24b2b8dea180098a3acc809a91cde6c0cc4c8607
++ : daily-cron.24b2b8dea180098a3acc809a91cde6c0cc4c8607
++ : daily-cron.24b2b8dea180098a3acc809a91cde6c0cc4c8607
++ : daily-cron.24b2b8dea180098a3acc809a91cde6c0cc4c8607
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-.git
++ : daily-cron.24b2b8dea180098a3acc809a91cde6c0cc4c8607
++ : git://git.qemu.org/qemu.git
++ :
Re: [Xen-devel] [xen-unstable test] 35257: regressions - FAIL
On Tue, 2015-03-03 at 12:44 +, Ian Campbell wrote:
On Thu, 2015-02-26 at 20:14 +, xen.org wrote:
version targeted for testing:
xen 24b2b8dea180098a3acc809a91cde6c0cc4c8607
I have force pushed this revision.
[...]
+ echo 'branch 24b2b8dea180098a3acc809a91cde6c0cc4c8607 ?'
branch 24b2b8dea180098a3acc809a91cde6c0cc4c8607 ?
+ exit 1
Ahem. Lets try that again.
osstest@osstest:~/branches/for-xen-unstable.git$
OSSTEST_CONFIG=production-config ./ap-push xen-unstable
24b2b8dea180098a3acc809a91cde6c0cc4c8607
+ branch=xen-unstable
+ revision=24b2b8dea180098a3acc809a91cde6c0cc4c8607
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{Repos} or die $!;
'
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable
24b2b8dea180098a3acc809a91cde6c0cc4c8607
+ branch=xen-unstable
+ revision=24b2b8dea180098a3acc809a91cde6c0cc4c8607
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{Repos} or die $!;
'
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock
']'
+ . cri-common
++ . cri-getconfig
++ umask 002
+ select_xenbranch
+ case $branch in
+ tree=xen
+ xenbranch=xen-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ : tested/2.6.39.x
+ . ap-common
++ : osst...@xenbits.xensource.com
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xensource.com:/home/xen/git/xen.git
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://libvirt.org/libvirt.git
++ : osst...@xenbits.xensource.com:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : https://github.com/rumpkernel/rumprun-xen
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
getconfig GitCacheProxy
perl -e '
use Osstest;
readglobalconfig();
print $c{GitCacheProxy} or die $!;
'
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo
'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ :
'git://drall.uk.xensource.com:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xensource.com:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xensource.com:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osst...@xenbits.xensource.com:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osst...@xenbits.xensource.com:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' x = x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ '[' x = x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-arm-xen
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-unstable
++ : daily-cron.xen-unstable
++ : daily-cron.xen-unstable
++ : daily-cron.xen-unstable
++ : daily-cron.xen-unstable
++ : daily-cron.xen-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
++ : git://git.qemu.org/qemu.git
++ : git://xenbits.xen.org/osstest/qemu.git
++ : osst...@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
++ : daily-cron.xen-unstable
+ TREE_LINUX=osst...@xenbits.xensource.com:/home/xen/git/linux-pvops.git
+
TREE_QEMU_MAINLINE=osst...@xenbits.xensource.com:/home/xen/git/osstest/qemu.git
+
TREE_QEMU_UPSTREAM=osst...@xenbits.xensource.com:/home/xen/git/qemu-upstream-unstable.git
+ TREE_XEN=osst...@xenbits.xensource.com:/home/xen/git/xen.git
+
Re: [Xen-devel] [PATCH v3 12/24] xen/arm: Release IRQ routed to a domain when it's destroying
Hi Ian, On 20/02/2015 17:41, Julien Grall wrote: +/* Only SPIs are supported */ +if ( virq 32 || virq = vgic_num_irqs(d) ) +return -EINVAL; + +p = irq_to_pending(d-vcpu[0], virq); +if ( !p-desc ) +return -EINVAL; Are we seeing this pattern a lot? It seems so, I wonder if a helper could be useful: p = spi_to_pending(d, virq); if ( !p-desc ) return -EINVAL; with the 32 check etc in the helper where it only needs commenting on once. IIRC, there is only 2 places. I will replace it by an helper. H I only found 1 place. So I will keep open-coding in the function. Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 00/18] x86: multiboot2 protocol support
On Tue, Mar 03, 2015 at 12:39:45PM +, Ian Campbell wrote: On Tue, 2015-03-03 at 13:36 +0100, Daniel Kiper wrote: On Tue, Mar 03, 2015 at 12:10:35PM +, Ian Campbell wrote: On Fri, 2015-01-30 at 18:54 +0100, Daniel Kiper wrote: xen/arch/x86/Makefile | 17 ++-- xen/arch/x86/boot/Makefile|3 +- xen/arch/x86/boot/head.S | 291 ++ xen/arch/x86/boot/reloc.c | 219 ++--- xen/arch/x86/dmi_scan.c |4 +- xen/arch/x86/domain_page.c|2 +- xen/arch/x86/e820.c | 29 ++ xen/arch/x86/efi/Makefile | 12 +-- xen/arch/x86/efi/efi-boot.h | 66 +++-- xen/arch/x86/efi/stub.c | 41 xen/arch/x86/mpparse.c|4 +- xen/arch/x86/setup.c | 30 +++--- xen/arch/x86/shutdown.c |3 +- xen/arch/x86/time.c |2 +- xen/arch/x86/x86_64/asm-offsets.c |8 ++ xen/arch/x86/xen.lds.S|2 - xen/common/efi/boot.c | 441 +- xen/common/efi/runtime.c | 11 ++- xen/drivers/acpi/osl.c|2 +- xen/include/xen/efi.h |6 +- xen/include/xen/multiboot2.h | 169 21 files changed, 1018 insertions(+), 344 deletions(-) From the diffstat I'm not sure: is there any ARM impact I should worry about reviewing? Any patches in particular my feedback is needed on? There are not any functional changes in ARM here. There are some small changes which are needed to make new x86 stuff coexist with ARM. Additionally, I thought that you are still interested in x86 things. Not totally disinterested in x86 things, but not especially interested in x86/EFI/multiboot unless I have to be. Roger. Am I right? If you do not have a time right now ignore this patch series. New thing will appear in 3-4 weeks. OK, thanks. Or if you completely not interested in that stuff just drop me a line and I will drop you from distribution list. If you could just CC me on the bits which impact ARM (or generic code) that would be ok, but otherwise I can cope with ignoring irrelevant parts of a series. Wilco. Daniel ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Regression due to d9581c7dcac15c02ad4d47c60c60f4d8f197db55 en/fb: allow xenfb initialization for hvm guest
I am afraid that Xend is still widespread enough that we need some way to
deal with it.
The #idef hackery - while not a nice way can make this work.
Or we can add this in an header/function as a quirk.
boolean xen_pvfb_dont_init_quirk(void)
{
#ifdef CONFIG_X86
I would be OK with having such a quirk without the ifdef (no xend has
been known to work on ARM anyway).
if (xen_running_on_version_or_later(4, 5) xen_hvm_domain())
Shouldn't this be xen_running_on_version_or_earlier(4, 4)?
Xend has been removed in 4.5.
This all sounds pretty gross, but if it is the way folks want to go,
shouldn't it try and determine that it is running on xend somehow
instead of guessing based on version number? 4.4 had xl in it too for
instance...
Right, so the secondary check would be to see if there is something
extra that Xend puts in the XenStore. And it looks to always
put 'protocol' in every device:
xm:
0 =
protocol = x86_32-abi
state = 1
backend-id = 0
backend = /local/domain/0/backend/vfb/7/0
While xl:
vfb =
0 =
backend = /local/domain/0/backend/vfb/1/0
backend-id = 0
state = 1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 2/5] libxc: Split off xc_minios_privcmd.c
On Mon, Mar 02, 2015 at 05:31:53PM +, Ian Campbell wrote: On Thu, 2015-02-26 at 11:56 +, Wei Liu wrote: From: Ian Jackson ian.jack...@eu.citrix.com We are going to want to use some but not all of the machinery previously in xc_minios.c. Split the privcmd and gnttab code into its own file. Does it make sense to put gnttab code in a file called privcmd.c? I don't think there is much of a link between the two, is there? I'm not sure which half of this rump libxc is going to want but perhaps either _common or _standalone would be a better suffix, depending which way it goes? I will name it xc_minios_common.c because the factored out code will be used by both mini-os and rump kernel. Wei. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xsm/policy: remove gawk-ism line in Makefile
On 03/03/2015 07:44 AM, Wei Liu wrote: Translate gawk regex to mawk regex to allow using mawk. The new regex works on both gawk and mawk. Signed-off-by: Wei Liu wei.l...@citrix.com Acked-by: Daniel De Graaf dgde...@tycho.nsa.gov ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v8 3/4] xen/arm: Make gic-v2 code handle hip04-d01 platform
On 03/03/15 15:36, Frediano Ziglio wrote: Hello Frediano, On 03/03/15 11:19, Frediano Ziglio wrote: The GIC in this platform is mainly compatible with the standard GICv2 beside: - ITARGET is extended to 16 bit to support 16 CPUs; - SGI mask is extended to support 16 CPUs; - maximum supported interrupt is 510; 510 is not a multiple of 32. Is it normal? This will result to having nr_lines = 512. What happen is we are trying to access IRQ 510 and 511? I don't know. I think it's the same reason why in xen/arch/arm/gic.c the limit for irq is 1021 and not 1024 (see if ( likely(irq = 16 irq 1021) ) line) IRQ 1021-1023 are reserved by the GIC as spurious interrupt. If I understand correctly what you say, IRQ 510-511 may be considered for spurious interrupt? If so, the check (irq = 16 irq 1021) needs to be changed. Also, is it possible to have GICH.VirtualID = 510? I think so, GICH have the same interface of normal GICv2. But some offsets are different... so I'd like a confirmation based on some spec. For instance on GICv2 if we use some VirtualID (1021-1023) the behavior is unpredictable. So if you have the a similar things on your board we may need to restrict the number of VirtualID in order to avoid introduce a possible host denial from a guest. [..] -DT_DEVICE_START(gicv2, GICv2, DEVICE_GIC) -.dt_match = gicv2_dt_match, -.init = gicv2_init, +DT_DEVICE_START(hip04gic, GIC-HIP04, DEVICE_GIC) +.dt_match = hip04gic_dt_match, +.init = hip04gic_init, DT_DEVICE_END Please keep the same indentation as before. I was wondering why the indentation is different. Ok I'm not sure why ... but it looks like we use the same indentation everywhere for DT_DEVICE_START. Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v9 4/4] xen/arm: Force dom0 to use normal GICv2 driver on Hip04 platform
Until vGIC support is not implemented and tested, this will prevent
guest kernels to use their Hip04 driver, or crash when they don't
have any.
Signed-off-by: Frediano Ziglio frediano.zig...@huawei.com
---
xen/arch/arm/gic-hip04.c | 18 +++---
xen/include/asm-arm/gic.h | 4 +++-
2 files changed, 14 insertions(+), 8 deletions(-)
diff --git a/xen/arch/arm/gic-hip04.c b/xen/arch/arm/gic-hip04.c
index 0fda957..073ad33 100644
--- a/xen/arch/arm/gic-hip04.c
+++ b/xen/arch/arm/gic-hip04.c
@@ -612,17 +612,21 @@ static int hip04gic_make_dt_node(const struct domain *d,
const struct dt_device_node *node, void *fdt)
{
const struct dt_device_node *gic = dt_interrupt_controller;
-const void *compatible = NULL;
+const void *compatible;
u32 len;
const __be32 *regs;
int res = 0;
-compatible = dt_get_property(gic, compatible, len);
-if ( !compatible )
-{
-dprintk(XENLOG_ERR, Can't find compatible property for the gic
node\n);
-return -FDT_ERR_XEN(ENOENT);
-}
+/*
+ * Replace compatibility string with a standard one.
+ * dom0 will see a compatible GIC. This as GICC is compatible
+ * with standard one and GICD (emulated by Xen) is compatible
+ * to standard. Otherwise we should implement HIP04 GICD in
+ * the virtual GIC.
+ * This actually limit CPU number to 8 for dom0.
+ */
+compatible = DT_COMPAT_GIC_CORTEX_A15;
+len = strlen((char*) compatible) + 1;
res = fdt_begin_node(fdt, interrupt-controller);
if ( res )
diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
index 6f5767f..89a9b6f 100644
--- a/xen/include/asm-arm/gic.h
+++ b/xen/include/asm-arm/gic.h
@@ -153,8 +153,10 @@
#include xen/irq.h
#include asm-arm/vgic.h
+#define DT_COMPAT_GIC_CORTEX_A15 arm,cortex-a15-gic
+
#define DT_MATCH_GIC_V2 \
-DT_MATCH_COMPATIBLE(arm,cortex-a15-gic), \
+DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_CORTEX_A15), \
DT_MATCH_COMPATIBLE(arm,cortex-a7-gic), \
DT_MATCH_COMPATIBLE(arm,gic-400)
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] kasan_map_early_shadow() on Xen
On 03/03/2015 05:16 PM, Konrad Rzeszutek Wilk wrote: On Tue, Mar 03, 2015 at 04:15:06PM +0300, Andrey Ryabinin wrote: On 03/03/2015 12:40 PM, Luis R. Rodriguez wrote: Andrey, I believe that on Xen we should disable kasan, would like confirmation I guess Xen guests won't work with kasan because Xen guests doesn't setup shadow (kasan_map_early_shadow() is not called in xen guests). Disabling kasan for Xen in Kconfig is undesirable because that will disable kasan for allmodconfig and allyesconfig builds, but I don't see other option for now. Was there an bug reported for this? It would be good to CC the maintainers of Xen on that sort of thing. There was no report for this. I just looked at Xen code because of this Luis's mail and I don't see how it could work with kasan. Fixing this might be not trivial. We need to setup shadow memory before any kasan instrumented function will run. This is like with -fstack-protector (you need to setup gdt before calling any stack protected function). ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 2/5] libxc: split off xc_minios_common.c
Rump kernel is going to use some but not all of the machinery previously
in xc_minios.c. Split the privcmd and gnttab code into its own file.
This part is pure code motion.
But we also have to:
- Alter the Makefile to build and link xc_minios_common.c too.
- Rename some of the minios_*_ops symbols to have proper namespaceing
and make them have external linkage, so that the init code (which
remains in xc_minios.c) can reference them.
- Call these *_ops symbols xc_*_ops so that we can mix and match in
the future. This does not impede the existing mechanisms for
run-time overriding. (But leave a comment next to the new
declarations in xc_private.h saying not to use these.)
- Change map_frames_ex to minios_map_frames_ex if compiling on rump
kernel.
Signed-off-by: Ian Jackson ian.jack...@eu.citrix.com
Signed-off-by: Wei Liu wei.l...@citrix.com
Acked-by: Samuel Thibault samuel.thiba...@ens-lyon.org
---
Changes in v2:
1. xc_minios_privcmd.c - xc_minios_common.c.
---
tools/libxc/Makefile | 2 +-
tools/libxc/xc_minios.c| 243 +-
tools/libxc/xc_minios_common.c | 291 +
tools/libxc/xc_private.h | 3 +
4 files changed, 299 insertions(+), 240 deletions(-)
create mode 100644 tools/libxc/xc_minios_common.c
diff --git a/tools/libxc/Makefile b/tools/libxc/Makefile
index 6fa88c7..3a0ff22 100644
--- a/tools/libxc/Makefile
+++ b/tools/libxc/Makefile
@@ -47,7 +47,7 @@ CTRL_SRCS-$(CONFIG_Linux) += xc_linux.c xc_linux_osdep.c
CTRL_SRCS-$(CONFIG_FreeBSD) += xc_freebsd.c xc_freebsd_osdep.c
CTRL_SRCS-$(CONFIG_SunOS) += xc_solaris.c
CTRL_SRCS-$(CONFIG_NetBSD) += xc_netbsd.c
-CTRL_SRCS-$(CONFIG_MiniOS) += xc_minios.c
+CTRL_SRCS-$(CONFIG_MiniOS) += xc_minios.c xc_minios_common.c
GUEST_SRCS-y :=
GUEST_SRCS-y += xg_private.c xc_suspend.c
diff --git a/tools/libxc/xc_minios.c b/tools/libxc/xc_minios.c
index e703684..90e3363 100644
--- a/tools/libxc/xc_minios.c
+++ b/tools/libxc/xc_minios.c
@@ -41,164 +41,10 @@
#include xc_private.h
-void minios_interface_close_fd(int fd);
void minios_evtchn_close_fd(int fd);
-void minios_gnttab_close_fd(int fd);
-
-extern void minios_interface_close_fd(int fd);
-extern void minios_evtchn_close_fd(int fd);
extern struct wait_queue_head event_queue;
-static xc_osdep_handle minios_privcmd_open(xc_interface *xch)
-{
-int fd = alloc_fd(FTYPE_XC);
-
-if ( fd == -1)
-return XC_OSDEP_OPEN_ERROR;
-
-return (xc_osdep_handle)fd;
-}
-
-static int minios_privcmd_close(xc_interface *xch, xc_osdep_handle h)
-{
-int fd = (int)h;
-return close(fd);
-}
-
-void minios_interface_close_fd(int fd)
-{
-files[fd].type = FTYPE_NONE;
-}
-
-static void *minios_privcmd_alloc_hypercall_buffer(xc_interface *xch,
xc_osdep_handle h, int npages)
-{
-return xc_memalign(xch, PAGE_SIZE, npages * PAGE_SIZE);
-}
-
-static void minios_privcmd_free_hypercall_buffer(xc_interface *xch,
xc_osdep_handle h, void *ptr, int npages)
-{
-free(ptr);
-}
-
-static int minios_privcmd_hypercall(xc_interface *xch, xc_osdep_handle h,
privcmd_hypercall_t *hypercall)
-{
-multicall_entry_t call;
-int i, ret;
-
-call.op = hypercall-op;
-for (i = 0; i ARRAY_SIZE(hypercall-arg); i++)
- call.args[i] = hypercall-arg[i];
-
-ret = HYPERVISOR_multicall(call, 1);
-
-if (ret 0) {
- errno = -ret;
- return -1;
-}
-if ((long) call.result 0) {
-errno = - (long) call.result;
-return -1;
-}
-return call.result;
-}
-
-static void *minios_privcmd_map_foreign_bulk(xc_interface *xch,
xc_osdep_handle h,
- uint32_t dom, int prot,
- const xen_pfn_t *arr, int *err,
unsigned int num)
-{
-unsigned long pt_prot = 0;
-if (prot PROT_READ)
- pt_prot = L1_PROT_RO;
-if (prot PROT_WRITE)
- pt_prot = L1_PROT;
-return map_frames_ex(arr, num, 1, 0, 1, dom, err, pt_prot);
-}
-
-static void *minios_privcmd_map_foreign_batch(xc_interface *xch,
xc_osdep_handle h,
- uint32_t dom, int prot,
- xen_pfn_t *arr, int num)
-{
-unsigned long pt_prot = 0;
-int err[num];
-int i;
-unsigned long addr;
-
-if (prot PROT_READ)
- pt_prot = L1_PROT_RO;
-if (prot PROT_WRITE)
- pt_prot = L1_PROT;
-
-addr = (unsigned long) map_frames_ex(arr, num, 1, 0, 1, dom, err, pt_prot);
-for (i = 0; i num; i++) {
-if (err[i])
-arr[i] |= 0xF000;
-}
-return (void *) addr;
-}
-
-static void *minios_privcmd_map_foreign_range(xc_interface *xch,
xc_osdep_handle h,
- uint32_t dom,
- int size, int prot,
- unsigned long mfn)
-{
-unsigned long
[Xen-devel] [PATCH v2 4/5] libxc: minios: introduce abstraction for files[]
We are going to want to reuse this code for NetBSD rump kernels, where
there is no gntmap device and we just want to call the MiniOS gntmap
code directly.
As part of this we want to abstract away the use of files[] inside the
actual functions. Do this with a #define whose definition we are
going to make conditional in just a moment.
No functional change in this patch.
Signed-off-by: Ian Jackson ian.jack...@eu.citrix.com
Signed-off-by: Wei Liu wei.l...@citrix.com
Acked-by: Samuel Thibault samuel.thiba...@ens-lyon.org
Acked-by: Ian Campbell ian.campb...@citrix.com
---
Changes in v2:
1. Fix a bug spotted by Jürgen.
---
tools/libxc/xc_minios_common.c | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/tools/libxc/xc_minios_common.c b/tools/libxc/xc_minios_common.c
index 8b08cde..c38b5f2 100644
--- a/tools/libxc/xc_minios_common.c
+++ b/tools/libxc/xc_minios_common.c
@@ -208,12 +208,14 @@ struct xc_osdep_ops xc_privcmd_ops = {
},
};
+#define GNTMAP(h) (files[(int)(h)].gntmap)
+
static xc_osdep_handle minios_gnttab_open(xc_gnttab *xcg)
{
int fd = alloc_fd(FTYPE_GNTMAP);
if ( fd == -1 )
return XC_OSDEP_OPEN_ERROR;
-gntmap_init(files[fd].gntmap);
+gntmap_init(GNTMAP(fd));
return (xc_osdep_handle)fd;
}
@@ -225,7 +227,7 @@ static int minios_gnttab_close(xc_gnttab *xcg,
xc_osdep_handle h)
void minios_gnttab_close_fd(int fd)
{
-gntmap_fini(files[fd].gntmap);
+gntmap_fini(GNTMAP(fd));
files[fd].type = FTYPE_NONE;
}
@@ -235,7 +237,6 @@ static void *minios_gnttab_grant_map(xc_gnttab *xcg,
xc_osdep_handle h,
uint32_t notify_offset,
evtchn_port_t notify_port)
{
-int fd = (int)h;
int stride = 1;
if (flags XC_GRANT_MAP_SINGLE_DOMAIN)
stride = 0;
@@ -243,7 +244,7 @@ static void *minios_gnttab_grant_map(xc_gnttab *xcg,
xc_osdep_handle h,
errno = ENOSYS;
return NULL;
}
-return gntmap_map_grant_refs(files[fd].gntmap,
+return gntmap_map_grant_refs(GNTMAP(fd),
count, domids, stride,
refs, prot PROT_WRITE);
}
@@ -252,9 +253,8 @@ static int minios_gnttab_munmap(xc_gnttab *xcg,
xc_osdep_handle h,
void *start_address,
uint32_t count)
{
-int fd = (int)h;
int ret;
-ret = gntmap_munmap(files[fd].gntmap,
+ret = gntmap_munmap(GNTMAP(fd),
(unsigned long) start_address,
count);
if (ret 0) {
@@ -267,9 +267,8 @@ static int minios_gnttab_munmap(xc_gnttab *xcg,
xc_osdep_handle h,
static int minios_gnttab_set_max_grants(xc_gnttab *xcg, xc_osdep_handle h,
uint32_t count)
{
-int fd = (int)h;
int ret;
-ret = gntmap_set_max_grants(files[fd].gntmap,
+ret = gntmap_set_max_grants(GNTMAP(fd),
count);
if (ret 0) {
errno = -ret;
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 1/5] NetBSDRump: provide evtchn.h
Xen's build system has a target for rump kernel called NetBSDRump. We
want to build libxc against rump kernel, so we need to copy NetBSD's
evtchn.h to NetBSDRump. This copy is not very likely to diverge from
NetBSD's copy, but we don't preclude such possibility.
The actual implementation of evtch code will be factored out from
libxc's NetBSD osdep code.
Signed-off-by: Ian Jackson ian.jack...@eu.citrix.com
Signed-off-by: Wei Liu wei.l...@citrix.com
---
Changes in v2:
1. Better commit message.
---
tools/include/xen-sys/NetBSDRump/evtchn.h | 86 +++
1 file changed, 86 insertions(+)
create mode 100644 tools/include/xen-sys/NetBSDRump/evtchn.h
diff --git a/tools/include/xen-sys/NetBSDRump/evtchn.h
b/tools/include/xen-sys/NetBSDRump/evtchn.h
new file mode 100644
index 000..2d8a1f9
--- /dev/null
+++ b/tools/include/xen-sys/NetBSDRump/evtchn.h
@@ -0,0 +1,86 @@
+/* $NetBSD: evtchn.h,v 1.1.1.1 2007/06/14 19:39:45 bouyer Exp $ */
+/**
+ * evtchn.h
+ *
+ * Interface to /dev/xen/evtchn.
+ *
+ * Copyright (c) 2003-2005, K A Fraser
+ *
+ * This file may be distributed separately from the Linux kernel, or
+ * incorporated into other software packages, subject to the following license:
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this source file (the Software), to deal in the Software without
+ * restriction, including without limitation the rights to use, copy, modify,
+ * merge, publish, distribute, sublicense, and/or sell copies of the Software,
+ * and to permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ */
+
+#ifndef __NetBSD_EVTCHN_H__
+#define __NetBSD_EVTCHN_H__
+
+/*
+ * Bind a fresh port to VIRQ @virq.
+ */
+#define IOCTL_EVTCHN_BIND_VIRQ \
+ _IOWR('E', 4, struct ioctl_evtchn_bind_virq)
+struct ioctl_evtchn_bind_virq {
+ unsigned int virq;
+ unsigned int port;
+};
+
+/*
+ * Bind a fresh port to remote @remote_domain, @remote_port.
+ */
+#define IOCTL_EVTCHN_BIND_INTERDOMAIN \
+ _IOWR('E', 5, struct ioctl_evtchn_bind_interdomain)
+struct ioctl_evtchn_bind_interdomain {
+ unsigned int remote_domain, remote_port;
+ unsigned int port;
+};
+
+/*
+ * Allocate a fresh port for binding to @remote_domain.
+ */
+#define IOCTL_EVTCHN_BIND_UNBOUND_PORT \
+ _IOWR('E', 6, struct ioctl_evtchn_bind_unbound_port)
+struct ioctl_evtchn_bind_unbound_port {
+ unsigned int remote_domain;
+ unsigned int port;
+};
+
+/*
+ * Unbind previously allocated @port.
+ */
+#define IOCTL_EVTCHN_UNBIND\
+ _IOW('E', 7, struct ioctl_evtchn_unbind)
+struct ioctl_evtchn_unbind {
+ unsigned int port;
+};
+
+/*
+ * Send event to previously allocated @port.
+ */
+#define IOCTL_EVTCHN_NOTIFY\
+ _IOW('E', 8, struct ioctl_evtchn_notify)
+struct ioctl_evtchn_notify {
+ unsigned int port;
+};
+
+/* Clear and reinitialise the event buffer. Clear error condition. */
+#define IOCTL_EVTCHN_RESET \
+ _IO('E', 9)
+
+#endif /* __NetBSD_EVTCHN_H__ */
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 3/5] libxc: split off xc_netbsd_evtchn.c
Rump kernel is going to use some but not all of the machinery previously
in xc_netbsd.c. Split the evtchn and ancillary code into its own file.
This part is pure code motion.
But we also have to alter the Makefile, and rename some symbols, as
with xc_minios*.c.
Signed-off-by: Ian Jackson ian.jack...@eu.citrix.com
Signed-off-by: Wei Liu wei.l...@citrix.com
---
Changes in v2:
1. xc_netbsd_user.c - xc_netbsd_evtchn.c.
---
tools/libxc/Makefile | 2 +-
tools/libxc/xc_netbsd.c| 168 +--
tools/libxc/xc_netbsd_evtchn.c | 196 +
3 files changed, 198 insertions(+), 168 deletions(-)
create mode 100644 tools/libxc/xc_netbsd_evtchn.c
diff --git a/tools/libxc/Makefile b/tools/libxc/Makefile
index 3a0ff22..8bf7344 100644
--- a/tools/libxc/Makefile
+++ b/tools/libxc/Makefile
@@ -46,7 +46,7 @@ CTRL_SRCS-$(CONFIG_X86) += xc_pagetab.c
CTRL_SRCS-$(CONFIG_Linux) += xc_linux.c xc_linux_osdep.c
CTRL_SRCS-$(CONFIG_FreeBSD) += xc_freebsd.c xc_freebsd_osdep.c
CTRL_SRCS-$(CONFIG_SunOS) += xc_solaris.c
-CTRL_SRCS-$(CONFIG_NetBSD) += xc_netbsd.c
+CTRL_SRCS-$(CONFIG_NetBSD) += xc_netbsd.c xc_netbsd_evtchn.c
CTRL_SRCS-$(CONFIG_MiniOS) += xc_minios.c xc_minios_common.c
GUEST_SRCS-y :=
diff --git a/tools/libxc/xc_netbsd.c b/tools/libxc/xc_netbsd.c
index 8a90ef3..f940607 100644
--- a/tools/libxc/xc_netbsd.c
+++ b/tools/libxc/xc_netbsd.c
@@ -224,172 +224,6 @@ static struct xc_osdep_ops netbsd_privcmd_ops = {
},
};
-#define EVTCHN_DEV_NAME /dev/xenevt
-
-static xc_osdep_handle netbsd_evtchn_open(xc_evtchn *xce)
-{
-int fd = open(EVTCHN_DEV_NAME, O_NONBLOCK|O_RDWR);
-if ( fd == -1 )
-return XC_OSDEP_OPEN_ERROR;
-
-return (xc_osdep_handle)fd;
-}
-
-static int netbsd_evtchn_close(xc_evtchn *xce, xc_osdep_handle h)
-{
-int fd = (int)h;
-return close(fd);
-}
-
-static int netbsd_evtchn_fd(xc_evtchn *xce, xc_osdep_handle h)
-{
-return (int)h;
-}
-
-static int netbsd_evtchn_notify(xc_evtchn *xce, xc_osdep_handle h,
evtchn_port_t port)
-{
-int fd = (int)h;
-struct ioctl_evtchn_notify notify;
-
-notify.port = port;
-
-return ioctl(fd, IOCTL_EVTCHN_NOTIFY, notify);
-}
-
-static evtchn_port_or_error_t
-netbsd_evtchn_bind_unbound_port(xc_evtchn * xce, xc_osdep_handle h, int domid)
-{
-int fd = (int)h;
-struct ioctl_evtchn_bind_unbound_port bind;
-int ret;
-
-bind.remote_domain = domid;
-
-ret = ioctl(fd, IOCTL_EVTCHN_BIND_UNBOUND_PORT, bind);
-if (ret == 0)
- return bind.port;
-else
- return -1;
-}
-
-static evtchn_port_or_error_t
-netbsd_evtchn_bind_interdomain(xc_evtchn *xce, xc_osdep_handle h, int domid,
- evtchn_port_t remote_port)
-{
-int fd = (int)h;
-struct ioctl_evtchn_bind_interdomain bind;
-int ret;
-
-bind.remote_domain = domid;
-bind.remote_port = remote_port;
-
-ret = ioctl(fd, IOCTL_EVTCHN_BIND_INTERDOMAIN, bind);
-if (ret == 0)
- return bind.port;
-else
- return -1;
-}
-
-static int netbsd_evtchn_unbind(xc_evtchn *xce, xc_osdep_handle h,
evtchn_port_t port)
-{
-int fd = (int)h;
-struct ioctl_evtchn_unbind unbind;
-
-unbind.port = port;
-
-return ioctl(fd, IOCTL_EVTCHN_UNBIND, unbind);
-}
-
-static evtchn_port_or_error_t
-netbsd_evtchn_bind_virq(xc_evtchn *xce, xc_osdep_handle h, unsigned int virq)
-{
-int fd = (int)h;
-struct ioctl_evtchn_bind_virq bind;
-int err;
-
-bind.virq = virq;
-
-err = ioctl(fd, IOCTL_EVTCHN_BIND_VIRQ, bind);
-if (err)
- return -1;
-else
- return bind.port;
-}
-
-static evtchn_port_or_error_t
-netbsd_evtchn_pending(xc_evtchn *xce, xc_osdep_handle h)
-{
-int fd = (int)h;
-evtchn_port_t port;
-
-if ( read_exact(fd, (char *)port, sizeof(port)) == -1 )
-return -1;
-
-return port;
-}
-
-static int netbsd_evtchn_unmask(xc_evtchn *xce, xc_osdep_handle h,
evtchn_port_t port)
-{
-int fd = (int)h;
-return write_exact(fd, (char *)port, sizeof(port));
-}
-
-static struct xc_osdep_ops netbsd_evtchn_ops = {
-.open = netbsd_evtchn_open,
-.close = netbsd_evtchn_close,
-
-.u.evtchn = {
- .fd = netbsd_evtchn_fd,
- .notify = netbsd_evtchn_notify,
- .bind_unbound_port = netbsd_evtchn_bind_unbound_port,
- .bind_interdomain = netbsd_evtchn_bind_interdomain,
- .bind_virq = netbsd_evtchn_bind_virq,
- .unbind = netbsd_evtchn_unbind,
- .pending = netbsd_evtchn_pending,
- .unmask = netbsd_evtchn_unmask,
-},
-};
-
-/* Optionally flush file to disk and discard page cache */
-void discard_file_cache(xc_interface *xch, int fd, int flush)
-{
-off_t cur = 0;
-int saved_errno = errno;
-
-if ( flush (fsync(fd) 0) )
-{
-/*PERROR(Failed to flush file: %s, strerror(errno));*/
-goto out;
-}
-
-/*
- * Calculate last page boundry of amount written so far
- * unless
[Xen-devel] [PATCH v2 0/5] Build libxc on rump kernel
Wei Liu (5): NetBSDRump: provide evtchn.h libxc: split off xc_minios_common.c libxc: split off xc_netbsd_evtchn.c libxc: minios: introduce abstraction for files[] libxc: rumpxen: provide xc_osdep_info tools/include/xen-sys/NetBSDRump/evtchn.h | 86 tools/libxc/Makefile | 6 +- tools/libxc/xc_minios.c | 243 +- tools/libxc/xc_minios_common.c| 322 ++ tools/libxc/xc_netbsd.c | 168 +--- tools/libxc/xc_netbsd_evtchn.c| 196 ++ tools/libxc/xc_netbsd_rumpkern.c | 59 ++ tools/libxc/xc_private.h | 3 + 8 files changed, 675 insertions(+), 408 deletions(-) create mode 100644 tools/include/xen-sys/NetBSDRump/evtchn.h create mode 100644 tools/libxc/xc_minios_common.c create mode 100644 tools/libxc/xc_netbsd_evtchn.c create mode 100644 tools/libxc/xc_netbsd_rumpkern.c -- 1.9.1 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 5/5] libxc: rumpxen: provide xc_osdep_info
This allows programs which use the bulk of libxc to link. We use
/dev/xenevt for event channels, the raw minios functions for privcmd
and gnttab, and the netbsd versions of discard_file_cache and
xc_memalign.
Signed-off-by: Ian Jackson ian.jack...@eu.citrix.com
Signed-off-by: Wei Liu wei.l...@citrix.com
---
tools/libxc/Makefile | 2 ++
tools/libxc/xc_minios_common.c | 34 ++-
tools/libxc/xc_netbsd_rumpkern.c | 59
3 files changed, 94 insertions(+), 1 deletion(-)
create mode 100644 tools/libxc/xc_netbsd_rumpkern.c
diff --git a/tools/libxc/Makefile b/tools/libxc/Makefile
index 8bf7344..c8a5442 100644
--- a/tools/libxc/Makefile
+++ b/tools/libxc/Makefile
@@ -48,6 +48,8 @@ CTRL_SRCS-$(CONFIG_FreeBSD) += xc_freebsd.c xc_freebsd_osdep.c
CTRL_SRCS-$(CONFIG_SunOS) += xc_solaris.c
CTRL_SRCS-$(CONFIG_NetBSD) += xc_netbsd.c xc_netbsd_evtchn.c
CTRL_SRCS-$(CONFIG_MiniOS) += xc_minios.c xc_minios_common.c
+CTRL_SRCS-$(CONFIG_NetBSDRump) += xc_netbsd_rumpkern.c xc_netbsd_evtchn.c
+CTRL_SRCS-$(CONFIG_NetBSDRump) += xc_minios_common.c
GUEST_SRCS-y :=
GUEST_SRCS-y += xg_private.c xc_suspend.c
diff --git a/tools/libxc/xc_minios_common.c b/tools/libxc/xc_minios_common.c
index c38b5f2..fd201fd 100644
--- a/tools/libxc/xc_minios_common.c
+++ b/tools/libxc/xc_minios_common.c
@@ -43,7 +43,17 @@
#ifdef __RUMPRUN__
# define map_frames_ex minios_map_frames_ex
-#endif /* __RUMPRUN__ */
+
+static xc_osdep_handle minios_privcmd_open(xc_interface *xch)
+{
+return 1;
+}
+static int minios_privcmd_close(xc_interface *xch, xc_osdep_handle h)
+{
+return 0;
+}
+
+#else /* !__RUMPRUN__ */
void minios_interface_close_fd(int fd);
void minios_gnttab_close_fd(int fd);
@@ -69,6 +79,8 @@ void minios_interface_close_fd(int fd)
files[fd].type = FTYPE_NONE;
}
+#endif /* !__RUMPRUN__ */
+
static void *minios_privcmd_alloc_hypercall_buffer(xc_interface *xch,
xc_osdep_handle h,
int npages)
@@ -208,6 +220,24 @@ struct xc_osdep_ops xc_privcmd_ops = {
},
};
+#ifdef __RUMPRUN__
+
+static struct gntmap static_gntmap;
+
+#define GNTMAP(h) static_gntmap
+
+static xc_osdep_handle minios_gnttab_open(xc_gnttab *xcg)
+{
+return 1;
+}
+
+static int minios_gnttab_close(xc_gnttab *xcg, xc_osdep_handle h)
+{
+return 0;
+}
+
+#else /* !__RUMPRUN__ */
+
#define GNTMAP(h) (files[(int)(h)].gntmap)
static xc_osdep_handle minios_gnttab_open(xc_gnttab *xcg)
@@ -231,6 +261,8 @@ void minios_gnttab_close_fd(int fd)
files[fd].type = FTYPE_NONE;
}
+#endif /* !__RUMPRUN__ */
+
static void *minios_gnttab_grant_map(xc_gnttab *xcg, xc_osdep_handle h,
uint32_t count, int flags, int prot,
uint32_t *domids, uint32_t *refs,
diff --git a/tools/libxc/xc_netbsd_rumpkern.c b/tools/libxc/xc_netbsd_rumpkern.c
new file mode 100644
index 000..882374a
--- /dev/null
+++ b/tools/libxc/xc_netbsd_rumpkern.c
@@ -0,0 +1,59 @@
+/**
+ *
+ * Copyright 2013 Citrix.
+ * Use is subject to license terms.
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation;
+ * version 2.1 of the License.
+ *
+ * This library 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
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301
USA
+ */
+
+#include xc_private.h
+
+#include xen/sys/evtchn.h
+#include unistd.h
+#include fcntl.h
+#include malloc.h
+#include sys/mman.h
+
+static struct xc_osdep_ops *rumpxen_osdep_init(xc_interface *xch,
+ enum xc_osdep_type type)
+{
+switch ( type )
+{
+case XC_OSDEP_PRIVCMD:
+return xc_privcmd_ops;
+case XC_OSDEP_EVTCHN:
+return xc_evtchn_ops;
+case XC_OSDEP_GNTTAB:
+return xc_gnttab_ops;
+default:
+return NULL;
+}
+}
+
+xc_osdep_info_t xc_osdep_info = {
+.name = Rump kernel OS interface,
+.init = rumpxen_osdep_init,
+.fake = 0,
+};
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: BSD
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v8 3/4] xen/arm: Make gic-v2 code handle hip04-d01 platform
Hello Frediano,
On 03/03/15 11:19, Frediano Ziglio wrote:
The GIC in this platform is mainly compatible with the standard
GICv2 beside:
- ITARGET is extended to 16 bit to support 16 CPUs;
- SGI mask is extended to support 16 CPUs;
- maximum supported interrupt is 510;
510 is not a multiple of 32. Is it normal?
This will result to having nr_lines = 512. What happen is we are trying
to access IRQ 510 and 511?
I don't know. I think it's the same reason why in xen/arch/arm/gic.c the limit
for irq is 1021 and not 1024 (see if ( likely(irq = 16 irq 1021) ) line)
Also, is it possible to have GICH.VirtualID = 510?
I think so, GICH have the same interface of normal GICv2.
...
diff --git a/MAINTAINERS b/MAINTAINERS index 0f04742..b17aab1 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -138,6 +138,11 @@ F: xen/drivers/char/omap-uart.c
F: xen/drivers/char/pl011.c
F: xen/drivers/passthrough/arm/
+HISILICON HIP04 SUPPORT
+M: Frediano Ziglio frediano.zig...@huawei.com
It might be good to have 2 maintainers form Huawei on this file. Ian
any though?
Added Zoltan Kiss.
+S: Supported
+F: xen/arch/arm/git-hip04.c
gic-hip04.c
Too many git commands :)
...
20cdbc9..94abdc4 100644
--- a/xen/arch/arm/gic-hip04.c
+++ b/xen/arch/arm/gic-hip04.c
@@ -1,7 +1,8 @@
/*
- * xen/arch/arm/gic-v2.c
+ * xen/arch/arm/gic-hip04.c
*
- * ARM Generic Interrupt Controller support v2
+ * Generic Interrupt Controller for HiSilicon Hip04 platform
+ * Based heavily from gic-v2.c
Please add a commit ID. It would help you to keep track of the GIC.
*
* Tim Deegan t...@xen.org
* Copyright (c) 2011 Citrix Systems.
@@ -71,59 +72,69 @@ static struct {
void __iomem * map_hbase; /* IO Address of virtual interface
registers */
paddr_t vbase;/* Address of virtual cpu interface
registers */
spinlock_t lock;
-} gicv2;
+} hip04gic;
-static struct gic_info gicv2_info;
+static struct gic_info hip04gic_info;
I think the renaming of gicv2 and gicv2_info is pointless here. Instead
of function name, it doesn't help for debugging.
It would also reduce the diff of this patch.
No problem
[..]
-DT_DEVICE_START(gicv2, GICv2, DEVICE_GIC)
-.dt_match = gicv2_dt_match,
-.init = gicv2_init,
+DT_DEVICE_START(hip04gic, GIC-HIP04, DEVICE_GIC)
+.dt_match = hip04gic_dt_match,
+.init = hip04gic_init,
DT_DEVICE_END
Please keep the same indentation as before.
I was wondering why the indentation is different. Ok
Frediano
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v9 0/4] xen/arm: Add support for Huawei hip04-d01 platform
This set of patches add Xen support for hip04-d01 platform (see https://wiki.linaro.org/Boards/D01 for details). Changes from v8: - added a maintainer (Julien Grall); - reduce difference from gic-hip04.c and gic-v2.c (Julien Grall); - specify base gic-v2.c for gic-hip04.c (Julien Grall); - other minor fixes (Julien Grall); - rewrite patch to check for interrupt controller nodes using device list classes. Changes from v7: - updated patches; - moved interrupt controller check in a separate patch (Ian Campbell); - changed conditional include of gic-hip04.c in Makefile (Ian Campbell); - added MAINTAINERS update (Ian Campbell). Changes from v6: - collapsed some patch (Julien Grall); - remove useless check for irq values; - test interrupt controller not using DT compatibility; - remove non standard drivers flag (Ian Campbell). Changes from V5.99.1: - removed RFC again; - use different constants for hip04 instead of redefine standard ones; - comment compatible string change; - add an option to ARM to enable non standard drivers; - rename gicv2 to hip04gic to make clear this is not a standard gic. Changes from v5: - do not change gic-v2.c code but use a copy. To be considered RFC, to see if better to use copy or other techniques. Changes from v4: - rebased to new version; - removed patch for computing GIC addresses as it apply to all platforms; - removed patches to platform (cpu and system operations) as now they can use a bootwrapper which provide them. Changes from v3: - change the way regs property is computed for GICv2 (Julien Grall); - revert order of compaible names for GIC (Julien Grall). Changes from v2: - rewrote DTS fix patch (Ian Campbell); - use is_hip04 macro instead of doing explicit test (Julien Grall); - do not use quirks to distinguish this platform (Ian Cambell); - move some GIC constants to C files instead of header (Julien Grall); - minor changes (Julien Grall). Changes from v1: - style (Julien Grall); - make gicv2_send_SGI faster (Julien Grall); - cleanup correctly if hip04_smp_init fails (Julien Grall); - remove quirks using compatibility (Ian Campbell); - other minor suggestions by Julien Grall. Frediano Ziglio (4): xen/arm: Duplicate gic-v2.c file to support hip04 platform version xen/arm: Detect GIC nodes based on class xen/arm: Make gic-v2 code handle hip04-d01 platform xen/arm: Force dom0 to use normal GICv2 driver on Hip04 platform MAINTAINERS | 6 + xen/arch/arm/Makefile | 1 + xen/arch/arm/domain_build.c | 8 +- xen/arch/arm/gic-hip04.c| 815 xen/include/asm-arm/gic.h | 4 +- 5 files changed, 826 insertions(+), 8 deletions(-) create mode 100644 xen/arch/arm/gic-hip04.c -- 1.9.1 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v9 2/4] xen/arm: Detect GIC nodes based on class
Instead of having a list with all matches use device list to detect
if a node is an interrupt controller.
Signed-off-by: Frediano Ziglio frediano.zig...@huawei.com
---
xen/arch/arm/domain_build.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 9f1f59f..aaa3b97 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1035,12 +1035,6 @@ static int handle_node(struct domain *d, struct
kernel_info *kinfo,
DT_MATCH_COMPATIBLE(arm,armv7-timer-mem),
{ /* sentinel */ },
};
-static const struct dt_device_match gic_matches[] __initconst =
-{
-DT_MATCH_GIC_V2,
-DT_MATCH_GIC_V3,
-{ /* sentinel */ },
-};
static const struct dt_device_match timer_matches[] __initconst =
{
DT_MATCH_TIMER,
@@ -1069,7 +1063,7 @@ static int handle_node(struct domain *d, struct
kernel_info *kinfo,
/* Replace these nodes with our own. Note that the original may be
* used_by DOMID_XEN so this check comes first. */
-if ( dt_match_node(gic_matches, node) )
+if ( device_get_class(node) == DEVICE_GIC )
return make_gic_node(d, kinfo-fdt, node);
if ( dt_match_node(timer_matches, node) )
return make_timer_node(d, kinfo-fdt, node);
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v8 2/4] xen/arm: Check for interrupt controller directly
2015-03-03 14:45 GMT+00:00 Julien Grall julien.gr...@linaro.org:
Hello Frediano,
On 03/03/15 11:19, Frediano Ziglio wrote:
This check allow to detect mail interrupt controller even if it does
main
not match one of the standard ones.
This allow boards with non standard controllers to be handled correctly
without having to manually edit the global list every time.
Signed-off-by: Frediano Ziglio frediano.zig...@huawei.com
---
xen/arch/arm/domain_build.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 9f1f59f..83951a3 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1069,7 +1069,7 @@ static int handle_node(struct domain *d, struct
kernel_info *kinfo,
/* Replace these nodes with our own. Note that the original may be
* used_by DOMID_XEN so this check comes first. */
-if ( dt_match_node(gic_matches, node) )
+if ( node == dt_interrupt_controller || dt_match_node(gic_matches,
node) )
return make_gic_node(d, kinfo-fdt, node);
What about if the device tree exposes multiple GICs? By mistake we will
expose the secondaries GIC if they are not standard.
As I suggested on a previous mail, I would prefer to introduce a new
callback to check if the node is a GIC.
I think something like this would make all happy (I hope, I tested and
works correctly on my board):
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 9f1f59f..aaa3b97 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1035,12 +1035,6 @@ static int handle_node(struct domain *d, struct
kernel_info *kinfo,
DT_MATCH_COMPATIBLE(arm,armv7-timer-mem),
{ /* sentinel */ },
};
-static const struct dt_device_match gic_matches[] __initconst =
-{
-DT_MATCH_GIC_V2,
-DT_MATCH_GIC_V3,
-{ /* sentinel */ },
-};
static const struct dt_device_match timer_matches[] __initconst =
{
DT_MATCH_TIMER,
@@ -1069,7 +1063,7 @@ static int handle_node(struct domain *d, struct
kernel_info *kinfo,
/* Replace these nodes with our own. Note that the original may be
* used_by DOMID_XEN so this check comes first. */
-if ( dt_match_node(gic_matches, node) )
+if ( device_get_class(node) == DEVICE_GIC )
return make_gic_node(d, kinfo-fdt, node);
if ( dt_match_node(timer_matches, node) )
return make_timer_node(d, kinfo-fdt, node);
--
1.9.1
Frediano
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v8 2/4] xen/arm: Check for interrupt controller directly
On 03/03/15 15:07, Frediano Ziglio wrote:
2015-03-03 14:45 GMT+00:00 Julien Grall julien.gr...@linaro.org:
Hello Frediano,
On 03/03/15 11:19, Frediano Ziglio wrote:
This check allow to detect mail interrupt controller even if it does
main
not match one of the standard ones.
This allow boards with non standard controllers to be handled correctly
without having to manually edit the global list every time.
Signed-off-by: Frediano Ziglio frediano.zig...@huawei.com
---
xen/arch/arm/domain_build.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 9f1f59f..83951a3 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1069,7 +1069,7 @@ static int handle_node(struct domain *d, struct
kernel_info *kinfo,
/* Replace these nodes with our own. Note that the original may be
* used_by DOMID_XEN so this check comes first. */
-if ( dt_match_node(gic_matches, node) )
+if ( node == dt_interrupt_controller || dt_match_node(gic_matches,
node) )
return make_gic_node(d, kinfo-fdt, node);
What about if the device tree exposes multiple GICs? By mistake we will
expose the secondaries GIC if they are not standard.
As I suggested on a previous mail, I would prefer to introduce a new
callback to check if the node is a GIC.
I think something like this would make all happy (I hope, I tested and
works correctly on my board):
This looks good to me.
Regards,
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 9f1f59f..aaa3b97 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1035,12 +1035,6 @@ static int handle_node(struct domain *d, struct
kernel_info *kinfo,
DT_MATCH_COMPATIBLE(arm,armv7-timer-mem),
{ /* sentinel */ },
};
-static const struct dt_device_match gic_matches[] __initconst =
-{
-DT_MATCH_GIC_V2,
-DT_MATCH_GIC_V3,
-{ /* sentinel */ },
-};
static const struct dt_device_match timer_matches[] __initconst =
{
DT_MATCH_TIMER,
@@ -1069,7 +1063,7 @@ static int handle_node(struct domain *d, struct
kernel_info *kinfo,
/* Replace these nodes with our own. Note that the original may be
* used_by DOMID_XEN so this check comes first. */
-if ( dt_match_node(gic_matches, node) )
+if ( device_get_class(node) == DEVICE_GIC )
return make_gic_node(d, kinfo-fdt, node);
if ( dt_match_node(timer_matches, node) )
return make_timer_node(d, kinfo-fdt, node);
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [linux-3.10 test] 35764: regressions - FAIL
flight 35764 linux-3.10 real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/35764/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemut-winxpsp3 7 windows-install fail REGR. vs. 26303 Regressions which are regarded as allowable (not blocking): test-amd64-i386-pair17 guest-migrate/src_host/dst_host fail like 26303 test-amd64-amd64-xl-winxpsp3 7 windows-install fail like 26303 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pvh-intel 9 guest-start fail 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-amd64-amd64-rumpuserxen-amd64 13 rumpuserxen-demo-xenstorels/xenstorels.repeat fail never pass test-amd64-amd64-xl-pvh-amd 9 guest-start fail never pass test-amd64-amd64-libvirt 10 migrate-support-checkfail never pass test-armhf-armhf-xl-sedf-pin 5 xen-boot fail never pass test-armhf-armhf-libvirt 5 xen-boot fail never pass test-armhf-armhf-xl-midway5 xen-boot fail never pass test-armhf-armhf-xl-sedf 5 xen-boot fail never pass test-armhf-armhf-xl-credit2 5 xen-boot fail never pass test-armhf-armhf-xl-multivcpu 5 xen-boot fail never pass test-armhf-armhf-xl 5 xen-boot fail never pass test-amd64-i386-xl-qemut-winxpsp3 14 guest-stopfail never pass test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 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-i386-xl-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-winxpsp3 14 guest-stop fail never pass test-amd64-amd64-xl-win7-amd64 14 guest-stop fail never pass test-amd64-amd64-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-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stopfail never pass version targeted for testing: linuxef16065a9e97e4fbcecc42e9effa3d2f15119794 baseline version: linuxbe67db109090b17b56eb8eb2190cd70700f107aa 923 people touched revisions under test, not listing them all 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 fail 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 fail test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64
Re: [Xen-devel] [PATCH 3/5] libxc: Split off xc_netbsd_user.c
On Mon, Mar 02, 2015 at 05:33:13PM +, Ian Campbell wrote: On Thu, 2015-02-26 at 11:56 +, Wei Liu wrote: From: Ian Jackson ian.jack...@eu.citrix.com We are going to want to use some but not all of the machinery previously in xc_netbsd.c Split the evtchn and ancillary code into its own file. This part is pure code motion. Why not xc_netbsd_evtchn? Ack. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v8 3/4] xen/arm: Make gic-v2 code handle hip04-d01 platform
Hello Frediano,
On 03/03/15 11:19, Frediano Ziglio wrote:
The GIC in this platform is mainly compatible with the standard
GICv2 beside:
- ITARGET is extended to 16 bit to support 16 CPUs;
- SGI mask is extended to support 16 CPUs;
- maximum supported interrupt is 510;
510 is not a multiple of 32. Is it normal?
This will result to having nr_lines = 512. What happen is we are trying
to access IRQ 510 and 511?
Also, is it possible to have GICH.VirtualID = 510?
- GICH APR and LR register offsets.
Signed-off-by: Frediano Ziglio frediano.zig...@huawei.com
Signed-off-by: Zoltan Kiss zoltan.k...@huawei.com
---
MAINTAINERS | 5 +
xen/arch/arm/Makefile| 1 +
xen/arch/arm/gic-hip04.c | 396
---
3 files changed, 209 insertions(+), 193 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 0f04742..b17aab1 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -138,6 +138,11 @@ F: xen/drivers/char/omap-uart.c
F: xen/drivers/char/pl011.c
F: xen/drivers/passthrough/arm/
+HISILICON HIP04 SUPPORT
+M: Frediano Ziglio frediano.zig...@huawei.com
It might be good to have 2 maintainers form Huawei on this file. Ian any
though?
+S: Supported
+F: xen/arch/arm/git-hip04.c
gic-hip04.c
+
CPU POOLS
M: Juergen Gross jgr...@suse.com
S: Supported
diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 41aba2e..935999e 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -12,6 +12,7 @@ obj-y += domctl.o
obj-y += sysctl.o
obj-y += domain_build.o
obj-y += gic.o gic-v2.o
+obj-$(CONFIG_ARM_32) += gic-hip04.o
obj-$(CONFIG_ARM_64) += gic-v3.o
obj-y += io.o
obj-y += irq.o
diff --git a/xen/arch/arm/gic-hip04.c b/xen/arch/arm/gic-hip04.c
index 20cdbc9..94abdc4 100644
--- a/xen/arch/arm/gic-hip04.c
+++ b/xen/arch/arm/gic-hip04.c
@@ -1,7 +1,8 @@
/*
- * xen/arch/arm/gic-v2.c
+ * xen/arch/arm/gic-hip04.c
*
- * ARM Generic Interrupt Controller support v2
+ * Generic Interrupt Controller for HiSilicon Hip04 platform
+ * Based heavily from gic-v2.c
Please add a commit ID. It would help you to keep track of the GIC.
*
* Tim Deegan t...@xen.org
* Copyright (c) 2011 Citrix Systems.
@@ -71,59 +72,69 @@ static struct {
void __iomem * map_hbase; /* IO Address of virtual interface registers */
paddr_t vbase;/* Address of virtual cpu interface registers
*/
spinlock_t lock;
-} gicv2;
+} hip04gic;
-static struct gic_info gicv2_info;
+static struct gic_info hip04gic_info;
I think the renaming of gicv2 and gicv2_info is pointless here. Instead
of function name, it doesn't help for debugging.
It would also reduce the diff of this patch.
[..]
-DT_DEVICE_START(gicv2, GICv2, DEVICE_GIC)
-.dt_match = gicv2_dt_match,
-.init = gicv2_init,
+DT_DEVICE_START(hip04gic, GIC-HIP04, DEVICE_GIC)
+.dt_match = hip04gic_dt_match,
+.init = hip04gic_init,
DT_DEVICE_END
Please keep the same indentation as before.
Regards,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] Regression due to d9581c7dcac15c02ad4d47c60c60f4d8f197db55 en/fb: allow xenfb initialization for hvm guest
On Tue, 2015-03-03 at 10:20 -0500, Konrad Rzeszutek Wilk wrote:
I am afraid that Xend is still widespread enough that we need some way
to
deal with it.
The #idef hackery - while not a nice way can make this work.
Or we can add this in an header/function as a quirk.
boolean xen_pvfb_dont_init_quirk(void)
{
#ifdef CONFIG_X86
I would be OK with having such a quirk without the ifdef (no xend has
been known to work on ARM anyway).
if (xen_running_on_version_or_later(4, 5) xen_hvm_domain())
Shouldn't this be xen_running_on_version_or_earlier(4, 4)?
Xend has been removed in 4.5.
This all sounds pretty gross, but if it is the way folks want to go,
shouldn't it try and determine that it is running on xend somehow
instead of guessing based on version number? 4.4 had xl in it too for
instance...
Right, so the secondary check would be to see if there is something
extra that Xend puts in the XenStore. And it looks to always
put 'protocol' in every device:
protocol is also written by guest kernels, and I wouldn't be surprised
if libxl or other toolstakcs write it on oocasion too. So I'm afraid
that particualr key is not suitable/
xm:
0 =
protocol = x86_32-abi
state = 1
backend-id = 0
backend = /local/domain/0/backend/vfb/7/0
While xl:
vfb =
0 =
backend = /local/domain/0/backend/vfb/1/0
backend-id = 0
state = 1
___
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
[Xen-devel] [PATCH v9 3/4] xen/arm: Make gic-v2 code handle hip04-d01 platform
The GIC in this platform is mainly compatible with the standard
GICv2 beside:
- ITARGET is extended to 16 bit to support 16 CPUs;
- SGI mask is extended to support 16 CPUs;
- maximum supported interrupt is 510;
- GICH APR and LR register offsets.
Signed-off-by: Frediano Ziglio frediano.zig...@huawei.com
Signed-off-by: Zoltan Kiss zoltan.k...@huawei.com
---
MAINTAINERS | 6 ++
xen/arch/arm/Makefile| 1 +
xen/arch/arm/gic-hip04.c | 270 ---
3 files changed, 147 insertions(+), 130 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 0f04742..af513ff 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -138,6 +138,12 @@ F: xen/drivers/char/omap-uart.c
F: xen/drivers/char/pl011.c
F: xen/drivers/passthrough/arm/
+HISILICON HIP04 SUPPORT
+M: Frediano Ziglio frediano.zig...@huawei.com
+M: Zoltan Kiss zoltan.k...@huawei.com
+S: Supported
+F: xen/arch/arm/gic-hip04.c
+
CPU POOLS
M: Juergen Gross jgr...@suse.com
S: Supported
diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 41aba2e..935999e 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -12,6 +12,7 @@ obj-y += domctl.o
obj-y += sysctl.o
obj-y += domain_build.o
obj-y += gic.o gic-v2.o
+obj-$(CONFIG_ARM_32) += gic-hip04.o
obj-$(CONFIG_ARM_64) += gic-v3.o
obj-y += io.o
obj-y += irq.o
diff --git a/xen/arch/arm/gic-hip04.c b/xen/arch/arm/gic-hip04.c
index 20cdbc9..0fda957 100644
--- a/xen/arch/arm/gic-hip04.c
+++ b/xen/arch/arm/gic-hip04.c
@@ -1,7 +1,8 @@
/*
- * xen/arch/arm/gic-v2.c
+ * xen/arch/arm/gic-hip04.c
*
- * ARM Generic Interrupt Controller support v2
+ * Generic Interrupt Controller for HiSilicon Hip04 platform
+ * Based heavily on gic-v2.c (id 3bcf563fec26378f7f4cf1e2ad0d4d5b3f341919)
*
* Tim Deegan t...@xen.org
* Copyright (c) 2011 Citrix Systems.
@@ -79,16 +80,26 @@ static struct gic_info gicv2_info;
* logical CPU numbering. Let's use mapping as returned by the GIC
* itself
*/
-static DEFINE_PER_CPU(u8, gic_cpu_id);
+static DEFINE_PER_CPU(u16, gic_cpu_id);
/* Maximum cpu interface per GIC */
-#define NR_GIC_CPU_IF 8
+#define NR_GIC_CPU_IF 16
+
+#define HIP04_GICD_SGI_TARGET_SHIFT 8
+
+#define HIP04_GICH_APR 0x70
+#define HIP04_GICH_LR0x80
static inline void writeb_gicd(uint8_t val, unsigned int offset)
{
writeb_relaxed(val, gicv2.map_dbase + offset);
}
+static inline void writew_gicd(uint16_t val, unsigned int offset)
+{
+writew_relaxed(val, gicv2.map_dbase + offset);
+}
+
static inline void writel_gicd(uint32_t val, unsigned int offset)
{
writel_relaxed(val, gicv2.map_dbase + offset);
@@ -123,7 +134,7 @@ static inline uint32_t readl_gich(int unsigned offset)
return readl_relaxed(gicv2.map_hbase + offset);
}
-static unsigned int gicv2_cpu_mask(const cpumask_t *cpumask)
+static unsigned int hip04gic_cpu_mask(const cpumask_t *cpumask)
{
unsigned int cpu;
unsigned int mask = 0;
@@ -139,7 +150,7 @@ static unsigned int gicv2_cpu_mask(const cpumask_t *cpumask)
return mask;
}
-static void gicv2_save_state(struct vcpu *v)
+static void hip04gic_save_state(struct vcpu *v)
{
int i;
@@ -148,27 +159,27 @@ static void gicv2_save_state(struct vcpu *v)
* accessed simultaneously by another pCPU.
*/
for ( i = 0; i gicv2_info.nr_lrs; i++ )
-v-arch.gic.v2.lr[i] = readl_gich(GICH_LR + i * 4);
+v-arch.gic.v2.lr[i] = readl_gich(HIP04_GICH_LR + i * 4);
-v-arch.gic.v2.apr = readl_gich(GICH_APR);
+v-arch.gic.v2.apr = readl_gich(HIP04_GICH_APR);
v-arch.gic.v2.vmcr = readl_gich(GICH_VMCR);
/* Disable until next VCPU scheduled */
writel_gich(0, GICH_HCR);
}
-static void gicv2_restore_state(const struct vcpu *v)
+static void hip04gic_restore_state(const struct vcpu *v)
{
int i;
for ( i = 0; i gicv2_info.nr_lrs; i++ )
-writel_gich(v-arch.gic.v2.lr[i], GICH_LR + i * 4);
+writel_gich(v-arch.gic.v2.lr[i], HIP04_GICH_LR + i * 4);
-writel_gich(v-arch.gic.v2.apr, GICH_APR);
+writel_gich(v-arch.gic.v2.apr, HIP04_GICH_APR);
writel_gich(v-arch.gic.v2.vmcr, GICH_VMCR);
writel_gich(GICH_HCR_EN, GICH_HCR);
}
-static void gicv2_dump_state(const struct vcpu *v)
+static void hip04gic_dump_state(const struct vcpu *v)
{
int i;
@@ -176,7 +187,7 @@ static void gicv2_dump_state(const struct vcpu *v)
{
for ( i = 0; i gicv2_info.nr_lrs; i++ )
printk( HW_LR[%d]=%x\n, i,
- readl_gich(GICH_LR + i * 4));
+ readl_gich(HIP04_GICH_LR + i * 4));
}
else
{
@@ -185,20 +196,20 @@ static void gicv2_dump_state(const struct vcpu *v)
}
}
-static void gicv2_eoi_irq(struct irq_desc *irqd)
+static void hip04gic_eoi_irq(struct irq_desc *irqd)
{
int irq = irqd-irq;
/* Lower the priority */
writel_gicc(irq, GICC_EOIR);
}
-static void gicv2_dir_irq(struct irq_desc *irqd)
+static
[Xen-devel] [PATCH v9 1/4] xen/arm: Duplicate gic-v2.c file to support hip04 platform version
HiSilison Hip04 platform use a slightly different version.
This is just a verbatim copy of the file to workaround git
not fully supporting copy operation.
Signed-off-by: Frediano Ziglio frediano.zig...@huawei.com
---
xen/arch/arm/gic-hip04.c | 801 +++
1 file changed, 801 insertions(+)
create mode 100644 xen/arch/arm/gic-hip04.c
diff --git a/xen/arch/arm/gic-hip04.c b/xen/arch/arm/gic-hip04.c
new file mode 100644
index 000..20cdbc9
--- /dev/null
+++ b/xen/arch/arm/gic-hip04.c
@@ -0,0 +1,801 @@
+/*
+ * xen/arch/arm/gic-v2.c
+ *
+ * ARM Generic Interrupt Controller support v2
+ *
+ * Tim Deegan t...@xen.org
+ * Copyright (c) 2011 Citrix Systems.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 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 General Public License for more details.
+ */
+
+#include xen/config.h
+#include xen/lib.h
+#include xen/init.h
+#include xen/mm.h
+#include xen/irq.h
+#include xen/sched.h
+#include xen/errno.h
+#include xen/softirq.h
+#include xen/list.h
+#include xen/device_tree.h
+#include xen/libfdt/libfdt.h
+#include asm/p2m.h
+#include asm/domain.h
+#include asm/platform.h
+#include asm/device.h
+
+#include asm/io.h
+#include asm/gic.h
+
+/*
+ * LR register definitions are GIC v2 specific.
+ * Moved these definitions from header file to here
+ */
+#define GICH_V2_LR_VIRTUAL_MASK0x3ff
+#define GICH_V2_LR_VIRTUAL_SHIFT 0
+#define GICH_V2_LR_PHYSICAL_MASK 0x3ff
+#define GICH_V2_LR_PHYSICAL_SHIFT 10
+#define GICH_V2_LR_STATE_MASK 0x3
+#define GICH_V2_LR_STATE_SHIFT 28
+#define GICH_V2_LR_PRIORITY_SHIFT 23
+#define GICH_V2_LR_PRIORITY_MASK 0x1f
+#define GICH_V2_LR_HW_SHIFT31
+#define GICH_V2_LR_HW_MASK 0x1
+#define GICH_V2_LR_GRP_SHIFT 30
+#define GICH_V2_LR_GRP_MASK0x1
+#define GICH_V2_LR_MAINTENANCE_IRQ (119)
+#define GICH_V2_LR_GRP1(130)
+#define GICH_V2_LR_HW (131)
+#define GICH_V2_LR_CPUID_SHIFT 9
+#define GICH_V2_VTR_NRLRGS 0x3f
+
+#define GICH_V2_VMCR_PRIORITY_MASK 0x1f
+#define GICH_V2_VMCR_PRIORITY_SHIFT 27
+
+/* Global state */
+static struct {
+paddr_t dbase;/* Address of distributor registers */
+void __iomem * map_dbase; /* IO mapped Address of distributor registers */
+paddr_t cbase;/* Address of CPU interface registers */
+void __iomem * map_cbase[2]; /* IO mapped Address of CPU interface
registers */
+paddr_t hbase;/* Address of virtual interface registers */
+void __iomem * map_hbase; /* IO Address of virtual interface registers */
+paddr_t vbase;/* Address of virtual cpu interface registers */
+spinlock_t lock;
+} gicv2;
+
+static struct gic_info gicv2_info;
+
+/* The GIC mapping of CPU interfaces does not necessarily match the
+ * logical CPU numbering. Let's use mapping as returned by the GIC
+ * itself
+ */
+static DEFINE_PER_CPU(u8, gic_cpu_id);
+
+/* Maximum cpu interface per GIC */
+#define NR_GIC_CPU_IF 8
+
+static inline void writeb_gicd(uint8_t val, unsigned int offset)
+{
+writeb_relaxed(val, gicv2.map_dbase + offset);
+}
+
+static inline void writel_gicd(uint32_t val, unsigned int offset)
+{
+writel_relaxed(val, gicv2.map_dbase + offset);
+}
+
+static inline uint32_t readl_gicd(unsigned int offset)
+{
+return readl_relaxed(gicv2.map_dbase + offset);
+}
+
+static inline void writel_gicc(uint32_t val, unsigned int offset)
+{
+unsigned int page = offset PAGE_SHIFT;
+offset = ~PAGE_MASK;
+writel_relaxed(val, gicv2.map_cbase[page] + offset);
+}
+
+static inline uint32_t readl_gicc(unsigned int offset)
+{
+unsigned int page = offset PAGE_SHIFT;
+offset = ~PAGE_MASK;
+return readl_relaxed(gicv2.map_cbase[page] + offset);
+}
+
+static inline void writel_gich(uint32_t val, unsigned int offset)
+{
+writel_relaxed(val, gicv2.map_hbase + offset);
+}
+
+static inline uint32_t readl_gich(int unsigned offset)
+{
+return readl_relaxed(gicv2.map_hbase + offset);
+}
+
+static unsigned int gicv2_cpu_mask(const cpumask_t *cpumask)
+{
+unsigned int cpu;
+unsigned int mask = 0;
+cpumask_t possible_mask;
+
+cpumask_and(possible_mask, cpumask, cpu_possible_map);
+for_each_cpu( cpu, possible_mask )
+{
+ASSERT(cpu NR_GIC_CPU_IF);
+mask |= per_cpu(gic_cpu_id, cpu);
+}
+
+return mask;
+}
+
+static void gicv2_save_state(struct vcpu *v)
+{
+int i;
+
+/* No need for spinlocks here because interrupts are disabled around
+ * this call and it only accesses struct vcpu fields that cannot be
+ *
Re: [Xen-devel] [PATCH 5/5] libxc: rumpxen: Provide xc_osdep_info
On Mon, Mar 02, 2015 at 05:36:33PM +, Ian Campbell wrote: On Thu, 2015-02-26 at 11:56 +, Wei Liu wrote: diff --git a/tools/libxc/xc_netbsd_rumpkern.c b/tools/libxc/xc_netbsd_rumpkern.c new file mode 100644 index 000..11d4a63 --- /dev/null +++ b/tools/libxc/xc_netbsd_rumpkern.c @@ -0,0 +1,62 @@ +/** + * + * Copyright 2013 Citrix. + * Use is subject to license terms. + * + * xc_gnttab functions: + * Copyright (c) 2007-2008, D G Murray derek.mur...@cl.cam.ac.uk It doesn't seem like any of that remains. In fact I suspect this is just a cut-and-paste error? Yes, cut-and-paste error. Deleted now. Wei. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] xen 4.5 non-debug error logging misleading when xz support is unavailable
Hi, xen 4.5 building from source on debian wheezy kernel 3.16 amd64 $ xl create wheezy-template-amd64.cfg Parsing config from wheezy-template64.mens-net.private.cfg xc: error: panic: xc_dom_bzimageloader.c:730: xc_dom_probe_bzimage_kernel unable to XZ decompress kernel: Invalid kernel xc: error: panic: xc_dom_core.c:677: xc_dom_find_loader: no loader found: Invalid kernel libxl: error: libxl_dom.c:583:libxl__build_pv: xc_dom_parse_image failed: No such file or directory libxl: error: libxl_create.c:1121:domcreate_rebuild_done: cannot (re-)build domain: -3 $ xl -v create wheezy-template-amd64.cfg Parsing config from wheezy-template64.mens-net.private.cfg domainbuilder: detail: xc_dom_allocate: cmdline=root=/dev/xvda2 ro elevator=noop, features=(null) domainbuilder: detail: xc_dom_kernel_file: filename=/boot/vmlinuz-3.16.0-0.bpo.4-amd64 domainbuilder: detail: xc_dom_malloc_filemap: 3058 kB domainbuilder: detail: xc_dom_ramdisk_file: filename=/boot/initrd.img-3.16.0-0.bpo.4-amd64 domainbuilder: detail: xc_dom_malloc_filemap: 13523 kB domainbuilder: detail: xc_dom_boot_xen_init: ver 4.5, caps xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64 domainbuilder: detail: xc_dom_parse_image: called domainbuilder: detail: xc_dom_find_loader: trying multiboot-binary loader ... domainbuilder: detail: loader probe failed domainbuilder: detail: xc_dom_find_loader: trying Linux bzImage loader ... domainbuilder: detail: xc_try_xz_decode: XZ decompress support unavailable xc: error: panic: xc_dom_bzimageloader.c:730: xc_dom_probe_bzimage_kernel unable to XZ decompress kernel: Invalid kernel domainbuilder: detail: loader probe failed domainbuilder: detail: xc_dom_find_loader: trying ELF-generic loader ... domainbuilder: detail: loader probe failed xc: error: panic: xc_dom_core.c:677: xc_dom_find_loader: no loader found: Invalid kernel libxl: error: libxl_dom.c:583:libxl__build_pv: xc_dom_parse_image failed: No such file or directory domainbuilder: detail: xc_dom_release: called libxl: error: libxl_create.c:1121:domcreate_rebuild_done: cannot (re-)build domain: -3 After installing liblzma-dev and recompiling from source I was able to launch domU with no issues. Thanks Regards ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v6 02/23] xen: move NUMA_NO_NODE to public memory.h as XEN_NUMA_NO_NODE
On 03.03.15 at 04:42, raistlin...@gmail.com wrote: On Mon, 2015-03-02 at 18:19 +, Andrew Cooper wrote: In this case, a pnode of XEN_NO_NUMA_NODE seems like precisely the correct value to report. Indeed. It tells Xen: hey Xen, toolstack here: we either don't care or could not come up with any sane vnode-to-pnode mapping, please figure that out yourself. That makes the code, IMO, simpler at any level. In fact, at Xen level, there is a default way to deal with the situation (the striping) already. At the toolstack level, we can only care about trying to come up with some super-cool and super-good (for performance) configuration and just give up, if anything like what David and Andrew said occurs. See my earlier reply - the tool stack at least giving hints to the hypervisor in such a case would likely still be better (for the final result) than leaving it entirely up to the hypervisor: No node really means allocate from anywhere, whereas some specific node passed in still allows the hypervisor to find second best fits when having to fall back. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] kasan_map_early_shadow() on Xen
On 03/03/15 09:40, Luis R. Rodriguez wrote: Andrey, I believe that on Xen we should disable kasan, would like confirmation Why? This is the first of heard of this. from someone on xen-devel though. Here's the thing though -- if true -- I'd like to do it *properly*, where *properly* means addressing a bit of architecture. A simple Kconfig slap seems rather reactive. I'd like to address a way to properly ensure we don't run into this and other similar issues in the future. The CR4 shadow issue was another recent example issue, also introduced via v4.0 [0]. We can't keep doing this reactively. Let's go down the rabbit hole for a bit. HAVE_ARCH_KASAN will be selected on x86 when: if X86_64 SPARSEMEM_VMEMMAP Now Xen should not have SPARSEMEM_VMEMMAP but PVOPs' goal is to enable Why? Again, this is the first I've heard of this as well. FWIW, all the Xen configs we use have SPARSEMEM_VMEMMAP enabled. David distributions to be able to have a single binary kernels and let the rest be figured out, so we can't just disable SPARSEMEM_VMEMMAP for Xen alone, we want to build Xen.. or part of Xen and perhaps keep SPARSEMEM_VMEMMAP, and only later figure things out. How do we do this cleanly and avoid future reactive measures? If the answer is not upon us, I'd like to at least highlight the issue so that in case we do come up with something its no surprise PVOPs is falling short for that single binary pipe dream right now. [0] https://lkml.org/lkml/2015/2/23/328 Luis ___ 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] [Qemu-devel] [v2][PATCH] libxl: add one machine property to support IGD GFX passthrough
Campbell,
Are you free to look at my reply?
Thanks
Tiejun
On 2015/3/2 9:20, Chen, Tiejun wrote:
Here I just mean when Qemu realizes IGD is passed through but without
that appropriate option set, Qemu can post something to explicitly
notify user that this option is needed in his case. But it may be a lazy
idea.
In any case I think the additions of such warnings in qemu are a
separate to the discussion in this thread, so I propose to leave it
alone for now.
Okay.
So now I think I'd better go back handling this on Xen side with your
comments. As you said the Boolean doesn't suffice to indicate that IGD
workarounds are needed. So I think we can reuse that existing bool
'gfx_passthru'.
Firstly we can redefine this as string,
Unfortunately not since libxl's API guarantee requires older clients to
keep working, i.e. those who use libxl_defbool_set on this field.
Probably the best which can be done is to deprecate this field in favour
of a new one (the old field would need to be obeyed only if the new one
was set to its default value).
Probably an Enumeration would be better than a raw string here as well.
This approach doesn't allow for the possibility of multiple such
workarounds though. It's unclear to me if this matters or not.
The other option which I've mentioned is to leave gfx_passthru and have
libxl figure out which workarounds to enable based on the set of PCI
devices passed through. I guess you don't like that approach? (due to
the need to maintain the pci vid:did list?)
No, I like that approach currently :) Please see the below,
- (gfx_passthru,
libxl_defbool),
+ (gfx_passthru, string),
Then
+
+if (libxl__is_igd_vga_passthru(gc, guest_config) ||
This is just working out that way that I already posted previously, and
here I paste this code fragment again,
+static const pci_info fixup_ids[] = {
+/* Intel HSW Classic */
+{0x8086, 0x0402}, /* HSWGT1D, HSWD_w7 */
+{0x8086, 0x0406}, /* HSWGT1M, HSWM_w7 */
+{0x8086, 0x0412}, /* HSWGT2D, HSWD_w7 */
+{0x8086, 0x0416}, /* HSWGT2M, HSWM_w7 */
+{0x8086, 0x041E}, /* HSWGT15D, HSWD_w7 */
+/* Intel HSW ULT */
+{0x8086, 0x0A06}, /* HSWGT1UT, HSWM_w7 */
+{0x8086, 0x0A16}, /* HSWGT2UT, HSWM_w7 */
+{0x8086, 0x0A26}, /* HSWGT3UT, HSWM_w7 */
+{0x8086, 0x0A2E}, /* HSWGT3UT28W, HSWM_w7 */
+{0x8086, 0x0A1E}, /* HSWGT2UX, HSWM_w7 */
+{0x8086, 0x0A0E}, /* HSWGT1ULX, HSWM_w7 */
+/* Intel HSW CRW */
+{0x8086, 0x0D26}, /* HSWGT3CW, HSWM_w7 */
+{0x8086, 0x0D22}, /* HSWGT3CWDT, HSWD_w7 */
+/* Intel HSW Server */
+{0x8086, 0x041A}, /* HSWSVGT2, HSWD_w7 */
+/* Intel HSW SRVR */
+{0x8086, 0x040A}, /* HSWSVGT1, HSWD_w7 */
+/* Intel BSW */
+{0x8086, 0x1606}, /* BDWULTGT1, BDWM_w7 */
+{0x8086, 0x1616}, /* BDWULTGT2, BDWM_w7 */
+{0x8086, 0x1626}, /* BDWULTGT3, BDWM_w7 */
+{0x8086, 0x160E}, /* BDWULXGT1, BDWM_w7 */
+{0x8086, 0x161E}, /* BDWULXGT2, BDWM_w7 */
+{0x8086, 0x1602}, /* BDWHALOGT1, BDWM_w7 */
+{0x8086, 0x1612}, /* BDWHALOGT2, BDWM_w7 */
+{0x8086, 0x1622}, /* BDWHALOGT3, BDWM_w7 */
+{0x8086, 0x162B}, /* BDWHALO28W, BDWM_w7 */
+{0x8086, 0x162A}, /* BDWGT3WRKS, BDWM_w7 */
+{0x8086, 0x162D}, /* BDWGT3SRVR, BDWM_w7 */
+};
+
+/*
+ * Some devices may need some ways to work well. Here like IGD,
+ * we have to pass a specific option to qemu.
+ */
+int libxl__is_igd_vga_passthru(libxl__gc *gc,
+ const libxl_domain_config *d_config)
+{
+unsigned int i, j, num = ARRAY_SIZE(fixup_ids);
+uint16_t vendor, device;
+
+for (i = 0 ; i d_config-num_pcidevs ; i++) {
+libxl_device_pci *pcidev = d_config-pcidevs[i];
+
+for (j = 0 ; j num ; j++) {
+vendor = fixup_ids[j].vendor;
+device = fixup_ids[j].device;
+
+if (sysfs_dev_get_vendor(gc, pcidev) == vendor
+sysfs_dev_get_device(gc, pcidev) == device)
+return 1;
+}
+}
+
+return 0;
+}
+
Is this expected?
+(b_info-u.hvm.gfx_passthru
+ strncmp(b_info-u.hvm.gfx_passthru, igd, 3) == 0) ) {
But as you mentioned previously,
You might like to optionally consider add a forcing option somehow so
that people with new devices not in the list can control things without
the need to recompile (e.g. gfx_passthru_kind_override?).
Here I was trying to convert gfx_passthru to address this thing.
According to your comment right now, you prefer we should introduce a
new field instead of the original 'gfx_passthru' to enumerate such a
type. So what about this?
libxl_gfx_passthru_kind_type = Enumeration(gfx_passthru_kind_type, [
(0, unknown),
(1, igd),
])
Then if we want to override this, just submit the following line into .cfg:
gfx_passthru_kind_override = igd
Thanks
Tiejun
+machinearg = GCSPRINTF(%s,igd-passthru=on,
Re: [Xen-devel] [PATCH v2 1/3] xen/arm: Add ThunderX platform support
On Tue, 2015-03-03 at 14:59 +0530, Vijay Kilari wrote: On Tue, Mar 3, 2015 at 2:33 PM, Ian Campbell ian.campb...@citrix.com wrote: On Tue, 2015-03-03 at 10:39 +0530, Vijay Kilari wrote: On Mon, Feb 23, 2015 at 11:21 PM, Ian Campbell ian.campb...@citrix.com wrote: On Wed, 2015-02-18 at 12:38 +, Julien Grall wrote: +uint64_t addr, size; Please use paddr_t and PRIpaddr etc. +res = map_mmio_regions(d, + paddr_to_pfn(addr PAGE_MASK), + DIV_ROUND_UP(size, PAGE_SIZE), + paddr_to_pfn(addr PAGE_MASK)); OOI, why this region is not described in the DT? Is it a PCI device? It is not PCI device. it is Global SerDes configuration region. It is not mentioned in DT. Why not? Should it be? There is no specific driver in dom0 for this. It is only used by thunder pci driver in dom0 to configure serdes. A DT is supposed to describe the hardware, so the presence or absence of a driver in the kernel doesn't really come in to it. In future we plan to get rid of this. But for now we can have this mapping. The problem is that removing this mapping in the future may, depending on how it is all done, break compatibility with older kernels. Could you describe how you plan to get rid of it please so I can see if we need to worry about that sort of thing here? To avoid blocking the rest of the series it might be a good idea to factor out this specific mapping into a separate patch, then the rest can go in, plus you can then use the commit message to explain what the plan is etc. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V2] Add flag to start info regarding virtual mapped p2m list
On 03/03/2015 11:52 AM, Jan Beulich wrote: On 03.03.15 at 11:32, jgr...@suse.com wrote: On 03/03/2015 11:27 AM, Jan Beulich wrote: Also I'm not particularly happy with the name, as it suggests to be a statement about the initial P2M the guest gets handed - yet that is always virtually mapped. SIF_PERMANENT_VIRT_P2M is getting a little long I'm afraid, so I'm looking for better suggestions. SIF_VIRT_KERNEL_P2M? SIF_FLAT_P2M? Neither reflects that this is not a statement about the initial P2M. What about SIF_VIRT_P2M_4TOOLS? At least this variant would give a hint regarding the consumer of the p2m. Anybody wanting to know more should probably read the comment. :-) Juergen ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v6 02/23] xen: move NUMA_NO_NODE to public memory.h as XEN_NUMA_NO_NODE
On Tue, Mar 03, 2015 at 07:44:25AM +, Jan Beulich wrote: On 02.03.15 at 18:00, wei.l...@citrix.com wrote: There are two issues here irrespective of this series: 1. should we expose that sentinel in ABI? 2. if so, what should the sentinel be? I think Andrew and you disagree on the first one. We can work out the answer to the second question later. I very much think that if we want to allow a no node specification via the domctl, then this should be part of the ABI. But that value and its (implicit) equivalent used for memops don't need to be the same, and it looks like they can't. And looking at this I think the code we have right now needs fixing: The internal vnode_to_pnode array should become nodeid_t[], and input from the domctl should be validated to either be a valid pnode or the to be defined sentinel (which then, due to being stored as a more narrow type, needs translation to NUMA_NO_NODE). If we don't want to allow no node, then input should be validated to present valid pnodes. This is currently the case, I don't allow no node. Not because the toolstack is designed / expected to work, but because there are many implications that I am not quite sure of (and this thread sorta confirms that everybody has his / her idea of how this should work). Libxl always requires the pnode to be a valid one. A sentinel is used between libxc and libxl to mark if the node specified is a valid pnode. Other than that, that sentinel is not used, not passed down to hypervisor. I think Andrew and Dario came to the idea of needing to have a unified sentinel from different angels. Andrew happened to see me using (~0UL) as a sentinel then wanted me to propagate the hypervisor sentinel. Dario thought more about other use cases that might need provisioning. In any case, whether exposing this sentinel or not has no immediate user visible effect (it's only needed between libxc and libxl at the moment), and we don't have any burden maintaining a different sentinel in libxc because libxc is not defined as stable interface. Due to the controversy of this patch, I'm fine with dropping this patch and move forward (now 20+ patches are blocked by this one). If we can't come to a resolution within this week, I will just drop this patch and resend the others next week. Wei. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Strange memory balloning problem even if balloning is disabled
On 03/03/15 09:05, Fabio Fantoni wrote: Il 02/03/2015 17:31, David Vrabel ha scritto: On 02/03/15 16:23, Jan Beulich wrote: On 02.03.15 at 16:52, fabio.fant...@m2r.biz wrote: On systems with wheezy as dom0 and kernel 3.2 it seems there are no visible problems. After updating the kernel to 3.16 (from backports repository), after starting the domUs, I get many of these errors in syslog and kern.log (infinite loop): xen:balloon: Cannot add additional memory (-17) I have a vague recollection of some fix from David aiming at avoiding to issue this message, but you would clearly have better luck getting a qualified response if you Cc-ed kernel people when reporting kernel problems (assuming you need explicit Cc-s at all, as most relevant people read the list anyway afaik) - I certainly can't figure by what criteria you put together the Cc list. You need 3dcf63677d4eb7fdfc13290c8558c301d2588fe8 (xen/balloon: cancel ballooning if adding new memory failed) fd8b79511349efd1f0decea920f61b93acb34a75 (xen/balloon: Don't continue ballooning when BP_ECANCELED is encountered) Or you can disable CONFIG_XEN_BALLOON_MEMORY_HOTPLUG. David Readded the other part of my initial mail that explain better the problem (also with the patch above applied)... The strange thing is that it should not use balloning because both dom0 and domUs have fixed memory set and balloning disabled. Ballooned pages are required to back grant mapped pages in blkback and netback. David ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 3/4] freemem: remove call to libxl_wait_for_free_memory
Now that libxl_wait_for_memory_target is capable of waiting until dom0 reaches its target, we can remove the other wait function call: libxl_wait_for_free_memory. No need to wait twice. Once dom0 has met its target, simply loop again and recalculate free_memkb. Signed-off-by: Stefano Stabellini stefano.stabell...@eu.citrix.com --- tools/libxl/xl_cmdimpl.c |8 +--- 1 file changed, 1 insertion(+), 7 deletions(-) diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c index 2dc7574..2a19cca 100644 --- a/tools/libxl/xl_cmdimpl.c +++ b/tools/libxl/xl_cmdimpl.c @@ -2220,15 +2220,9 @@ static int freemem(uint32_t domid, libxl_domain_build_info *b_info) if (rc 0) return rc; -rc = libxl_wait_for_free_memory(ctx, domid, need_memkb, 10); -if (!rc) -return 0; -else if (rc != ERROR_NOMEM) -return rc; - /* wait until dom0 reaches its target, as long as we are making * progress */ -rc = libxl_wait_for_memory_target(ctx, 0, 1); +rc = libxl_wait_for_memory_target(ctx, 0, 10); if (rc 0) return rc; -- 1.7.10.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 4/4] libxl_wait_for_memory_target: wait for 2 sec at a time
Use a 2 sec sleep time in the loop to allow the guest to release a
decent amount of memory in an iteration (empirical tests show ballooning
speed to be 512MB/sec or recent boxes).
Signed-off-by: Stefano Stabellini stefano.stabell...@eu.citrix.com
---
tools/libxl/libxl.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 648a227..94b4d59 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -4970,7 +4970,7 @@ int libxl_wait_for_memory_target(libxl_ctx *ctx, uint32_t
domid, int wait_secs)
prev_memkb = UINT64_MAX;
do {
-sleep(1);
+sleep(2);
libxl_dominfo_dispose(info);
libxl_dominfo_init(info);
@@ -4986,7 +4986,7 @@ int libxl_wait_for_memory_target(libxl_ctx *ctx, uint32_t
domid, int wait_secs)
goto out;
}
else if (current_memkb == prev_memkb)
-wait_secs--;
+wait_secs -= 2;
/* if current_memkb prev_memkb loop for free as progress has
* been made */
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 2/4] libxl_wait_for_memory_target: wait as long as dom0 is making progress
Decrement wait_secs only if dom0 is making no progress toward reaching
the balloon target, otherwise loop again for free.
Signed-off-by: Stefano Stabellini stefano.stabell...@eu.citrix.com
Tested-by: Mike Latimer mlati...@suse.com
---
tools/libxl/libxl.c | 29 ++---
tools/libxl/xl_cmdimpl.c |4 ++--
2 files changed, 24 insertions(+), 9 deletions(-)
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 088786e..648a227 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -4959,26 +4959,41 @@ int libxl_wait_for_memory_target(libxl_ctx *ctx,
uint32_t domid, int wait_secs)
{
int rc = 0;
uint32_t target_memkb = 0;
+uint64_t current_memkb, prev_memkb;
libxl_dominfo info;
+rc = libxl_get_memory_target(ctx, domid, target_memkb);
+if (rc 0)
+return rc;
+
libxl_dominfo_init(info);
+prev_memkb = UINT64_MAX;
do {
-wait_secs--;
sleep(1);
-rc = libxl_get_memory_target(ctx, domid, target_memkb);
-if (rc 0)
-goto out;
-
libxl_dominfo_dispose(info);
libxl_dominfo_init(info);
rc = libxl_domain_info(ctx, info, domid);
if (rc 0)
goto out;
-} while (wait_secs 0 (info.current_memkb + info.outstanding_memkb)
target_memkb);
-if ((info.current_memkb + info.outstanding_memkb) = target_memkb)
+current_memkb = info.current_memkb + info.outstanding_memkb;
+
+if (current_memkb prev_memkb)
+{
+rc = ERROR_FAIL;
+goto out;
+}
+else if (current_memkb == prev_memkb)
+wait_secs--;
+/* if current_memkb prev_memkb loop for free as progress has
+ * been made */
+
+prev_memkb = current_memkb;
+} while (wait_secs 0 current_memkb target_memkb);
+
+if (current_memkb = target_memkb)
rc = 0;
else
rc = ERROR_FAIL;
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index f4c4122..2dc7574 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -2226,8 +2226,8 @@ static int freemem(uint32_t domid,
libxl_domain_build_info *b_info)
else if (rc != ERROR_NOMEM)
return rc;
-/* the memory target has been reached but the free memory is still
- * not enough: loop over again */
+/* wait until dom0 reaches its target, as long as we are making
+ * progress */
rc = libxl_wait_for_memory_target(ctx, 0, 1);
if (rc 0)
return rc;
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 0/4] fix freemem loop
Hi all, this patch series fixes the freemem loop on machines with very large amount of memory, where the current wait time is not enough. In order to be able to handle arbitrarly large amount of ram, we implement in libxl_wait_for_memory_target a policy of waiting until dom0 is making progress. The patch series also reverts libxl: Wait for ballooning if free memory is increasing, that is not actually implemented correctly. Stefano Stabellini (4): Revert libxl: Wait for ballooning if free memory is increasing libxl_wait_for_memory_target: wait as long as dom0 is making progress freemem: remove call to libxl_wait_for_free_memory libxl_wait_for_memory_target: wait for 2 sec at a time tools/libxl/libxl.c | 31 +++ tools/libxl/xl_cmdimpl.c | 29 ++--- 2 files changed, 29 insertions(+), 31 deletions(-) Cheers, Stefano ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RFC V2 1/5] libxl: add pvusb definitions
On Mon, 2015-01-19 at 16:28 +0800, Chunyan Liu wrote: Sorry for the long delay in replying. To attach a usb device, a virtual usb controller should be created first. This patch defines usbctrl and usbdevice related structs. Per 54ca17df026600095...@relay2.provo.novell.com please could you mention here that the HVM guest related parts (i.e. LIBXL_USBCTRL_TYPE_DEVICEMODEL) and libxl_usb_type are placeholders for emulated HVM support. In fact I wonder if it should just be omitted, we will need a LIBXL_HAVE for HVM USB support anyway once it is implemented so we can add the enum then. Or will we -- do we think returning an error for such an HVM guest with USB devices configured now is acceptable and for it to silently start working at some point in the future is OK? Signed-off-by: Chunyan Liu cy...@suse.com Signed-off-by: Simon Cao caobosi...@gmail.com --- tools/libxl/libxl_types.idl | 58 +++- tools/libxl/libxl_types_internal.idl | 1 + 2 files changed, 58 insertions(+), 1 deletion(-) diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl index 1214d2e..0639434 100644 --- a/tools/libxl/libxl_types.idl +++ b/tools/libxl/libxl_types.idl @@ -521,6 +531,27 @@ libxl_device_pci = Struct(device_pci, [ (seize, bool), ]) +libxl_device_usbctrl = Struct(device_usbctrl, [ +(name, string), +(type, libxl_usbctrl_type), +(backend_domid, libxl_domid), +(backend_domname, string), +(devid, libxl_devid), +(usb_version, uint8), +(num_ports, uint8), I think int would be fine for both of these last two (and is a bit kinder to language bindings). +]) + +libxl_device_usb = Struct(device_usb, [ +(ctrl, integer), Is this an index into something? If so what? There seems to be no usbctrl array added to the domain_config struct, so I'm unsure how this is used. +(port, integer), Port on the hub? +(intf, string), What is this one? (This may just be my lack of usb knowledge) +(u, KeyedUnion(None, libxl_usb_type, type, +[(hostdev, Struct(None, [ +(hostbus, integer), +(hostaddr, integer) ])) +])) +]) + @@ -547,6 +578,7 @@ libxl_domain_config = Struct(domain_config, [ (disks, Array(libxl_device_disk, num_disks)), (nics, Array(libxl_device_nic, num_nics)), (pcidevs, Array(libxl_device_pci, num_pcidevs)), +(usbs, Array(libxl_device_usb, num_usbs)), So, I'm unsure how this interacts with the controllers, which it doesn't seem to be possible to specify at domain build time. You pointed me to http://www.redhat.com/archives/libvir-list/2014-June/msg00038.html but having had a look through I can't see it. For v3 please could you give an overview/summary of how it fits together in the 0/N patch. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 1/4] Revert libxl: Wait for ballooning if free memory is increasing
This reverts commit 2563bca11544361dc2afa5e20b5663e10a0715cb.
---
tools/libxl/xl_cmdimpl.c | 17 +++--
1 file changed, 3 insertions(+), 14 deletions(-)
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index e41f633..f4c4122 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -2198,9 +2198,8 @@ static int preserve_domain(uint32_t *r_domid, libxl_event
*event,
static int freemem(uint32_t domid, libxl_domain_build_info *b_info)
{
-int rc, retries;
-const int MAX_RETRIES = 3;
-uint32_t need_memkb, free_memkb, free_memkb_prev = 0;
+int rc, retries = 3;
+uint32_t need_memkb, free_memkb;
if (!autoballoon)
return 0;
@@ -2209,7 +2208,6 @@ static int freemem(uint32_t domid,
libxl_domain_build_info *b_info)
if (rc 0)
return rc;
-retries = MAX_RETRIES;
do {
rc = libxl_get_free_memory(ctx, free_memkb);
if (rc 0)
@@ -2234,16 +2232,7 @@ static int freemem(uint32_t domid,
libxl_domain_build_info *b_info)
if (rc 0)
return rc;
-/*
- * If the amount of free mem has increased on this iteration (i.e.
- * some progress has been made) then reset the retry counter.
- */
-if (free_memkb free_memkb_prev) {
-retries = MAX_RETRIES;
-free_memkb_prev = free_memkb;
-} else {
-retries--;
-}
+retries--;
} while (retries 0);
return ERROR_NOMEM;
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RFC V2 2/5] libxl: export some functions for pvusb use
On Mon, 2015-01-19 at 16:28 +0800, Chunyan Liu wrote: Signed-off-by: Chunyan Liu cy...@suse.com Signed-off-by: Simon Cao caobosi...@gmail.com Acked-by: Ian Campbell ian.campb...@citrix.com ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC PATCH 00/19] xen/arm: Add ITS support
On Tue, 2015-03-03 at 09:32 +0530, Vijay Kilari wrote: Hi Ian, On Mon, Mar 2, 2015 at 11:09 PM, Ian Campbell ian.campb...@citrix.com wrote: Forgot one series (albeit of a single patch): On Mon, 2015-03-02 at 14:53 +, Ian Campbell wrote: There's quite a few series out there right now from you guys, with quite a number of patches in each, so I think we need to prioritise the order we deal with them. I am intending to go through them in the following order: * Basic platform support code * VMAP PTE present fix * PCI support * ITS support * Other new work (e.g. NUMA) Does that ordering suit your plans? I think we don't want to build up too much of a backlog so it would be good to put an emphasis on addressing comments resending stuff nearer the top of the list first. (With that in mind I think the basic platform device was almost there but needed a couple of minor things addressing in one patch). Agreed, But the patch series sent are completely independent. True, but maintainer bandwidth for review is not (nor is it infinite). So I just wanted to set your expectations wrt what order I would be dealing with things in (along with all the other stuff I have to review). Holding back patches will delay things. I have sent ITS patch series to get first feedback. Meanwhile, I will work on platform VMAP patches As Manish is working on PCI, Any changes to ITS driver for PCI stuff will be managed separately. Regards Vijay ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH net-next 06/14] xen: Use eth_foo_addr instead of memset
On Mon, Mar 02, 2015 at 07:54:51PM -0800, Joe Perches wrote: Use the built-in function instead of memset. Signed-off-by: Joe Perches j...@perches.com Acked-by: Wei Liu wei.l...@citrix.com --- drivers/net/xen-netback/interface.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c index f38227a..4ae98e2 100644 --- a/drivers/net/xen-netback/interface.c +++ b/drivers/net/xen-netback/interface.c @@ -438,7 +438,7 @@ struct xenvif *xenvif_alloc(struct device *parent, domid_t domid, * stolen by an Ethernet bridge for STP purposes. * (FE:FF:FF:FF:FF:FF) */ - memset(dev-dev_addr, 0xFF, ETH_ALEN); + eth_broadcast_addr(dev-dev_addr); dev-dev_addr[0] = ~0x01; netif_carrier_off(dev); -- 2.1.2 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 5/5] libxc: rumpxen: provide xc_osdep_info
Wei Liu, le Tue 03 Mar 2015 15:57:21 +, a écrit :
This allows programs which use the bulk of libxc to link. We use
/dev/xenevt for event channels, the raw minios functions for privcmd
and gnttab, and the netbsd versions of discard_file_cache and
xc_memalign.
Signed-off-by: Ian Jackson ian.jack...@eu.citrix.com
Signed-off-by: Wei Liu wei.l...@citrix.com
Acked-by: Samuel Thibault samuel.thiba...@ens-lyon.org
+static xc_osdep_handle minios_privcmd_open(xc_interface *xch)
+{
+return 1;
+}
+static xc_osdep_handle minios_gnttab_open(xc_gnttab *xcg)
+{
+return 1;
+}
Perhaps return a different fd number?
Samuel
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCHv1 1/2] xen-netback: return correct ethtool stats
Use correct pointer arithmetic to get the pointer to each stat.
Signed-off-by: David Vrabel david.vra...@citrix.com
---
drivers/net/xen-netback/interface.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/xen-netback/interface.c
b/drivers/net/xen-netback/interface.c
index f38227a..3aa8648 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -340,12 +340,11 @@ static void xenvif_get_ethtool_stats(struct net_device
*dev,
unsigned int num_queues = vif-num_queues;
int i;
unsigned int queue_index;
- struct xenvif_stats *vif_stats;
for (i = 0; i ARRAY_SIZE(xenvif_stats); i++) {
unsigned long accum = 0;
for (queue_index = 0; queue_index num_queues; ++queue_index) {
- vif_stats = vif-queues[queue_index].stats;
+ void *vif_stats = vif-queues[queue_index].stats;
accum += *(unsigned long *)(vif_stats +
xenvif_stats[i].offset);
}
data[i] = accum;
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCHv1 0/2 net] xen-netback: fix ethtool stats and memory
A couple of bug fixes for netback: - make ethool stats to report the correct values. - don't leak 1 MiB every time a VIF is destroyed. David ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RFC V2 1/5] libxl: add pvusb definitions
On 03/03/2015 11:10 AM, Ian Campbell wrote: On Mon, 2015-01-19 at 16:28 +0800, Chunyan Liu wrote: Sorry for the long delay in replying. To attach a usb device, a virtual usb controller should be created first. This patch defines usbctrl and usbdevice related structs. Per 54ca17df026600095...@relay2.provo.novell.com please could you mention here that the HVM guest related parts (i.e. LIBXL_USBCTRL_TYPE_DEVICEMODEL) and libxl_usb_type are placeholders for emulated HVM support. In fact I wonder if it should just be omitted, we will need a LIBXL_HAVE for HVM USB support anyway once it is implemented so we can add the enum then. Or will we -- do we think returning an error for such an HVM guest with USB devices configured now is acceptable and for it to silently start working at some point in the future is OK? I think that was my idea back when I was writing the HVM hotplug patches. Signed-off-by: Chunyan Liu cy...@suse.com Signed-off-by: Simon Cao caobosi...@gmail.com --- tools/libxl/libxl_types.idl | 58 +++- tools/libxl/libxl_types_internal.idl | 1 + 2 files changed, 58 insertions(+), 1 deletion(-) diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl index 1214d2e..0639434 100644 --- a/tools/libxl/libxl_types.idl +++ b/tools/libxl/libxl_types.idl @@ -521,6 +531,27 @@ libxl_device_pci = Struct(device_pci, [ (seize, bool), ]) +libxl_device_usbctrl = Struct(device_usbctrl, [ +(name, string), +(type, libxl_usbctrl_type), +(backend_domid, libxl_domid), +(backend_domname, string), +(devid, libxl_devid), +(usb_version, uint8), +(num_ports, uint8), I think int would be fine for both of these last two (and is a bit kinder to language bindings). +]) + +libxl_device_usb = Struct(device_usb, [ +(ctrl, integer), Is this an index into something? If so what? There seems to be no usbctrl array added to the domain_config struct, so I'm unsure how this is used. It looks like this is meant to specify which USB controller you're plugging your device into; and if you set it to -1, then it will automatically try to plug it into the best one (and also automatically create one for you if one doesn't exist). This should probably be a libxl_devid I'm guessing, then? -George ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] kasan_map_early_shadow() on Xen
On Tue, Mar 03, 2015 at 06:38:20PM +0300, Andrey Ryabinin wrote: On 03/03/2015 05:16 PM, Konrad Rzeszutek Wilk wrote: On Tue, Mar 03, 2015 at 04:15:06PM +0300, Andrey Ryabinin wrote: On 03/03/2015 12:40 PM, Luis R. Rodriguez wrote: Andrey, I believe that on Xen we should disable kasan, would like confirmation I guess Xen guests won't work with kasan because Xen guests doesn't setup shadow (kasan_map_early_shadow() is not called in xen guests). Disabling kasan for Xen in Kconfig is undesirable because that will disable kasan for allmodconfig and allyesconfig builds, but I don't see other option for now. Was there an bug reported for this? It would be good to CC the maintainers of Xen on that sort of thing. There was no report for this. I just looked at Xen code because of this Luis's mail and I don't see how it could work with kasan. Ahh. Fixing this might be not trivial. We need to setup shadow memory before any kasan instrumented function will run. This is like with -fstack-protector (you need to setup gdt before calling any stack protected function). If it is like that - then just using what had to be implemented for the stack protection as a template ought to pave most of the work? ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCHv1 2/2] xen-netback: unref frags when handling a from-guest skb with a frag list
Every time a VIF is destroyed up-to 256 pages may be leaked if packets
with more than MAX_SKB_FRAGS frags where transmitted from the guest.
Even worse, if another user of ballooned pages allocated one of these
ballooned pages it would not handle the the unexpectedly non-zero page
count (e.g., gntdev would deadlock when unmapping a grant because the
page count would never reach 1).
When handling a from-guest skb with a frag list, unref the frags
before releasing them so they are freed correctly when the VIF is
destroyed.
Also swap over to the new (local) frags /after/ calling the skb
destructor. This isn't strictly necessary but it's less confusing.
Signed-off-by: David Vrabel david.vra...@citrix.com
---
drivers/net/xen-netback/netback.c | 43 +++--
1 file changed, 22 insertions(+), 21 deletions(-)
diff --git a/drivers/net/xen-netback/netback.c
b/drivers/net/xen-netback/netback.c
index f7a31d2..3d06eeb 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -1343,7 +1343,7 @@ static int xenvif_handle_frag_list(struct xenvif_queue
*queue, struct sk_buff *s
{
unsigned int offset = skb_headlen(skb);
skb_frag_t frags[MAX_SKB_FRAGS];
- int i;
+ int i, nr_frags;
struct ubuf_info *uarg;
struct sk_buff *nskb = skb_shinfo(skb)-frag_list;
@@ -1357,17 +1357,16 @@ static int xenvif_handle_frag_list(struct xenvif_queue
*queue, struct sk_buff *s
skb-data_len += nskb-len;
/* create a brand new frags array and coalesce there */
- for (i = 0; offset skb-len; i++) {
+ for (nr_frags = 0; offset skb-len; nr_frags++) {
struct page *page;
unsigned int len;
- BUG_ON(i = MAX_SKB_FRAGS);
+ BUG_ON(nr_frags = MAX_SKB_FRAGS);
page = alloc_page(GFP_ATOMIC);
if (!page) {
- int j;
skb-truesize += skb-data_len;
- for (j = 0; j i; j++)
- put_page(frags[j].page.p);
+ for (i = 0; i nr_frags; i++)
+ put_page(frags[i].page.p);
return -ENOMEM;
}
@@ -1379,27 +1378,29 @@ static int xenvif_handle_frag_list(struct xenvif_queue
*queue, struct sk_buff *s
BUG();
offset += len;
- frags[i].page.p = page;
- frags[i].page_offset = 0;
- skb_frag_size_set(frags[i], len);
+ frags[nr_frags].page.p = page;
+ frags[nr_frags].page_offset = 0;
+ skb_frag_size_set(frags[nr_frags], len);
}
- /* swap out with old one */
- memcpy(skb_shinfo(skb)-frags,
- frags,
- i * sizeof(skb_frag_t));
- skb_shinfo(skb)-nr_frags = i;
- skb-truesize += i * PAGE_SIZE;
-
- /* remove traces of mapped pages and frag_list */
+
+ /* Copied all the bits from the frag list -- free it. */
skb_frag_list_init(skb);
- uarg = skb_shinfo(skb)-destructor_arg;
- /* increase inflight counter to offset decrement in callback */
+ xenvif_skb_zerocopy_prepare(queue, nskb);
+ kfree_skb(nskb);
+
+ /* Release all the original (foreign) frags. */
+ for (i = 0; i skb_shinfo(skb)-nr_frags; i++)
+ skb_frag_unref(skb, i);
atomic_inc(queue-inflight_packets);
+ uarg = skb_shinfo(skb)-destructor_arg;
uarg-callback(uarg, true);
skb_shinfo(skb)-destructor_arg = NULL;
- xenvif_skb_zerocopy_prepare(queue, nskb);
- kfree_skb(nskb);
+ /* Fill the skb with the new (local) frags. */
+ memcpy(skb_shinfo(skb)-frags, frags,
+ nr_frags * sizeof(skb_frag_t));
+ skb_shinfo(skb)-nr_frags = nr_frags;
+ skb-truesize += nr_frags * PAGE_SIZE;
return 0;
}
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH] xen/arm: gic: Correctly check if an IRQ is valid in gic_interrupt
The IRQ 1020 is reserved for special purpose, so the check should be
irq 1020 rather than irq 1021.
Signed-off-by: Julien Grall julien.gr...@linaro.org
---
xen/arch/arm/gic.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index 390c8b0..940fb8e 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -570,7 +570,7 @@ void gic_interrupt(struct cpu_user_regs *regs, int is_fiq)
/* Reading IRQ will ACK it */
irq = gic_hw_ops-read_irq();
-if ( likely(irq = 16 irq 1021) )
+if ( likely(irq = 16 irq 1020) )
{
local_irq_enable();
do_IRQ(regs, irq, is_fiq);
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH] xen/arm: gic: GICv2 GICv3 only supports 1020 physical interrupts
GICD_TYPER.ITLinesNumber can encode up to 1024 interrupts. Although,
IRQ 1020-1023 are reserved for special purpose.
This helps to check when an IRQ is valid or not.
Signed-off-by: Julien Grall julien.gr...@linaro.org
---
xen/arch/arm/gic-v2.c | 16 ++--
xen/arch/arm/gic-v3.c | 16 ++--
2 files changed, 20 insertions(+), 12 deletions(-)
diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index 20cdbc9..826a457 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -256,6 +256,7 @@ static void __init gicv2_dist_init(void)
uint32_t type;
uint32_t cpumask;
uint32_t gic_cpus;
+unsigned int nr_lines;
int i;
cpumask = readl_gicd(GICD_ITARGETSR) 0xff;
@@ -266,31 +267,34 @@ static void __init gicv2_dist_init(void)
writel_gicd(0, GICD_CTLR);
type = readl_gicd(GICD_TYPER);
-gicv2_info.nr_lines = 32 * ((type GICD_TYPE_LINES) + 1);
+nr_lines = 32 * ((type GICD_TYPE_LINES) + 1);
gic_cpus = 1 + ((type GICD_TYPE_CPUS) 5);
printk(GICv2: %d lines, %d cpu%s%s (IID %8.8x).\n,
- gicv2_info.nr_lines, gic_cpus, (gic_cpus == 1) ? : s,
+ nr_lines, gic_cpus, (gic_cpus == 1) ? : s,
(type GICD_TYPE_SEC) ? , secure : ,
readl_gicd(GICD_IIDR));
/* Default all global IRQs to level, active low */
-for ( i = 32; i gicv2_info.nr_lines; i += 16 )
+for ( i = 32; i nr_lines; i += 16 )
writel_gicd(0x0, GICD_ICFGR + (i / 16) * 4);
/* Route all global IRQs to this CPU */
-for ( i = 32; i gicv2_info.nr_lines; i += 4 )
+for ( i = 32; i nr_lines; i += 4 )
writel_gicd(cpumask, GICD_ITARGETSR + (i / 4) * 4);
/* Default priority for global interrupts */
-for ( i = 32; i gicv2_info.nr_lines; i += 4 )
+for ( i = 32; i nr_lines; i += 4 )
writel_gicd(GIC_PRI_IRQ 24 | GIC_PRI_IRQ 16 |
GIC_PRI_IRQ 8 | GIC_PRI_IRQ,
GICD_IPRIORITYR + (i / 4) * 4);
/* Disable all global interrupts */
-for ( i = 32; i gicv2_info.nr_lines; i += 32 )
+for ( i = 32; i nr_lines; i += 32 )
writel_gicd(~0x0, GICD_ICENABLER + (i / 32) * 4);
+/* Only 1020 interrupts are supported */
+gicv2_info.nr_lines = min((unsigned)1020, nr_lines);
+
/* Turn on the distributor */
writel_gicd(GICD_CTL_ENABLE, GICD_CTLR);
}
diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index ab80670..99a3b9a 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -528,23 +528,24 @@ static void __init gicv3_dist_init(void)
uint32_t type;
uint32_t priority;
uint64_t affinity;
+unsigned int nr_lines;
int i;
/* Disable the distributor */
writel_relaxed(0, GICD + GICD_CTLR);
type = readl_relaxed(GICD + GICD_TYPER);
-gicv3_info.nr_lines = 32 * ((type GICD_TYPE_LINES) + 1);
+nr_lines = 32 * ((type GICD_TYPE_LINES) + 1);
printk(GICv3: %d lines, (IID %8.8x).\n,
- gicv3_info.nr_lines, readl_relaxed(GICD + GICD_IIDR));
+ nr_lines, readl_relaxed(GICD + GICD_IIDR));
/* Default all global IRQs to level, active low */
-for ( i = NR_GIC_LOCAL_IRQS; i gicv3_info.nr_lines; i += 16 )
+for ( i = NR_GIC_LOCAL_IRQS; i nr_lines; i += 16 )
writel_relaxed(0, GICD + GICD_ICFGR + (i / 16) * 4);
/* Default priority for global interrupts */
-for ( i = NR_GIC_LOCAL_IRQS; i gicv3_info.nr_lines; i += 4 )
+for ( i = NR_GIC_LOCAL_IRQS; i nr_lines; i += 4 )
{
priority = (GIC_PRI_IRQ 24 | GIC_PRI_IRQ 16 |
GIC_PRI_IRQ 8 | GIC_PRI_IRQ);
@@ -552,7 +553,7 @@ static void __init gicv3_dist_init(void)
}
/* Disable all global interrupts */
-for ( i = NR_GIC_LOCAL_IRQS; i gicv3_info.nr_lines; i += 32 )
+for ( i = NR_GIC_LOCAL_IRQS; i nr_lines; i += 32 )
writel_relaxed(0x, GICD + GICD_ICENABLER + (i / 32) * 4);
gicv3_dist_wait_for_rwp();
@@ -566,8 +567,11 @@ static void __init gicv3_dist_init(void)
/* Make sure we don't broadcast the interrupt */
affinity = ~GICD_IROUTER_SPI_MODE_ANY;
-for ( i = NR_GIC_LOCAL_IRQS; i gicv3_info.nr_lines; i++ )
+for ( i = NR_GIC_LOCAL_IRQS; i nr_lines; i++ )
writeq_relaxed(affinity, GICD + GICD_IROUTER + i * 8);
+
+/* Only 1020 interrupts are supported */
+gicv3_info.nr_lines = min((unsigned)1020, nr_lines);
}
static int gicv3_enable_redist(void)
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] kasan_map_early_shadow() on Xen
On 03/03/2015 12:40 PM, Luis R. Rodriguez wrote: Andrey, I believe that on Xen we should disable kasan, would like confirmation I guess Xen guests won't work with kasan because Xen guests doesn't setup shadow (kasan_map_early_shadow() is not called in xen guests). Disabling kasan for Xen in Kconfig is undesirable because that will disable kasan for allmodconfig and allyesconfig builds, but I don't see other option for now. from someone on xen-devel though. Here's the thing though -- if true -- I'd like to do it *properly*, where *properly* means addressing a bit of architecture. A simple Kconfig slap seems rather reactive. I'd like to address a way to properly ensure we don't run into this and other similar issues in the future. The CR4 shadow issue was another recent example issue, also introduced via v4.0 [0]. We can't keep doing this reactively. Let's go down the rabbit hole for a bit. HAVE_ARCH_KASAN will be selected on x86 when: if X86_64 SPARSEMEM_VMEMMAP Now Xen should not have SPARSEMEM_VMEMMAP but PVOPs' goal is to enable distributions to be able to have a single binary kernels and let the rest be figured out, so we can't just disable SPARSEMEM_VMEMMAP for Xen alone, we want to build Xen.. or part of Xen and perhaps keep SPARSEMEM_VMEMMAP, and only later figure things out. How do we do this cleanly and avoid future reactive measures? If the answer is not upon us, I'd like to at least highlight the issue so that in case we do come up with something its no surprise PVOPs is falling short for that single binary pipe dream right now. [0] https://lkml.org/lkml/2015/2/23/328 Luis ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [OSSTEST PATCH 2/3] allow files: Support negation syntax
We now support !pattern, which undoes the effect of a pattern
specified previously (perhaps in another file).
Note that the logic is a bit poor: !... only undoes the effect of an
identical (or equivalent) earlier pattern; it doesn't provide a
specific override.
Improving that would involve a more invasive change to
sg-report-flight which I don't want to do right now.
Signed-off-by: Ian Jackson ian.jack...@eu.citrix.com
---
sg-report-flight | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/sg-report-flight b/sg-report-flight
index 062107a..7d804fa 100755
--- a/sg-report-flight
+++ b/sg-report-flight
@@ -76,13 +76,20 @@ while (@ARGV $ARGV[0] =~ m/^-/) {
next unless m/\S/;
next if m/^\#/;
s/\s+/ /g;
+ my $remove = s/^!\s*//;
die if m/ /g 1;
$_ .= ' @@' unless m/ /;
s/\@\@/ '[^ ]*' /ge;
s/\@/ '[^ -\/]*' /ge;
$_= '^(?:'.$_.')$';
-print DEBUG ALLOW $_\n;
-push @allows, $_;
+ my $entry = $_;
+if (!$remove) {
+ print DEBUG ALLOW $entry\n;
+ push @allows, $entry;
+ } else {
+ print DEBUG DEWALLOW $entry\n;
+ @allows = grep { $_ ne $entry } @allows;
+ }
}
A-error and die $allowfile $!;
close A or die $allowfile $!;
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [OSSTEST PATCH 1/3] allow files: Pass branch-specific allow file last to sg-report-flight
We are going to make it possible for a branch-specific allow file to
override general allow information from allow.all.
No functional change yet.
Signed-off-by: Ian Jackson ian.jack...@eu.citrix.com
---
cri-args-hostlists |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/cri-args-hostlists b/cri-args-hostlists
index 57958d3..2ee0b7b 100644
--- a/cri-args-hostlists
+++ b/cri-args-hostlists
@@ -112,7 +112,7 @@ start_email () {
./sg-report-job-history --html-dir=$job_html_dir --flight=$flight
./sg-report-flight --html-dir=$flight_html_dir/$flight/ \
- --allow=allow.$branch --allow=allow.all \
+ --allow=allow.all --allow=allow.$branch \
$sgr_args $flight
}
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [OSSTEST PATCH 3/3] allow files: Allow all libvirt test failures on other branches
We have a problem where virtd crashes, and this is causing problems for other branches. So ignore libvirt test failures. Use the new ability to override allowances to cause libvirt failures to still block libvirt pushes. Signed-off-by: Ian Jackson ian.jack...@eu.citrix.com --- allow.all |2 +- allow.libvirt |1 + 2 files changed, 2 insertions(+), 1 deletion(-) create mode 100644 allow.libvirt diff --git a/allow.all b/allow.all index fd2aa25..aab5721 100644 --- a/allow.all +++ b/allow.all @@ -2,4 +2,4 @@ test-@@-sedf@@ build-@@logs-capture@@ test-@@-pcipt@@ test-@@-qemuu-@@ guest-localmigrate -test-@@-libvirt@@ guest-start +test-@@-libvirt@@ diff --git a/allow.libvirt b/allow.libvirt new file mode 100644 index 000..abc7669 --- /dev/null +++ b/allow.libvirt @@ -0,0 +1 @@ +!test-@@-libvirt@@ -- 1.7.10.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [rumpuserxen test] 35788: regressions - FAIL
flight 35788 rumpuserxen real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/35788/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-rumpuserxen6 xen-build fail REGR. vs. 33866 build-amd64-rumpuserxen 6 xen-build fail REGR. vs. 33866 Tests which did not succeed, but are not blocking: test-amd64-amd64-rumpuserxen-amd64 1 build-check(1) blocked n/a test-amd64-i386-rumpuserxen-i386 1 build-check(1) blocked n/a version targeted for testing: rumpuserxen a08e18716981ad9006e52530750b1caa83d73f46 baseline version: rumpuserxen 30d72f3fc5e35cd53afd82c8179cc0e0b11146ad People who touched revisions under test: Antti Kantee po...@iki.fi Ian Jackson ian.jack...@eu.citrix.com Martin Lucina mar...@lucina.net jobs: build-amd64 pass build-i386 pass build-amd64-pvopspass build-i386-pvops pass build-amd64-rumpuserxen fail build-i386-rumpuserxen fail test-amd64-amd64-rumpuserxen-amd64 blocked test-amd64-i386-rumpuserxen-i386 blocked sg-report-flight on osstest.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 345 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [libvirt test] 35800: regressions - FAIL
flight 35800 libvirt real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/35800/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-libvirt 13 guest-destroy fail REGR. vs. 35524 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-libvirt 9 guest-start fail like 35524 Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 10 migrate-support-checkfail never pass test-amd64-i386-libvirt 10 migrate-support-checkfail never pass version targeted for testing: libvirt 1723cad6e735ddf998f70cb7504e55518207cff1 baseline version: libvirt 719cd2182bf06196b26204a8cf88d28001b1d79b People who touched revisions under test: Daniel Veillard veill...@redhat.com Ján Tomko jto...@redhat.com Michal Privoznik mpriv...@redhat.com Peter Krempa pkre...@redhat.com jobs: build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-libvirt fail test-armhf-armhf-libvirt fail test-amd64-i386-libvirt pass sg-report-flight on osstest.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. commit 1723cad6e735ddf998f70cb7504e55518207cff1 Author: Daniel Veillard veill...@redhat.com Date: Mon Mar 2 11:40:05 2015 +0800 Release of libvirt-1.2.13 commit 75b4c5cf8dbb8a43674e0eae44ebf4215a99106a Author: Michal Privoznik mpriv...@redhat.com Date: Fri Feb 27 16:11:25 2015 +0100 docs: Add mist.io as libvirt-based application As reported on the libvirt-users list [1], there's new web application called mist.io which uses libvirt as one of its backends. Lets add it into our list of libivrt based applications. 1: https://www.redhat.com/archives/libvirt-users/2015-February/msg00096.html Signed-off-by: Michal Privoznik mpriv...@redhat.com commit c75f42f3318463b0555edac333c8f20d54b4d5dc Author: Ján Tomko jto...@redhat.com Date: Fri Feb 27 11:55:40 2015 +0100 Really fix XML formatting flags in SaveImageUpdateDef Commit cf2d4c6 used a logical or instead of bitwise or, effectively passing 1, that is VIR_DOMAIN_XML_INACTIVE. This was caught by a warning when building with clang. https://bugzilla.redhat.com/show_bug.cgi?id=1183869 commit 8c45e8bec887fba6a5b0f8cc5c2c9d310cfa3deb Author: Ján Tomko jto...@redhat.com Date: Thu Feb 26 14:33:26 2015 +0100 Ignore listen attribute of graphics for type network listens Commit 6992994 started filling the listen attribute of the parent graphics elements from type='network' listens. When this XML is passed to UpdateDevice, parsing fails: XML error: graphics listen attribute 10.20.30.40 must match address attribute of first listen element (found none) Ignore the address in the parent graphics attribute when no type='address' listens are found, the same we ignore the address for the listen subelements when parsing inactive XML. commit ef2e6f4089a14d734df158dccdef429dbebbe810 Author: Peter Krempa pkre...@redhat.com Date: Thu Feb 26 10:35:47 2015 +0100 util: storage: Fix error type in virStorageSourceParseBackingURI The gluster volume name extraction code was copied from the XML parser without changing the VIR_ERR_XML_ERROR error code. Use VIR_ERR_CONFIG_UNSUPPORTED instead. commit fc56ecd73520d3a3680d6f7500944298a99f254d Author: Peter Krempa pkre...@redhat.com Date: Thu Feb 26 10:28:21 2015 +0100 util: storagefile: Don't crash on gluster URIs without path Similar to commit fdb80ed4f6563928b9942a0d1450e0c725aa6c06 libvirtd would crash if a gluster URI without path would be used in the backing chain of a volume. The crash happens in the gluster specific part of the parser that extracts the gluster volume
Re: [Xen-devel] [PATCH v2 5/5] libxc: rumpxen: provide xc_osdep_info
On Tue, Mar 03, 2015 at 04:41:23PM +, Wei Liu wrote:
On Tue, Mar 03, 2015 at 05:05:29PM +0100, Samuel Thibault wrote:
Wei Liu, le Tue 03 Mar 2015 15:57:21 +, a écrit :
This allows programs which use the bulk of libxc to link. We use
/dev/xenevt for event channels, the raw minios functions for privcmd
and gnttab, and the netbsd versions of discard_file_cache and
xc_memalign.
Signed-off-by: Ian Jackson ian.jack...@eu.citrix.com
Signed-off-by: Wei Liu wei.l...@citrix.com
Acked-by: Samuel Thibault samuel.thiba...@ens-lyon.org
+static xc_osdep_handle minios_privcmd_open(xc_interface *xch)
+{
+return 1;
+}
+static xc_osdep_handle minios_gnttab_open(xc_gnttab *xcg)
+{
+return 1;
+}
Perhaps return a different fd number?
After thinking a bit more I think we should use alloc_fd(FTYPE_*) for
all file descriptor allocation.
(Sorry for speaking to myself)
Just tried that, failed.
Rump kernel doesn't use mini-os's fd management facility so there is no
alloc_fd etc. On the other hand this makes me think number 1 is as good
as any other number we can use.
Wei.
Wei.
Samuel
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 5/5] libxc: rumpxen: provide xc_osdep_info
Wei Liu, le Tue 03 Mar 2015 16:41:23 +, a écrit :
On Tue, Mar 03, 2015 at 05:05:29PM +0100, Samuel Thibault wrote:
Wei Liu, le Tue 03 Mar 2015 15:57:21 +, a écrit :
This allows programs which use the bulk of libxc to link. We use
/dev/xenevt for event channels, the raw minios functions for privcmd
and gnttab, and the netbsd versions of discard_file_cache and
xc_memalign.
Signed-off-by: Ian Jackson ian.jack...@eu.citrix.com
Signed-off-by: Wei Liu wei.l...@citrix.com
Acked-by: Samuel Thibault samuel.thiba...@ens-lyon.org
+static xc_osdep_handle minios_privcmd_open(xc_interface *xch)
+{
+return 1;
+}
+static xc_osdep_handle minios_gnttab_open(xc_gnttab *xcg)
+{
+return 1;
+}
Perhaps return a different fd number?
After thinking a bit more I think we should use alloc_fd(FTYPE_*) for
all file descriptor allocation.
That would make sense, yes.
Samuel
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 2/2] flask: create unified flask= boot parameter
This unifies the flask_enforcing and flask_enabled boot parameters into a single parameter with additional states. Defined options are: force - require policy to be loaded at boot time and enforce it late - bootloader policy is not used; later loadpolicy is enforcing permissive - a missing or broken policy does not panic disabled - revert to dummy (no XSM) policy. Was flask_enabled=0 The default mode remains permissive and the flask_enforcing boot parameter is retained for compatibility. If flask_enforcing=1 is specified and flask= is not, the bootloader policy will be loaded in enforcing mode if present, but errors will disable access controls until a successful loadpolicy instead of causing a panic at boot. Suggested-by: Julien Grall julien.gr...@linaro.org Signed-off-by: Daniel De Graaf dgde...@tycho.nsa.gov --- docs/man/xl.pod.1| 4 ++-- docs/misc/xsm-flask.txt | 48 +++- xen/xsm/flask/flask_op.c | 34 xen/xsm/flask/hooks.c| 22 ++ xen/xsm/flask/include/security.h | 8 ++- 5 files changed, 75 insertions(+), 41 deletions(-) diff --git a/docs/man/xl.pod.1 b/docs/man/xl.pod.1 index 6b89ba8..48b8f98 100644 --- a/docs/man/xl.pod.1 +++ b/docs/man/xl.pod.1 @@ -1441,8 +1441,8 @@ Determine if the FLASK security module is loaded and enforcing its policy. =item Bsetenforce I1|0|Enforcing|Permissive Enable or disable enforcing of the FLASK access controls. The default is -permissive and can be changed using the flask_enforcing option on the -hypervisor's command line. +permissive, but this can be changed to enforcing by specifying flask=enforcing +or flask=late on the hypervisor's command line. =item Bloadpolicy Ipolicy-file diff --git a/docs/misc/xsm-flask.txt b/docs/misc/xsm-flask.txt index 9559028..efe8d50 100644 --- a/docs/misc/xsm-flask.txt +++ b/docs/misc/xsm-flask.txt @@ -400,28 +400,26 @@ may require multiple passes to find all required ranges. Additional notes on XSM:FLASK - -1) xen command line parameters - - a) flask_enforcing - - The default value for flask_enforcing is '0'. This parameter causes the - platform to boot in permissive mode which means that the policy is loaded - but not enforced. This mode is often helpful for developing new systems - and policies as the policy violations are reported on the xen console and - may be viewed in dom0 through 'xl dmesg'. - - To boot the platform into enforcing mode, which means that the policy is - loaded and enforced, append 'flask_enforcing=1' on the grub line. - - This parameter may also be changed through the flask hypercall. - - b) flask_enabled - - The default value for flask_enabled is '1'. This parameter causes the - platform to enable the FLASK security module under the XSM framework. - The parameter may be enabled/disabled only once per boot. If the parameter - is set to '0', only a reboot can re-enable flask. When flask_enabled is '0' - the DUMMY module is enforced. - - This parameter may also be changed through the flask hypercall. But may - only be performed once per boot. +The xen command line accepts these values for the flask= parameter: + + * permissive [default] + This is intended for development and is not suitable for use with untrusted + guests. If a policy is provided by the bootloader, it will be loaded; + errors will be reported to the ring buffer but will not prevent booting. + The policy can be changed to enforcing mode using xl setenforce. + * force or enforcing + This requires a security policy to be provided by the bootloader and will + enable enforcing prior to the creation of domain 0. If a valid policy is + not provided, the hypervisor will not continue booting. + * late + This disabled loading of the security policy from the bootloader. FLASK + will be enabled but will not enforce access controls until a policy is + loaded by a domain using xl loadpolicy or similar commands. Once a + policy is loaded, FLASK will run in enforcing mode unless xl setenforce + has disabled this. + * disabled + This causes the XSM framework to revert to the dummy module. The dummy + module provides the same security policy as is used when compiling the + hypervisor without support for XSM. The xsm_op hypercall can be used to + switch to this mode after boot, but there is no way to re-enable FLASK + once the dummy module is loaded. diff --git a/xen/xsm/flask/flask_op.c b/xen/xsm/flask/flask_op.c index 0e89360..8db9b1e 100644 --- a/xen/xsm/flask/flask_op.c +++ b/xen/xsm/flask/flask_op.c @@ -24,11 +24,12 @@ #define _copy_to_guest copy_to_guest #define _copy_from_guest copy_from_guest -int flask_enforcing = 0;
[Xen-devel] [PATCH v3 0/2] flask: Handle policy load failures properly
This series has changed quite a bit from v2; the focus has changed from fixing the behavior on failed policy loads to adding the flask= boot parameter. The first patch, which is purely cleanup with no functional changes, was extracted to simplify review. [PATCH 1/2] flask: clean up initialization and #defines [PATCH 2/2] flask: create unified flask= boot parameter ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 1/2] flask: clean up initialization and #defines
This removes the FLASK_DEVELOP and FLASK_BOOTPARAM configuration
parameters which have never been settable by users. Disabling the
FLASK_DEVELOP configuration option has not produced a compiling
hypervisor for some time, and the FLASK_BOOTPARAM option will be
replaced with a more flexible boot parameter.
This also changes the return type of xsm_initcall_t to void to properly
reflect the fact that the caller ignores the return value.
Signed-off-by: Daniel De Graaf dgde...@tycho.nsa.gov
---
xen/include/xen/config.h | 4
xen/include/xsm/xsm.h| 2 +-
xen/xsm/flask/avc.c | 2 --
xen/xsm/flask/flask_op.c | 4
xen/xsm/flask/hooks.c| 6 ++
xen/xsm/flask/include/avc.h | 4
xen/xsm/flask/include/security.h | 5 -
7 files changed, 3 insertions(+), 24 deletions(-)
diff --git a/xen/include/xen/config.h b/xen/include/xen/config.h
index 7bef8a6..d3d9911 100644
--- a/xen/include/xen/config.h
+++ b/xen/include/xen/config.h
@@ -100,10 +100,6 @@
#ifdef FLASK_ENABLE
#define XSM_MAGIC 0xf97cff8c
-/* Enable permissive mode (xl setenforce or flask_enforcing parameter) */
-#define FLASK_DEVELOP 1
-/* Allow runtime disabling of FLASK via the flask_enable parameter */
-#define FLASK_BOOTPARAM 1
/* Maintain statistics on the access vector cache */
#define FLASK_AVC_STATS 1
#endif
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index 4ce089f..0437735 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -42,7 +42,7 @@ typedef enum xsm_default xsm_default_t;
extern char *policy_buffer;
extern u32 policy_size;
-typedef int (*xsm_initcall_t)(void);
+typedef void (*xsm_initcall_t)(void);
extern xsm_initcall_t __xsm_initcall_start[], __xsm_initcall_end[];
diff --git a/xen/xsm/flask/avc.c b/xen/xsm/flask/avc.c
index fc6580e..b1a4f8a 100644
--- a/xen/xsm/flask/avc.c
+++ b/xen/xsm/flask/avc.c
@@ -251,8 +251,6 @@ void __init avc_init(void)
}
atomic_set(avc_cache.active_nodes, 0);
atomic_set(avc_cache.lru_hint, 0);
-
-printk(AVC INITIALIZED\n);
}
int avc_get_hash_stats(struct xen_flask_hash_stats *arg)
diff --git a/xen/xsm/flask/flask_op.c b/xen/xsm/flask/flask_op.c
index 7743aac..0e89360 100644
--- a/xen/xsm/flask/flask_op.c
+++ b/xen/xsm/flask/flask_op.c
@@ -24,15 +24,11 @@
#define _copy_to_guest copy_to_guest
#define _copy_from_guest copy_from_guest
-#ifdef FLASK_DEVELOP
int flask_enforcing = 0;
integer_param(flask_enforcing, flask_enforcing);
-#endif
-#ifdef FLASK_BOOTPARAM
int flask_enabled = 1;
integer_param(flask_enabled, flask_enabled);
-#endif
#define MAX_POLICY_SIZE 0x400
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 65094bb..dad5deb 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -1626,14 +1626,14 @@ static struct xsm_operations flask_ops = {
#endif
};
-static __init int flask_init(void)
+static __init void flask_init(void)
{
int ret = 0;
if ( !flask_enabled )
{
printk(Flask: Disabled at boot.\n);
-return 0;
+return;
}
printk(Flask: Initializing.\n);
@@ -1650,8 +1650,6 @@ static __init int flask_init(void)
printk(Flask: Starting in enforcing mode.\n);
else
printk(Flask: Starting in permissive mode.\n);
-
-return ret;
}
xsm_initcall(flask_init);
diff --git a/xen/xsm/flask/include/avc.h b/xen/xsm/flask/include/avc.h
index 42a5e4b..a00a6eb 100644
--- a/xen/xsm/flask/include/avc.h
+++ b/xen/xsm/flask/include/avc.h
@@ -17,11 +17,7 @@
#include av_permissions.h
#include security.h
-#ifdef FLASK_DEVELOP
extern int flask_enforcing;
-#else
-#define flask_enforcing 1
-#endif
/*
* An entry in the AVC.
diff --git a/xen/xsm/flask/include/security.h b/xen/xsm/flask/include/security.h
index 348f018..dea0143 100644
--- a/xen/xsm/flask/include/security.h
+++ b/xen/xsm/flask/include/security.h
@@ -35,12 +35,7 @@
#define POLICYDB_VERSION_MIN POLICYDB_VERSION_BASE
#define POLICYDB_VERSION_MAX POLICYDB_VERSION_BOUNDARY
-#ifdef FLASK_BOOTPARAM
extern int flask_enabled;
-#else
-#define flask_enabled 1
-#endif
-
extern int flask_mls_enabled;
int security_load_policy(void * data, size_t len);
--
2.1.0
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] 4.4.2-rc2 and 4.3.4-rc2 have been tagged
All, aiming at releases with, as before, presumably no further RC on both of the branches (even more so with the long delay already incurred), please test! (The plan however is to incorporate the fixes for the XSAs that are going to go public during the next several days; unless something extremely important shows up, the expectation is for no other changes to go in before the release.) To remind you, 4.3.4 is expected to be the last xen.org coordinated release on the 4.3 series. Thanks, Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 5/5] libxc: rumpxen: provide xc_osdep_info
On Tue, Mar 03, 2015 at 05:05:29PM +0100, Samuel Thibault wrote:
Wei Liu, le Tue 03 Mar 2015 15:57:21 +, a écrit :
This allows programs which use the bulk of libxc to link. We use
/dev/xenevt for event channels, the raw minios functions for privcmd
and gnttab, and the netbsd versions of discard_file_cache and
xc_memalign.
Signed-off-by: Ian Jackson ian.jack...@eu.citrix.com
Signed-off-by: Wei Liu wei.l...@citrix.com
Acked-by: Samuel Thibault samuel.thiba...@ens-lyon.org
+static xc_osdep_handle minios_privcmd_open(xc_interface *xch)
+{
+return 1;
+}
+static xc_osdep_handle minios_gnttab_open(xc_gnttab *xcg)
+{
+return 1;
+}
Perhaps return a different fd number?
After thinking a bit more I think we should use alloc_fd(FTYPE_*) for
all file descriptor allocation.
Wei.
Samuel
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCHv1 2/2] xen-netback: unref frags when handling a from-guest skb with a frag list
On 03/03/15 16:26, David Vrabel wrote:
Every time a VIF is destroyed up-to 256 pages may be leaked if packets
up to (and maybe a comma before it?)
with more than MAX_SKB_FRAGS frags where transmitted from the guest.
were
Even worse, if another user of ballooned pages allocated one of these
ballooned pages it would not handle the the unexpectedly non-zero page
^^^
One too many the
count (e.g., gntdev would deadlock when unmapping a grant because the
page count would never reach 1).
When handling a from-guest skb with a frag list, unref the frags
before releasing them so they are freed correctly when the VIF is
destroyed.
Also swap over to the new (local) frags /after/ calling the skb
destructor. This isn't strictly necessary but it's less confusing.
Signed-off-by: David Vrabel david.vra...@citrix.com
Reviewed-by: Zoltan Kiss zoltan.k...@linaro.org
---
drivers/net/xen-netback/netback.c | 43 +++--
1 file changed, 22 insertions(+), 21 deletions(-)
diff --git a/drivers/net/xen-netback/netback.c
b/drivers/net/xen-netback/netback.c
index f7a31d2..3d06eeb 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -1343,7 +1343,7 @@ static int xenvif_handle_frag_list(struct xenvif_queue
*queue, struct sk_buff *s
{
unsigned int offset = skb_headlen(skb);
skb_frag_t frags[MAX_SKB_FRAGS];
- int i;
+ int i, nr_frags;
struct ubuf_info *uarg;
struct sk_buff *nskb = skb_shinfo(skb)-frag_list;
@@ -1357,17 +1357,16 @@ static int xenvif_handle_frag_list(struct xenvif_queue
*queue, struct sk_buff *s
skb-data_len += nskb-len;
/* create a brand new frags array and coalesce there */
- for (i = 0; offset skb-len; i++) {
+ for (nr_frags = 0; offset skb-len; nr_frags++) {
struct page *page;
unsigned int len;
- BUG_ON(i = MAX_SKB_FRAGS);
+ BUG_ON(nr_frags = MAX_SKB_FRAGS);
page = alloc_page(GFP_ATOMIC);
if (!page) {
- int j;
skb-truesize += skb-data_len;
- for (j = 0; j i; j++)
- put_page(frags[j].page.p);
+ for (i = 0; i nr_frags; i++)
+ put_page(frags[i].page.p);
return -ENOMEM;
}
@@ -1379,27 +1378,29 @@ static int xenvif_handle_frag_list(struct xenvif_queue
*queue, struct sk_buff *s
BUG();
offset += len;
- frags[i].page.p = page;
- frags[i].page_offset = 0;
- skb_frag_size_set(frags[i], len);
+ frags[nr_frags].page.p = page;
+ frags[nr_frags].page_offset = 0;
+ skb_frag_size_set(frags[nr_frags], len);
}
- /* swap out with old one */
- memcpy(skb_shinfo(skb)-frags,
- frags,
- i * sizeof(skb_frag_t));
- skb_shinfo(skb)-nr_frags = i;
- skb-truesize += i * PAGE_SIZE;
-
- /* remove traces of mapped pages and frag_list */
+
+ /* Copied all the bits from the frag list -- free it. */
skb_frag_list_init(skb);
- uarg = skb_shinfo(skb)-destructor_arg;
- /* increase inflight counter to offset decrement in callback */
+ xenvif_skb_zerocopy_prepare(queue, nskb);
+ kfree_skb(nskb);
+
+ /* Release all the original (foreign) frags. */
+ for (i = 0; i skb_shinfo(skb)-nr_frags; i++)
+ skb_frag_unref(skb, i);
atomic_inc(queue-inflight_packets);
+ uarg = skb_shinfo(skb)-destructor_arg;
uarg-callback(uarg, true);
skb_shinfo(skb)-destructor_arg = NULL;
- xenvif_skb_zerocopy_prepare(queue, nskb);
- kfree_skb(nskb);
+ /* Fill the skb with the new (local) frags. */
+ memcpy(skb_shinfo(skb)-frags, frags,
+ nr_frags * sizeof(skb_frag_t));
+ skb_shinfo(skb)-nr_frags = nr_frags;
+ skb-truesize += nr_frags * PAGE_SIZE;
return 0;
}
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 5/5] libxc: rumpxen: provide xc_osdep_info
Wei Liu, le Tue 03 Mar 2015 16:58:07 +, a écrit : Rump kernel doesn't use mini-os's fd management facility so there is no alloc_fd etc. On the other hand this makes me think number 1 is as good as any other number we can use. Does Rump have not fd at all? It'd probably still be good to have different, even if hardcoded, fd numbers, for potentially easier debugging. Samuel ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH] libxl: Correct license header on libxl_flask.c to be LGPL
libxl is intended to be an LGPL 2.1 licensed library, however this file inadvertently got given a GPL header. The following people have touched this file, although all but Machon's contributions are trivial and/or mechanical an Ack from each would be unambiguous: $ git log --format='%an %aE' tools/libxl/libxl_flask.c | sort -u Ian Campbell ian.campb...@citrix.com Ian Jackson ian.jack...@eu.citrix.com Machon Gregory mbgr...@tycho.ncsc.mil Wei Liu l...@liuw.name $ Signed-off-by: Ian Campbell ian.campb...@citrix.com Cc: Ian Jackson ian.jack...@eu.citrix.com Cc: Machon Gregory mbgr...@tycho.ncsc.mil Cc: Wei Liu l...@liuw.name Cc: Daniel De Graaf dgde...@tycho.nsa.gov --- Machon, as the majority author of this file are you OK with this change? Ian, this should be a candidate for backport I think. --- tools/libxl/libxl_flask.c | 13 + 1 file changed, 9 insertions(+), 4 deletions(-) diff --git a/tools/libxl/libxl_flask.c b/tools/libxl/libxl_flask.c index 23f2476..38347a3 100644 --- a/tools/libxl/libxl_flask.c +++ b/tools/libxl/libxl_flask.c @@ -1,10 +1,15 @@ /* - * * Author: Machon Gregory, mbgr...@tycho.ncsc.mil * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License version 2, - * as published by the Free Software Foundation. + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU Lesser General Public License as published + * by the Free Software Foundation; version 2.1 only. with the special + * exception on linking described in file LICENSE. + * + * 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 Lesser General Public License for more details. */ #include libxl_osdeps.h /* must come before any other headers */ -- 1.7.10.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] libxl: Correct license header on libxl_flask.c to be LGPL
Ian Campbell writes ([PATCH] libxl: Correct license header on libxl_flask.c to be LGPL): libxl is intended to be an LGPL 2.1 licensed library, however this file inadvertently got given a GPL header. The following people have touched this file, although all but Machon's contributions are trivial and/or mechanical an Ack from each would be unambiguous: $ git log --format='%an %aE' tools/libxl/libxl_flask.c | sort -u Ian Campbell ian.campb...@citrix.com Ian Jackson ian.jack...@eu.citrix.com Acked-by: Ian Jackson ian.jack...@eu.citrix.com ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] x86/xen: Initialize cr4 shadow for 64-bit PV(H) guests
On March 3, 2015 1:15:42 PM EST, Luis R. Rodriguez mcg...@suse.com wrote: On Tue, Mar 03, 2015 at 09:27:34AM -0500, Boris Ostrovsky wrote: On 03/03/2015 12:35 AM, Luis R. Rodriguez wrote: On Mon, Feb 23, 2015 at 9:09 AM, David Vrabel david.vra...@citrix.com wrote: On 23/02/15 16:01, Boris Ostrovsky wrote: Commit 1e02ce4cccdc (x86: Store a per-cpu shadow copy of CR4) introduced CR4 shadows. These shadows are initialized in early boot code. The commit missed initialization for 64-bit PV(H) guests that this patch adds. Applied to stable/for-linus-4.0, thanks. Boris, can you kick of a set of tests on this branch, please? Do we know worst case what should blow up without this commit ? PVH guest will crash. Oh wow that is serious. And this is a reactive measure to a change upstream, it might be hard but it'd be nice if we can have a proactive architecture to address this. Don't mind me though, I realize this seems hard, just thinking out loud right now. Did you find it through code inspection or a test? Boris runs every night on different hardware an regression test against the latest Linux kernel. Luis L ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC PATCH 09/19] xen/arm: Update irq descriptor for LPIs support
On Mon, 2 Mar 2015, vijay.kil...@gmail.com wrote:
From: Vijaya Kumar K vijaya.ku...@caviumnetworks.com
Introduce new fields in irq descriptors for
LPI support. data field to hold irq related data
and virq to hold virtual lpi number for the corresponding
irq
Signed-off-by: Vijaya Kumar K vijaya.ku...@caviumnetworks.com
---
xen/arch/arm/irq.c| 18 ++
xen/include/asm-arm/irq.h |3 ++-
xen/include/xen/irq.h |2 ++
3 files changed, 22 insertions(+), 1 deletion(-)
diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c
index cb9c99b..d52ee0c 100644
--- a/xen/arch/arm/irq.c
+++ b/xen/arch/arm/irq.c
@@ -89,6 +89,7 @@ static int __cpuinit init_local_irq_data(void)
init_one_irq_desc(desc);
desc-irq = irq;
desc-action = NULL;
+desc-data = NULL;
/* PPIs are included in local_irqs, we copy the IRQ type from
* local_irqs_type when bringing up local IRQ for this CPU in
@@ -104,6 +105,23 @@ static int __cpuinit init_local_irq_data(void)
return 0;
}
+int irq_set_desc_data(unsigned int irq, void *d)
+{
+unsigned long flags;
+struct irq_desc *desc = irq_to_desc(irq);
+
+spin_lock_irqsave(desc-lock, flags);
+desc-data = d;
+spin_unlock_irqrestore(desc-lock, flags);
+
+return 0;
+}
+
+void *irq_get_desc_data(struct irq_desc *d)
+{
+return d-data;
If you have spin_locks in irq_set_desc_data, you also need them in
irq_get_desc_data.
+}
+
void __init init_IRQ(void)
{
int irq;
diff --git a/xen/include/asm-arm/irq.h b/xen/include/asm-arm/irq.h
index 435dfcd..de029e4 100644
--- a/xen/include/asm-arm/irq.h
+++ b/xen/include/asm-arm/irq.h
@@ -46,7 +46,8 @@ void arch_move_irqs(struct vcpu *v);
/* Set IRQ type for an SPI */
int irq_set_spi_type(unsigned int spi, unsigned int type);
-
+int irq_set_desc_data(unsigned int irq, void *d);
+void *irq_get_desc_data(struct irq_desc *d);
int platform_get_irq(const struct dt_device_node *device, int index);
void irq_set_affinity(struct irq_desc *desc, const cpumask_t *cpu_mask);
diff --git a/xen/include/xen/irq.h b/xen/include/xen/irq.h
index 9e0155c..f12afac 100644
--- a/xen/include/xen/irq.h
+++ b/xen/include/xen/irq.h
@@ -91,6 +91,8 @@ typedef struct irq_desc {
spinlock_t lock;
struct arch_irq_desc arch;
cpumask_var_t affinity;
+void *data; /* IRQ specific data */
+int virq; /* Used to store vlpi */
I guess we didn't need to find the virq corresponding to a given
physical irq before, because we assumed 1:1.
Given that this struct is common with x86, I think it is best to add the
two new fields to struct arch_irq_desc.
virq should be unsigned int. Instead of another void* data, please add
struct vits_device *dev.
/* irq ratelimit */
s_time_t rl_quantum_start;
--
1.7.9.5
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] ./configure: line 7058: python-config: command not found after commit 0013245
On Tue, Mar 03, 2015 at 05:46:08PM +, Julien Grall wrote: On 03/03/15 17:36, Wei Liu wrote: On Tue, Mar 03, 2015 at 05:22:39PM +, Julien Grall wrote: Hi, I've tried to use ./configure on the latest master and got the below error: checking for python-config... no checking Python.h usability... yes checking Python.h presence... yes checking for Python.h... yes checking for PyArg_ParseTuple in -lpython2.7... yes checking whether Python setup.py brokenly enables -D_FORTIFY_SOURCE... ./configure: line 7058: python-config: command not found no checking for xgettext... /usr/bin/xgettext Shall we require python-config installed on the build-platform? Isn't it part of the python-dev package? I'm using Debian, but I would expect it should come with whatever python development package you distro has? My point wasn't about the missing package but the odd error of the configure when python-config doesn't exist. My point being that you've clearly installed python development package (and we check that in configure) but you don't have python-config. It looks a bit weird. But if this is how some distro packages python then we should deal with this. Wei. Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] ./configure: line 7058: python-config: command not found after commit 0013245
On 03/03/2015 18:48, Wei Liu wrote: On Tue, Mar 03, 2015 at 05:46:08PM +, Julien Grall wrote: On 03/03/15 17:36, Wei Liu wrote: On Tue, Mar 03, 2015 at 05:22:39PM +, Julien Grall wrote: Hi, I've tried to use ./configure on the latest master and got the below error: checking for python-config... no checking Python.h usability... yes checking Python.h presence... yes checking for Python.h... yes checking for PyArg_ParseTuple in -lpython2.7... yes checking whether Python setup.py brokenly enables -D_FORTIFY_SOURCE... ./configure: line 7058: python-config: command not found no checking for xgettext... /usr/bin/xgettext Shall we require python-config installed on the build-platform? Isn't it part of the python-dev package? I'm using Debian, but I would expect it should come with whatever python development package you distro has? My point wasn't about the missing package but the odd error of the configure when python-config doesn't exist. My point being that you've clearly installed python development package (and we check that in configure) but you don't have python-config. It looks a bit weird. But if this is how some distro packages python then we should deal with this. Oh sorry I didn't understand your point like that. I'm using Debian Jessie. python-dev is not installed. Although I have libpython-dev installed. Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] 4.4.2-rc2 and 4.3.4-rc2 have been tagged
On 03/03/15 17:18, Jan Beulich wrote: All, aiming at releases with, as before, presumably no further RC on both of the branches (even more so with the long delay already incurred), please test! (The plan however is to incorporate the fixes for the XSAs that are going to go public during the next several days; unless something extremely important shows up, the expectation is for no other changes to go in before the release.) To remind you, 4.3.4 is expected to be the last xen.org coordinated release on the 4.3 series. Thanks, Jan My NMI shootdown fixes still suffer from the TLB shootdown issue which you identified. I notice your patch is still not even in staging (lacking acks?) but it has been thoroughly tested by XenServer. If that patch can't be fasttracked through, it might be worth introducing an extra fixmap entry in older trees to avoid introducing a regression into the crash path for systems using tboot. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 6/6] tools/libxl: Fix datacopier POLLHUP handling to not always be fatal
On 03/03/15 18:10, Ian Jackson wrote: Ian Campbell writes (Re: [PATCH 6/6] tools/libxl: Fix datacopier POLLHUP handling to not always be fatal): On Fri, 2015-02-20 at 13:55 +, Andrew Cooper wrote: A different and far less invasive approach might be to have a per-fd revent ignore mask. This would at least allow the callbacks to be made when the datacopier is in a consistent state. Ian, any thoughts on this? I think there is a real bug but the patch is misconceived :-/. Andrew says on IRC: 18:02 andyhhp Diziet: POLLHUP|POLLIN is a valid revent to recieve 18:03 andyhhp which happens when the writer has written into the pipe and closed the fd This is true [1] and will indeed cause the datacopier to quit before it has finished copying all the data, which I think is indeed a bug. On the other hand, some fd objects can return POLLHUP without other indications. In those cases we should fail. I think the right answer is for the dc to ignore POLLHUP iff there are other bits set which are going to be handled. Care needs to be taken about how this interacts with 7253e0fd1aeb3ae7d4714bcc1d86b846b3331995 libxl: react correctly to bootloader pty master POLLHUP Ian. [1] http://pubs.opengroup.org/onlinepubs/9699919799/functions/poll.html I don't think anything good can come from ignoring a POLLHUP on write_fd, as a subsequent call to write() is either going to hit a hard error, or block. (Indeed, [1] indicates that POLLHUP and POLLOUT are mutually exclusive.) On the read side, transforming POLLHUP|POLLIN to POLLIN should be safe, as read() will continue to work until EOF. Given [1], this should be safe even interacting with 7253e0fd1 as POLLHUP should be set for every subsequent poll(), even once EOF has been reached. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH tip/core/rcu 02/20] x86: Use common outgoing-CPU-notification code
On Tue, Mar 03, 2015 at 02:17:24PM -0500, Boris Ostrovsky wrote:
On 03/03/2015 12:42 PM, Paul E. McKenney wrote:
}
@@ -511,7 +508,8 @@ static void xen_cpu_die(unsigned int cpu)
schedule_timeout(HZ/10);
}
-cpu_die_common(cpu);
+(void)cpu_wait_death(cpu, 5);
+/* FIXME: Are the below calls really safe in case of timeout? */
Not for HVM guests (PV guests will only reach this point after
target cpu has been marked as down by the hypervisor).
We need at least to have a message similar to what native_cpu_die()
prints on cpu_wait_death() failure. And I think we should not call
the two routines below (three, actually --- there is also
xen_teardown_timer() below, which is not part of the diff).
-boris
xen_smp_intr_free(cpu);
xen_uninit_lock_cpu(cpu);
So something like this, then?
if (cpu_wait_death(cpu, 5)) {
xen_smp_intr_free(cpu);
xen_uninit_lock_cpu(cpu);
xen_teardown_timer(cpu);
}
Easy change for me to make if so!
Or do I need some other check for HVM-vs.-PV guests, and, if so, what
would that check be? And also if so, is it OK to online a PV guest's
CPU that timed out during its previous offline?
Thanx, Paul
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 6/6] tools/libxl: Fix datacopier POLLHUP handling to not always be fatal
Ian Campbell writes (Re: [PATCH 6/6] tools/libxl: Fix datacopier POLLHUP handling to not always be fatal): On Fri, 2015-02-20 at 13:55 +, Andrew Cooper wrote: A different and far less invasive approach might be to have a per-fd revent ignore mask. This would at least allow the callbacks to be made when the datacopier is in a consistent state. Ian, any thoughts on this? I think there is a real bug but the patch is misconceived :-/. Andrew says on IRC: 18:02 andyhhp Diziet: POLLHUP|POLLIN is a valid revent to recieve 18:03 andyhhp which happens when the writer has written into the pipe and closed the fd This is true [1] and will indeed cause the datacopier to quit before it has finished copying all the data, which I think is indeed a bug. On the other hand, some fd objects can return POLLHUP without other indications. In those cases we should fail. I think the right answer is for the dc to ignore POLLHUP iff there are other bits set which are going to be handled. Care needs to be taken about how this interacts with 7253e0fd1aeb3ae7d4714bcc1d86b846b3331995 libxl: react correctly to bootloader pty master POLLHUP Ian. [1] http://pubs.opengroup.org/onlinepubs/9699919799/functions/poll.html ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] x86/xen: Initialize cr4 shadow for 64-bit PV(H) guests
On Tue, Mar 03, 2015 at 09:27:34AM -0500, Boris Ostrovsky wrote: On 03/03/2015 12:35 AM, Luis R. Rodriguez wrote: On Mon, Feb 23, 2015 at 9:09 AM, David Vrabel david.vra...@citrix.com wrote: On 23/02/15 16:01, Boris Ostrovsky wrote: Commit 1e02ce4cccdc (x86: Store a per-cpu shadow copy of CR4) introduced CR4 shadows. These shadows are initialized in early boot code. The commit missed initialization for 64-bit PV(H) guests that this patch adds. Applied to stable/for-linus-4.0, thanks. Boris, can you kick of a set of tests on this branch, please? Do we know worst case what should blow up without this commit ? PVH guest will crash. Oh wow that is serious. And this is a reactive measure to a change upstream, it might be hard but it'd be nice if we can have a proactive architecture to address this. Don't mind me though, I realize this seems hard, just thinking out loud right now. Did you find it through code inspection or a test? Luis ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] kasan_map_early_shadow() on Xen
On Tue, Mar 3, 2015 at 2:06 AM, David Vrabel david.vra...@citrix.com wrote:
On 03/03/15 09:40, Luis R. Rodriguez wrote:
Andrey,
I believe that on Xen we should disable kasan, would like confirmation
Why? This is the first of heard of this.
Andrey chimed in here confirming this.
from someone on xen-devel though. Here's the thing though -- if true
-- I'd like to do it *properly*, where *properly* means addressing a
bit of architecture. A simple Kconfig slap seems rather reactive. I'd
like to address a way to properly ensure we don't run into this and
other similar issues in the future. The CR4 shadow issue was another
recent example issue, also introduced via v4.0 [0]. We can't keep
doing this reactively.
Let's go down the rabbit hole for a bit. HAVE_ARCH_KASAN will be
selected on x86 when:
if X86_64 SPARSEMEM_VMEMMAP
Now Xen should not have SPARSEMEM_VMEMMAP but PVOPs' goal is to enable
Why? Again, this is the first I've heard of this as well. FWIW, all
the Xen configs we use have SPARSEMEM_VMEMMAP enabled.
Interesting... we have config ARCH_SPARSEMEM_ENABLE depend on !XEN at
SUSE. Figured this was a generic issue. The SUSE kernels are based on
3.12 though, but anyway with it enabled I do get compile failures
because of redefinition of MAX_PHYSMEM_BITS which we provide on Xen
set to 43 for some reason (can't find that justification), so it
doesn't use the default 46 that would be used otherwise. But another
reason seems to be the lack of forward porting yet PAT support for PV
domains -- commit 47591df50 upstream which requires us to still have
the union on the pte_t, and I suppose we need ca15f20f as well...
If there is nothing else I suppose this just requires fixing up at
SUSE's end for SPARSEMEM_VMEMMAP...
--- ./arch/x86/include/asm/pgtable_64_types.h 2015-03-02
13:35:49.885257763 -0800
+++ ./arch/x86/include/mach-xen/asm/pgtable_64_types.h 2015-03-02
13:36:25.554259348 -0800
@@ -15,7 +15,7 @@
typedef unsigned long pgdval_t;
typedef unsigned long pgprotval_t;
-typedef struct { pteval_t pte; } pte_t;
+typedef union { pteval_t pte; unsigned int pte_low; } pte_t;
#endif /* !__ASSEMBLY__ */
@@ -54,6 +54,7 @@
#define PGDIR_MASK (~(PGDIR_SIZE - 1))
/* See Documentation/x86/x86_64/mm.txt for a description of the memory map. */
+#define MAX_PHYSMEM_BITS 43
#define MAXMEM _AC(__AC(1, UL) MAX_PHYSMEM_BITS, UL)
#define VMALLOC_START_AC(0xc900, UL)
#define VMALLOC_END _AC(0xe8ff, UL)
Luis
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH tip/core/rcu 02/20] x86: Use common outgoing-CPU-notification code
On 03/03/2015 12:42 PM, Paul E. McKenney wrote: } @@ -511,7 +508,8 @@ static void xen_cpu_die(unsigned int cpu) schedule_timeout(HZ/10); } - cpu_die_common(cpu); + (void)cpu_wait_death(cpu, 5); + /* FIXME: Are the below calls really safe in case of timeout? */ Not for HVM guests (PV guests will only reach this point after target cpu has been marked as down by the hypervisor). We need at least to have a message similar to what native_cpu_die() prints on cpu_wait_death() failure. And I think we should not call the two routines below (three, actually --- there is also xen_teardown_timer() below, which is not part of the diff). -boris xen_smp_intr_free(cpu); xen_uninit_lock_cpu(cpu); ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC PATCH 17/19] xen/arm: its: Support ITS interrupt handling
On Mon, 2 Mar 2015, vijay.kil...@gmail.com wrote:
From: Vijaya Kumar K vijaya.ku...@caviumnetworks.com
Add support for handling ITS(LPI) interrupts.
The LPI interrupts are handled by physical ITS
driver.
nested LPI interrupt handling is not tested and
enabled.
Signed-off-by: Vijaya Kumar K vijaya.ku...@caviumnetworks.com
---
xen/arch/arm/gic-v3-its.c | 31 +++
xen/arch/arm/gic-v3.c |8 ++--
xen/arch/arm/gic.c | 38 --
xen/arch/arm/irq.c | 10 +++---
xen/arch/arm/vgic-v3-its.c | 10 ++
xen/arch/arm/vgic.c| 14 ++
xen/include/asm-arm/gic.h |3 +++
xen/include/asm-arm/irq.h |1 +
8 files changed, 104 insertions(+), 11 deletions(-)
diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
index b2c3320..7adbee4 100644
--- a/xen/arch/arm/gic-v3-its.c
+++ b/xen/arch/arm/gic-v3-its.c
@@ -344,6 +344,37 @@ static const struct gic_its_hw_operations gic_its_ops = {
.gic_guest_lpi_type = gic_guest_its_type,
};
+void its_handle_lpi(uint32_t irqnr, struct cpu_user_regs *regs)
+{
+struct domain *d;
+struct irq_desc *desc = irq_to_desc(irqnr);
+
+irq_enter();
+spin_lock(desc-lock);
+
+if ( !desc-action )
+{
+printk(UNKNOWN LPI without handler\n);
+goto err;
+}
+
+if ( desc-status IRQ_GUEST )
+{
+d = irq_get_domain(desc);
+
+desc-handler-end(desc);
+
+desc-status |= IRQ_INPROGRESS;
+desc-arch.eoi_cpu = smp_processor_id();
+
+/* XXX: inject irq into all guest vcpus */
+vgic_vcpu_inject_irq(d-vcpu[0], irqnr);
+}
Does it really need a separate handler? It seems to me that LPIs could
just be handled from do_IRQ like the rest.
Also the comment is wrong in this case.
+err:
+spin_unlock(desc-lock);
+irq_exit();
+}
+
static u64 its_cmd_ptr_to_offset(struct its_node *its,
struct its_cmd_block *ptr)
{
diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index 02e71dd..b654535 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -848,9 +848,13 @@ static void gicv3_update_lr(int lr, const struct
pending_irq *p,
val = (((uint64_t)state 0x3) GICH_LR_STATE_SHIFT) | grp;
val |= ((uint64_t)p-priority 0xff) GICH_LR_PRIORITY_SHIFT;
-val |= ((uint64_t)p-irq GICH_LR_VIRTUAL_MASK)
GICH_LR_VIRTUAL_SHIFT;
- if ( p-desc != NULL )
+if ( is_lpi(p-irq) )
+val |= ((uint64_t)p-desc-virq GICH_LR_VIRTUAL_MASK)
GICH_LR_VIRTUAL_SHIFT;
+else
+val |= ((uint64_t)p-irq GICH_LR_VIRTUAL_MASK)
GICH_LR_VIRTUAL_SHIFT;
desc-virq should contain the right value for all interrupts, not just
lpis, so you should be able to do:
val |= ((uint64_t)p-desc-virq GICH_LR_VIRTUAL_MASK)
GICH_LR_VIRTUAL_SHIFT;
in all cases.
+ if ( p-desc != NULL !(is_lpi(p-irq)) )
val |= GICH_LR_HW | (((uint64_t)p-desc-irq GICH_LR_PHYSICAL_MASK)
GICH_LR_PHYSICAL_SHIFT);
diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index fb77387..c4d352a 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -34,6 +34,7 @@
#include asm/io.h
#include asm/gic.h
#include asm/vgic.h
+#include asm/gic-its.h
static void gic_restore_pending_irqs(struct vcpu *v);
@@ -134,6 +135,21 @@ void gic_route_irq_to_xen(struct irq_desc *desc, const
cpumask_t *cpu_mask,
gic_set_irq_properties(desc, cpu_mask, priority);
}
+void gic_route_lpi_to_guest(struct domain *d, struct irq_desc *desc,
+const cpumask_t *cpu_mask, unsigned int priority)
+{
+struct pending_irq *p;
+ASSERT(spin_is_locked(desc-lock));
+
+desc-handler = gic_its_hw_ops-gic_guest_lpi_type;
+set_bit(_IRQ_GUEST, desc-status);
+
+
+/* TODO: do not assume delivery to vcpu0 */
+p = irq_to_pending(d-vcpu[0], desc-irq);
+p-desc = desc;
+}
+
/* Program the GIC to route an interrupt to a guest
* - desc.lock must be held
*/
@@ -341,20 +357,33 @@ static void gic_update_one_lr(struct vcpu *v, int i)
struct pending_irq *p;
int irq;
struct gic_lr lr_val;
+uint32_t pirq;
ASSERT(spin_is_locked(v-arch.vgic.lock));
ASSERT(!local_irq_is_enabled());
gic_hw_ops-read_lr(i, lr_val);
irq = lr_val.virq;
-p = irq_to_pending(v, irq);
+
+if ( is_lpi(irq) )
+{
+// Fetch corresponding plpi for vlpi
+if ( vgic_its_get_pid(v, irq, pirq) )
+BUG();
+p = irq_to_pending(v, pirq);
+irq = pirq;
+}
+else
+{
+p = irq_to_pending(v, irq);
Shouldn't p-desc-irq return the pirq for LPIs too? If it doesn't, it
should :-)
I would like to see a more generic handling of virq != physical irq.
This is not specific to
Re: [Xen-devel] [RFC PATCH 17/19] xen/arm: its: Support ITS interrupt handling
Hi Stefano, On 03/03/2015 18:07, Stefano Stabellini wrote: I would like to see a more generic handling of virq != physical irq. This is not specific to LPIs but to any scenario where the physical irq differs from the virtual irq. I though we talked about it during the meeting at Connect... I've already got a patch for making virq != pirq : https://patches.linaro.org/43012/ That would drop the static 8K added because of the changes in irq_desc. Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] vNUMA: validate XEN_DOMCTL_setvnumainfo input
On 03/03/15 14:38, Jan Beulich wrote:
As we get ready to use the information set for a domain here we should
make sure it is actually valid: Both vNode and pNode numbers should be
in range. Do a little bit of other cleanup so the code ends up looking
reasonably consistent in style.
Along with this goes that we don't need an array of unsigned int to
store the pNode number - a nodeid_t one (a quarter the size) suffices.
Signed-off-by: Jan Beulich jbeul...@suse.com
Reviewed-by: Andrew Cooper andrew.coop...@citrix.com
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -344,7 +344,7 @@ static struct vnuma_info *vnuma_alloc(un
vnuma-vdistance = xmalloc_array(unsigned int, nr_vnodes * nr_vnodes);
vnuma-vcpu_to_vnode = xmalloc_array(unsigned int, nr_vcpus);
-vnuma-vnode_to_pnode = xmalloc_array(unsigned int, nr_vnodes);
+vnuma-vnode_to_pnode = xmalloc_array(nodeid_t, nr_vnodes);
vnuma-vmemrange = xmalloc_array(xen_vmemrange_t, nr_ranges);
if ( vnuma-vdistance == NULL || vnuma-vmemrange == NULL ||
@@ -382,30 +382,40 @@ static struct vnuma_info *vnuma_init(con
nr_vnodes * nr_vnodes) )
goto vnuma_fail;
+if ( copy_from_guest(info-vmemrange, uinfo-vmemrange,
+ uinfo-nr_vmemranges) )
+goto vnuma_fail;
+
if ( copy_from_guest(info-vcpu_to_vnode, uinfo-vcpu_to_vnode,
d-max_vcpus) )
goto vnuma_fail;
-if ( copy_from_guest(info-vnode_to_pnode, uinfo-vnode_to_pnode,
- nr_vnodes) )
-goto vnuma_fail;
+ret = -E2BIG;
+for ( i = 0; i d-max_vcpus; ++i )
+if ( info-vcpu_to_vnode[i] = nr_vnodes )
+goto vnuma_fail;
-if (copy_from_guest(info-vmemrange, uinfo-vmemrange,
-uinfo-nr_vmemranges))
-goto vnuma_fail;
+for ( i = 0; i nr_vnodes; ++i )
+{
+unsigned int pnode;
+
+ret = -EFAULT;
+if ( copy_from_guest_offset(pnode, uinfo-vnode_to_pnode, i, 1) )
+goto vnuma_fail;
+ret = -E2BIG;
+if ( pnode = MAX_NUMNODES )
+goto vnuma_fail;
+info-vnode_to_pnode[i] = pnode;
+}
info-nr_vnodes = nr_vnodes;
info-nr_vmemranges = uinfo-nr_vmemranges;
/* Check that vmemranges flags are zero. */
+ret = -EINVAL;
for ( i = 0; i info-nr_vmemranges; i++ )
-{
if ( info-vmemrange[i].flags != 0 )
-{
-ret = -EINVAL;
goto vnuma_fail;
-}
-}
return info;
--- a/xen/include/xen/domain.h
+++ b/xen/include/xen/domain.h
@@ -4,6 +4,7 @@
#include public/xen.h
#include asm/domain.h
+#include asm/numa.h
typedef union {
struct vcpu_guest_context *nat;
@@ -99,7 +100,7 @@ struct vnuma_info {
unsigned int nr_vmemranges;
unsigned int *vdistance;
unsigned int *vcpu_to_vnode;
-unsigned int *vnode_to_pnode;
+nodeid_t *vnode_to_pnode;
struct xen_vmemrange *vmemrange;
};
___
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 0/4] fix freemem loop
On Tuesday, March 03, 2015 11:08:38 AM Stefano Stabellini wrote: Hi all, this patch series fixes the freemem loop on machines with very large amount of memory, where the current wait time is not enough. In order to be able to handle arbitrarly large amount of ram, we implement in libxl_wait_for_memory_target a policy of waiting until dom0 is making progress. The patch series also reverts libxl: Wait for ballooning if free memory is increasing, that is not actually implemented correctly. Stefano Stabellini (4): Revert libxl: Wait for ballooning if free memory is increasing libxl_wait_for_memory_target: wait as long as dom0 is making progress freemem: remove call to libxl_wait_for_free_memory libxl_wait_for_memory_target: wait for 2 sec at a time tools/libxl/libxl.c | 31 +++ tools/libxl/xl_cmdimpl.c | 29 ++--- 2 files changed, 29 insertions(+), 31 deletions(-) I just tested this whole series and it works well in my environment (64G - 512G guests). dom0 now balloons down just the required amount. Also, domU startup works the first time, as it correctly waits until memory is freed. (Using dom0_mem is still a preferred option, as the ballooning delay can be significant.) Thanks for all the help and patience as we've worked through this. Ack to the whole series: Acked-by: Mike Latimer mlati...@suse.com -Mike ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH tip/core/rcu 02/20] x86: Use common outgoing-CPU-notification code
On 03/03/2015 04:26 PM, Paul E. McKenney wrote:
On Tue, Mar 03, 2015 at 03:13:07PM -0500, Boris Ostrovsky wrote:
On 03/03/2015 02:42 PM, Paul E. McKenney wrote:
On Tue, Mar 03, 2015 at 02:17:24PM -0500, Boris Ostrovsky wrote:
On 03/03/2015 12:42 PM, Paul E. McKenney wrote:
}
@@ -511,7 +508,8 @@ static void xen_cpu_die(unsigned int cpu)
schedule_timeout(HZ/10);
}
- cpu_die_common(cpu);
+ (void)cpu_wait_death(cpu, 5);
+ /* FIXME: Are the below calls really safe in case of timeout? */
Not for HVM guests (PV guests will only reach this point after
target cpu has been marked as down by the hypervisor).
We need at least to have a message similar to what native_cpu_die()
prints on cpu_wait_death() failure. And I think we should not call
the two routines below (three, actually --- there is also
xen_teardown_timer() below, which is not part of the diff).
-boris
xen_smp_intr_free(cpu);
xen_uninit_lock_cpu(cpu);
So something like this, then?
if (cpu_wait_death(cpu, 5)) {
xen_smp_intr_free(cpu);
xen_uninit_lock_cpu(cpu);
xen_teardown_timer(cpu);
}
else
pr_err(CPU %u didn't die...\n, cpu);
Easy change for me to make if so!
Or do I need some other check for HVM-vs.-PV guests, and, if so, what
would that check be? And also if so, is it OK to online a PV guest's
CPU that timed out during its previous offline?
I believe PV VCPUs will always be CPU_DEAD by the time we get here
since we are (indirectly) waiting for this in the loop at the
beginning of xen_cpu_die():
'while (xen_pv_domain() HYPERVISOR_vcpu_op(VCPUOP_is_up, cpu,
NULL))' will exit only after 'HYPERVISOR_vcpu_op(VCPUOP_down,
smp_processor_id()' in xen_play_dead(). Which happens after
play_dead_common() has marked the cpu as CPU_DEAD.
So no test is needed.
OK, so I have the following patch on top of my previous patch, which
I will merge if testing goes well. So if a CPU times out going offline,
the above three functions will not be called, the didn't die message
will be printed, and any future attempt to online that CPU will fail.
Is that the correct semantics?
Yes.
I am not sure whether not ever onlining the CPU is the best outcome but
then I don't think trying to online it again with all interrupts and
such still set up will work well. And it's an improvement over what we
have now anyway (with current code we may clean up things for a non-dead
cpu).
Thanks.
-boris
Thanx, Paul
diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
index e2c7389c58c5..f2a06ff0614d 100644
--- a/arch/x86/xen/smp.c
+++ b/arch/x86/xen/smp.c
@@ -508,12 +508,13 @@ static void xen_cpu_die(unsigned int cpu)
schedule_timeout(HZ/10);
}
- (void)cpu_wait_death(cpu, 5);
- /* FIXME: Are the below calls really safe in case of timeout? */
-
- xen_smp_intr_free(cpu);
- xen_uninit_lock_cpu(cpu);
- xen_teardown_timer(cpu);
+ if (cpu_wait_death(cpu, 5)) {
+ xen_smp_intr_free(cpu);
+ xen_uninit_lock_cpu(cpu);
+ xen_teardown_timer(cpu);
+ } else {
+ pr_err(CPU %u didn't die...\n, cpu);
+ }
}
static void xen_play_dead(void) /* used only with HOTPLUG_CPU */
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/2] x86/xen/apic: Work with UP, non-SMP 32-bit kernels.
On Tue, Mar 03, 2015 at 03:20:41PM -0500, Konrad Rzeszutek Wilk wrote:
Most of the APIC code that use APIC_LDR is not used on
64-bit. On 32-bit it is bit of an hack - and the mechanism
it is uses is to setup the APIC_LDR via apci-init_apic_ldr
(which we set to NULL) and then use apic-x86_32_early_logical_apicid
to get an CPU to APIC ID mapping and also apic-read to match
the APIC_LDR.
The 'x86_32_early_logical_apicid' is called from 'setup_local_APIC'
which is called from the following functions:
- start_secondary -smp_callin - apic_ap_setup [not called on PV]
- native_smp_prepare_cpus - apci_bsp_setup [not called on PV]
- up_late_init - APIC_init_uniprocessor - apic_bsp_setup -setup_local_APIC
[called on PV with CONFIG_SMP not defined, CONFIG_X86_32 and UP kernel]
This patch fixes the build issue and also allows the bootup
to continue without warnings.
Reported-by: Boris Ostrovsky boris.ostrov...@oracle.com
Signed-off-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com
---
arch/x86/xen/apic.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/arch/x86/xen/apic.c b/arch/x86/xen/apic.c
index 86bea3e..de1c74d 100644
--- a/arch/x86/xen/apic.c
+++ b/arch/x86/xen/apic.c
@@ -56,7 +56,10 @@ static u32 xen_apic_read(u32 reg)
if (reg == APIC_LVR)
return 0x10;
-
+#ifdef CONFIG_X86_32
+ if (reg == APIC_LDR)
+ return SET_APIC_LOGICAL_ID(1UL smp_processor_id());
+#endif
if (reg != APIC_ID)
return 0;
@@ -117,6 +120,12 @@ static int xen_phys_pkg_id(int initial_apic_id, int
index_msb)
return initial_apic_id index_msb;
}
+static int xen_x86_32_early_logical_apicid(int cpu)
+{
+ /* Match with APIC_LDR read. Otherwise setup_local_APIC complains. */
+ return 1 cpu;
+}
+
Argh. That should have been wrapped with CONFIG_X86_32 otherwise it will
complain
on 64-bit (not used.. etc).
David, I can commit it in and fix it up.
static void xen_noop(void)
{
}
@@ -176,8 +185,8 @@ static struct apic xen_pv_apic = {
.safe_wait_icr_idle = xen_safe_apic_wait_icr_idle,
#ifdef CONFIG_X86_32
- /* generic_processor_info */
- .x86_32_early_logical_apicid= default_x86_32_early_logical_apicid,
+ /* generic_processor_info and setup_local_APIC. */
+ .x86_32_early_logical_apicid= xen_x86_32_early_logical_apicid,
#endif
};
--
1.8.4.2
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] domctl: cleanup
On 03/03/15 14:40, Jan Beulich wrote:
- drop redundant ret = 0 statements
- drop unnecessary braces
- eliminate a few single use local variables
- move break statements inside case-specific braced scopes
Signed-off-by: Jan Beulich jbeul...@suse.com
One bug (one ret = 0 was not redundant) and one suggestion for futher
cleanup.
Otherwise, Reviewed-by: Andrew Cooper andrew.coop...@citrix.com
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -831,15 +825,13 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xe
ret = cpumask_to_xenctl_bitmap(vcpuaff-cpumap_soft,
v-cpu_soft_affinity);
}
+break;
}
-break;
case XEN_DOMCTL_scheduler_op:
-{
ret = sched_adjust(d, op-u.scheduler_op);
copyback = 1;
-}
-break;
+break;
case XEN_DOMCTL_getdomaininfo:
{
For a cleanup patch, you might as well nuke the trailing whitespace,
which includes the a space after this brace
@@ -870,8 +859,8 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xe
getdomaininfo_out:
rcu_read_unlock(domlist_read_lock);
d = NULL;
+break;
}
-break;
case XEN_DOMCTL_getvcpucontext:
{
... and here ...
@@ -919,8 +908,8 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xe
getvcpucontext_out:
xfree(c.nat);
+break;
}
-break;
case XEN_DOMCTL_getvcpuinfo:
{
... and here.
@@ -961,21 +947,16 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xe
* the meantime, while tot max, all new allocations are disallowed.
*/
d-max_pages = new_max;
-ret = 0;
spin_unlock(d-page_alloc_lock);
+break;
}
-break;
case XEN_DOMCTL_setdomainhandle:
-{
memcpy(d-handle, op-u.setdomainhandle.handle,
sizeof(xen_domain_handle_t));
-ret = 0;
-}
-break;
+break;
case XEN_DOMCTL_setdebugging:
-{
ret = -EINVAL;
if ( d == current-domain ) /* no domain_pause() */
break;
@@ -983,9 +964,7 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xe
domain_pause(d);
d-debugger_attached = !!op-u.setdebugging.enable;
domain_unpause(d); /* causes guest to latch new status */
-ret = 0;
This ret is not redundant. (Observe the unconditional ret = -EINVAL in
the previous hunk).
XEN_DOMCTL_setdebugging can probably be rearranged to a single if()/else
in the same way as XEN_DOMCTL_set_access_required below to make it
slightly shorter.
~Andrew
@@ -1131,41 +1103,28 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xe
break;
case XEN_DOMCTL_disable_migrate:
-{
d-disable_migrate = op-u.disable_migrate.disable;
-}
-break;
+break;
#ifdef HAS_MEM_ACCESS
case XEN_DOMCTL_set_access_required:
-{
-struct p2m_domain* p2m;
-
-ret = -EPERM;
if ( current-domain == d )
-break;
-
-ret = 0;
-p2m = p2m_get_hostp2m(d);
-p2m-access_required = op-u.access_required.access_required;
-}
-break;
+ret = -EPERM;
+else
+p2m_get_hostp2m(d)-access_required =
+op-u.access_required.access_required;
+break;
#endif
case XEN_DOMCTL_set_virq_handler:
-{
-uint32_t virq = op-u.set_virq_handler.virq;
-ret = set_global_virq_handler(d, virq);
-}
-break;
+ret = set_global_virq_handler(d, op-u.set_virq_handler.virq);
+break;
case XEN_DOMCTL_set_max_evtchn:
-{
d-max_evtchn_port = min_t(unsigned int,
op-u.set_max_evtchn.max_port,
INT_MAX);
-}
-break;
+break;
case XEN_DOMCTL_setvnumainfo:
{
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
