Re: [Xen-devel] [PATCH v2 2/5] vTPM: limit libxl__add_vtpms() function to para virtual machine
On Tue, Jan 06, 2015 at 02:17:36AM +, Xu, Quan wrote:
-Original Message-
From: Wei Liu [mailto:wei.l...@citrix.com]
Sent: Monday, January 05, 2015 8:53 PM
To: Xu, Quan
Cc: xen-devel@lists.xen.org; ian.jack...@eu.citrix.com;
stefano.stabell...@eu.citrix.com; ian.campb...@citrix.com;
wei.l...@citrix.com
Subject: Re: [PATCH v2 2/5] vTPM: limit libxl__add_vtpms() function to para
virtual machine
On Tue, Dec 30, 2014 at 11:45:02PM -0500, Quan Xu wrote:
Signed-off-by: Quan Xu quan...@intel.com
---
tools/libxl/libxl_create.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index b1ff5ae..0a09925 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -1358,8 +1358,9 @@ static void domcreate_attach_vtpms(libxl__egc
*egc,
goto error_out;
}
-/* Plug vtpm devices */
- if (d_config-num_vtpms 0) {
+ /* Plug vtpm devices for para virtual domain*/
+ if (d_config-num_vtpms 0
+ d_config-b_info.type == LIBXL_DOMAIN_TYPE_PV) {
It's unclear to me why you stub out HVM domain. You need to state your
reasoning in comment and commit log. :-/
In brief, it is different to plug vtpm device for HVM/PV domain. I will try
to describe more detailed in next v3. Thanks Wei.
I got that idea when I read your later patch. But stubbing out PV here
is wrong. Essentially this patch introduces a functional regression by
itself because now you can't add vtpms for PV. I doubt that you will
still need this patch in your next round. See my reply to patch 4/5.
Wei.
Thanks
Quan Xu
Wei.
/* Attach vtpms */
libxl__multidev_begin(ao, dcs-multidev);
dcs-multidev.callback = domcreate_attach_pci;
--
1.8.3.2
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 3/4] tools: libxl: code preparation for MBM
On Mon, Jan 05, 2015 at 12:25:05PM +, Wei Liu wrote:
On Tue, Dec 23, 2014 at 04:54:38PM +0800, Chao Peng wrote:
[...]
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 3737c7e..f4534ec 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -7845,12 +7845,13 @@ out:
}
#ifdef LIBXL_HAVE_PSR_CMT
-static void psr_cmt_print_domain_cache_occupancy(libxl_dominfo *dominfo,
+static void psr_cmt_print_domain_l3_info(libxl_dominfo *dominfo,
+libxl_psr_cmt_type
type,
uint32_t nr_sockets)
Indentation.
{
char *domain_name;
uint32_t socketid;
-uint32_t l3_cache_occupancy;
+uint32_t data;
if (!libxl_psr_cmt_domain_attached(ctx, dominfo-domid))
return;
@@ -7860,15 +7861,21 @@ static void
psr_cmt_print_domain_cache_occupancy(libxl_dominfo *dominfo,
free(domain_name);
for (socketid = 0; socketid nr_sockets; socketid++) {
-if ( !libxl_psr_cmt_get_cache_occupancy(ctx, dominfo-domid,
- socketid, l3_cache_occupancy) )
-printf(%13u KB, l3_cache_occupancy);
+switch (type) {
+case LIBXL_PSR_CMT_TYPE_CACHE_OCCUPANCY:
+if ( !libxl_psr_cmt_get_cache_occupancy(ctx, dominfo-domid,
+ socketid, data) )
+printf(%13u KB, data);
+break;
+default:
+return;
+}
}
printf(\n);
}
-static int psr_cmt_show_cache_occupancy(uint32_t domid)
+static int psr_cmt_show_l3_info(libxl_psr_cmt_type type, uint32_t domid)
{
uint32_t i, socketid, nr_sockets, total_rmid;
uint32_t l3_cache_size;
@@ -7904,18 +7911,22 @@ static int psr_cmt_show_cache_occupancy(uint32_t
domid)
printf(%14s %d, Socket, socketid);
printf(\n);
-/* Total L3 cache size */
-printf(%-46s, Total L3 Cache Size);
-for (socketid = 0; socketid nr_sockets; socketid++) {
-rc = libxl_psr_cmt_get_l3_cache_size(ctx, socketid,
l3_cache_size);
-if (rc 0) {
-fprintf(stderr, Failed to get system l3 cache size for
socket:%d\n,
-socketid);
-return -1;
-}
-printf(%13u KB, l3_cache_size);
+if ( type == LIBXL_PSR_CMT_TYPE_CACHE_OCCUPANCY ) {
Coding style, no space after ( and before ).
I missed this issue when I reviewed your previous patches. You can fix
this style problem here while you're at it.
Sure, I will fix them all.
Thanks.
Chao
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 3/4] tools: libxl: code preparation for MBM
On Tue, Jan 06, 2015 at 05:46:12PM +0800, Chao Peng wrote: [...] Coding style, no space after ( and before ). I missed this issue when I reviewed your previous patches. You can fix this style problem here while you're at it. Sure, I will fix them all. If you plan to fix them all and there are many instances, please use preparatory patch -- don't mix them with functional changes. Wei. Thanks. Chao ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Writable page tables questions
On Mon, 2015-01-05 at 17:28 +, Andrew Cooper wrote: On 04/01/2015 17:17, Junji Zhi wrote: Hi, I'm Junji, a newbie in Xen and hoping I can contribute to the community one day. I have a few questions regarding the writable page tables, while reading The Definitive Guide to the Xen Hypervisor by David Chisnall: 1. Writable page tables is one Xen memory assist technique, applied to paravirtualized guests ONLY. HVM does not apply. Correct? 2. According to the book, when a guest wants to modify its page table, it triggers a trap into the hypervisor and it does a few steps: (1) it invalidates a PTE that points to the page containing the page table. Is my understanding correct? Q: What does invalidate really mean here? Does it mean simply flipping a bit in the PTE of the page table, or removing the PTE completely? At least clearing the present bit, what happens to the other bits in the PTE is up to the implementation I think. Does it also need to invalidate the TLB entry? Yes, I think so, else the CPU might subsequently use a stale mapping. (2) then the control goes back to the guest and it can write/read the page table now. (3) The book's words pasted: When an address referenced by the newly invalidated page directory entry is referenced (read or write), a page fault occurs. Q: The description of step (3) is confusing. What does it mean by an address referenced by the newly invalidated page directory entry is referenced? Does it mean the case when the guest code is accessing an virtual address that needs to search the invalidated page table for translation? Yes, it means when something tries to access memory which would have been mapped by the PT page which was removed in (1). I do not have the Chisnall book to hand at the moment, so cannot comment as to the exact text in it. However, looking at the code as it exists today, XENFEAT_writable_page_tables (there is a typo in the ABI) is strictly only offered to HVM guests, and not to PV guests. XENFEAT_writable_page_tables is different from out of sync PT updates, which is what Junji (and the book) seems to be referring to. I don't know if modern Xen still does this for PV (I think it still does for shadow mode HVM under at least some circumstances) but at at one point in time (presumably when the book was written) it used to be that Xen would handle an emulated write to a r/o page table page by: * unhooking it from the higher level PTs which referenced it, flushing TLBs * map the PT page itself r/w (contrary to the usual invariant that it be mapped r/o, which is Xen's usual invariant) At which point any subsequent writes to the now out-of-sync PT page can just happen without trapping. This is safe because after the unhook the PT is not part of any cr3 and the invariant is not violated (the guest doesn't really know this is happening, for all it knows all writes are still being emulated). At some point something would try and access the memory which would be mapped by the out of sync PT page and Xen will, in the page fault handler: * make all the mappings r/o again (+ tlb flush) * validate all the entries in the page * rehook it into the higher level PTs which should reference it At which point the mappings are available again and Xen's invariants are preserved. The tlb flushes involved in the above are reasonably expensive, IIRC Xen flip flopped a bit (years ago now) on whether it is worthwhile doing this or not, which is why I'm not sure if it still does or not. This is all different from XENFEAT_writable_page_tables that you talk about which is where the guest is informed that it is not obliged to make the regular mappings r/o in the first place, i.e. to ignore Xen's invariant completely. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [Qemu-devel] bind interdomain ioctl error xen-kvm.c
Hi Stefano, Please find my answers inline. However Anthony (CC'ed) should have some patches for it. Anthony, can you please share any patch that can help me with this? Can you post the full output of the logs? I have attached the output of sudo xl -v create /etc/xen/qemu-pv.cfg as xl_create.txt. I have also enabled DEBUG_XEN_HVM in xen-hvm.c and pasted output of sudo ./x86_64-softmmu/qemu-system-x86_64 -machine q35,accel=xen -cpu qemu64 -xen-domid 13 below: xen: shared page at pfn feffd xen: buffered io page at pfn feffb bind interdomain ioctl error 22 xen hardware virtual machine initialisation failed What is the Xen version that you are running? I am using XEN 4.4.1 as this is the default on Ubuntu 14.04. I have attached the output of xl info command as xl_info.txt. Did you execute the xencommons init script at boot time? On Ubuntu I don't see /etc/init.d/xencommon but there is a /etc/init.d/xen script which starts xenstored and xenconsoled. I did confirm from ps aufx that both the daemons are running. I have attched log for ps aufx as ps_aufx_grep_xen.txt . On Mon, Jan 5, 2015 at 4:48 AM, Stefano Stabellini stefano.stabell...@eu.citrix.com wrote: On Tue, 30 Dec 2014, Rishi Ranjan wrote: I am trying to use Xen as accelerator for my Qemu machine. I have created a guest domain with following xl config: builder = hvm name = qemu-hvm memory = 512 vcpus = 1 vif = [''] vnc = 1 boot=c When I try to run with following parameters: -machine q35,accel=xen -cpu qemu64 -bios ./pc-bios/bios-256k.bin -xen-domid Domain id of guest You should know that q35 emulation is not fully working on Xen yet. However Anthony (CC'ed) should have some patches for it. That said, it does not look like this error has something to do with q35. I am getting follwing error from xen-hvm.c: bind interdomain ioctl error in xen_hvm_init while calling state-shared_vmport_page = xc_map_foreign_range(xen_xc, xen_domid, XC_PAGE_SIZE, PROT_READ|PROT_WRITE, ioreq_pfn); Can someone help me get this working? Can you post the full output of the logs? What is the Xen version that you are running? Did you execute the xencommons init script at boot time? host : rishi-700-327c release: 3.13.0-43-generic version: #72-Ubuntu SMP Mon Dec 8 19:35:06 UTC 2014 machine: x86_64 nr_cpus: 8 max_cpu_id : 7 nr_nodes : 1 cores_per_socket : 4 threads_per_core : 2 cpu_mhz: 3392 hw_caps: bfebfbff:2c100800::7f00:77fafbff::0021:2fbb virt_caps : hvm hvm_directio total_memory : 16289 free_memory: 128 sharing_freed_memory : 0 sharing_used_memory: 0 outstanding_claims : 0 free_cpus : 0 xen_major : 4 xen_minor : 4 xen_extra : .1 xen_version: 4.4.1 xen_caps : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64 xen_scheduler : credit xen_pagesize : 4096 platform_params: virt_start=0x8000 xen_changeset : xen_commandline: placeholder no-real-mode edd=off cc_compiler: gcc (Ubuntu 4.8.2-19ubuntu1) 4.8.2 cc_compile_by : stefan.bader cc_compile_domain : canonical.com cc_compile_date: Wed Nov 26 14:12:33 UTC 2014 xend_config_format : 4 root65 0.0 0.0 0 0 ?S09:33 0:00 \_ [xenwatch] root66 0.0 0.0 0 0 ?S09:33 0:00 \_ [xenbus] root72 0.0 0.0 0 0 ?S 09:33 0:00 \_ [xenbus_frontend] root 1112 0.0 0.0 10232 2408 ?Ss 09:33 0:00 dhclient -1 -v -pf /run/dhclient.xenbr0.pid -lf /var/lib/dhcp/dhclient.xenbr0.leases xenbr0 root 1524 0.0 0.0 10992 960 ?S09:33 0:00 /usr/lib/xen-4.4/bin/xenstored --pid-file=/var/run/xenstore.pid root 1530 0.0 0.0 82572 632 ?SLl 09:33 0:00 /usr/lib/xen-4.4/bin/xenconsoled --pid-file=/var/run/xenconsoled.pid rishi 4309 0.0 0.0 17444 932 pts/1S+ 10:44 0:00 | \_ grep --color=auto xen sudo xl -v create /etc/xen/qemu-pv.cfg Parsing config from /etc/xen/qemu-pv.cfg libxl: detail: libxl_dom.c:195:numa_place_domain: NUMA placement candidate with 1 nodes, 8 cpus and 4477 KB free selected xc: detail: elf_parse_binary: phdr: paddr=0x10 memsz=0xa7a84 xc: detail: elf_parse_binary: memory: 0x10 - 0x1a7a84 xc: detail: VIRTUAL MEMORY ARRANGEMENT: Loader:0010-001a7a84 Modules: - TOTAL: -ff80 ENTRY ADDRESS: 00100620 xc: detail: PHYSICAL MEMORY ALLOCATION: 4KB PAGES: 0x0200 2MB PAGES:
Re: [Xen-devel] [PATCH 4/4] tools: add total/local memory bandwith monitoring
On 06/01/15 10:09, Chao Peng wrote:
On Mon, Jan 05, 2015 at 12:39:42PM +, Wei Liu wrote:
On Tue, Dec 23, 2014 at 04:54:39PM +0800, Chao Peng wrote:
[...]
+static int libxl__psr_cmt_get_mem_bandwidth(libxl__gc *gc, uint32_t domid,
+xc_psr_cmt_type type, uint32_t socketid, uint32_t *bandwidth)
+{
+uint64_t sample1, sample2;
+uint32_t upscaling_factor;
+int rc;
+
+rc = libxl__psr_cmt_get_l3_monitoring_data(gc, domid,
+type, socketid, sample1);
+if (rc 0)
+return ERROR_FAIL;
+
+usleep(1);
+
+rc = libxl__psr_cmt_get_l3_monitoring_data(gc, domid,
+type, socketid, sample2);
+if (rc 0)
+ return ERROR_FAIL;
+
+if (sample2 sample1) {
+ LOGE(ERROR, event counter overflowed between two samplings);
+ return ERROR_FAIL;
+}
+
What's the likelihood of counter overflows? Can we handle this more
gracefully? Say, retry (with maximum retry cap) when counter overflows?
The likelihood is very small here. Hardware guarantees the counter will
not overflow in one second even under maximum platform bandwidth conditions.
And we only sleep 0.01 second here.
I'd like to adopt your suggestion to retry another time once that happens.
But only one retry and it should correct the overflow.
Thanks,
Chao
You have no possible way of guaranteeing that the actual elapsed time
between the two samples is less than 1 second. On a very heavily loaded
system, even regular task scheduling could cause an actual elapsed time
of more than one second in that snippet of code.
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [win-pv-devel] XenBus_AddWatch
-Original Message- From: win-pv-devel-boun...@lists.xenproject.org [mailto:win-pv-devel- boun...@lists.xenproject.org] On Behalf Of hanji unit Sent: 31 December 2014 15:15 To: win-pv-de...@lists.xenproject.org; xen-devel@lists.xen.org Subject: [win-pv-devel] XenBus_AddWatch Hello, I am calling XenBus_AddWatch API from a DomU guest in the win-pvdrivers xenpci driver, and noticed that I am not able to watch xenstore entries that are outside of the DomU's xenstore tree. For example, the following call in XenPci_EvtDeviceD0EntryPostInterruptsEnabled fails with response=EIO even if the xenstore permissions for Container and Container/DomU in xenstore are both b0: response = XenBus_AddWatch(xpdd, XN_BASE_GLOBAL, Container/DomU, MyCallback, xpdd); However, the following call works and it watches a xenstore entry relative to DomUs xenstore tree: response = XenBus_AddWatch(xpdd, XBT_NIL, DomU, MyCallback, xpdd); Writing to an entry outside the DomUs tree is allowed if permissions are b0: result = XnWriteString(xpdd, XN_BASE_GLOBAL, Container/DomU, buffer); It seems like DomUs should be allowed to watch xenstore entries outside their trees. Is this a bug or is it by design? Hi, The API you're referring to is part of James Harper's GPLPV drivers I believe, which I'm no expert on. I would imagine the API simply passes error codes back from xenstored though so you should probably check xenstored-access.log, although EIO does sound like an odd code to get back. Paul Thanks. ___ win-pv-devel mailing list win-pv-de...@lists.xenproject.org http://lists.xenproject.org/cgi-bin/mailman/listinfo/win-pv-devel ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Parallel make supported?
On Tue, Jan 06, 2015 at 12:08:33AM +, Peter Kay wrote: root[xen-4.5.0-rc4]# ls -l tools/xenstore/libxenstore* -rw-r--r-- 1 root root 98580 Dec 19 22:02 tools/xenstore/libxenstore.a -rwxr-xr-x 1 root root 82624 Dec 19 22:02 tools/xenstore/libxenstore.so.3.0.3 Please see output of make -d -C tools/xenstore init-xenstore-domain attached - it's quite long uncompressed The log file suggests compilation of init-xenstore-domain is successful. :-/ If you encounter that problem with parallel build you might want to invoke make with -j? Wei. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] One question about the hypercall to translate gfn to mfn.
On Tue, 2015-01-06 at 08:42 +, Tian, Kevin wrote: From: George Dunlap Sent: Monday, January 05, 2015 11:50 PM On Fri, Dec 12, 2014 at 6:29 AM, Tian, Kevin kevin.t...@intel.com wrote: We're not there in the current design, purely because XenGT has to be in dom0 (so it can trivially DoS Xen by rebooting the host). Can we really decouple dom0 from DoS Xen? I know there's on-going effort like PVH Dom0, however there are lots of trickiness in Dom0 which can put the platform into a bad state. One example is ACPI. All the platform details are encapsulated in AML language, and only dom0 knows how to handle ACPI events. Unless Xen has another parser to guard all possible resources which might be touched thru ACPI, a tampered dom0 has many way to break out. But that'd be very challenging and complex. If we can't containerize Dom0's behavior completely, I would think dom0 and Xen actually in the same trust zone, so putting XenGT in Dom0 shouldn't make things worse. The question here is, If a malicious guest can manage to break into XenGT, what can they do? If XenGT is running in dom0, then the answer is, At very least, they can DoS the host because dom0 is allowed to reboot; they can probably do lots of other nasty things as well. If XenGT is running in its own domain, and can only add IOMMU entries for MFNs belonging to XenGT-only VMs, then the answer is, They can access other XenGT-enabled VMs, but they cannot shut down the host or access non-XenGT VMs. Slides 8-11 of a presentation I gave (http://www.slideshare.net/xen_com_mgr/a-brief-tutorial-on-xens-advanced-s ecurity-features) can give you a graphical idea of what we're' talking about. I agree we need to make XenGT more isolated following on-going trend from previous discussion, but regarding to whether Dom0/Xen are in the same security domain, I don't see my statement is changed w/ above attempts which just try to move privileged Xen stuff away from dom0, but all existing Linux vulnerabilities allow a tampered Dom0 do many evil things with root permission or even tampered kernel to DoS Xen (e.g. w/ ACPI). PVH dom0 can help performance... but itself alone doesn't change the fact that Dom0/Xen are actually in the same security domain. :-) Which is a good reason why one would want to remove as much potentially vulnerable code from dom0 as possible, and then deny it the corresponding permissions via XSM too. I also find the argument dom0 can do some bad things so we should let it be able to do all bad things rather specious. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 0/2] VT-d: extend XSA-59 workaround
Dugger, Donald D donald.d.dug...@intel.com 01/05/15 5:28 PM Working to resolve this issue, I hope to have a definitive answer by the end of this week. I.e. too late for 4.5, unless it gets slipped further... Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC 2/2] x86, vdso, pvclock: Simplify and speed up the vdso pvclock reader
On 05/01/2015 20:17, Marcelo Tosatti wrote: But there is no guarantee that vCPU-N has updated its pvti when vCPU-M resumes guest instruction execution. You're right. So the cost this patch removes is mainly from __getcpu (==RDTSCP?) ? Perhaps you can use Gleb's idea to stick vcpu id into version field ? Or just replace __getcpu with rdtscp. Paolo ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] One question about the hypercall to translate gfn to mfn.
From: George Dunlap Sent: Monday, January 05, 2015 11:50 PM On Fri, Dec 12, 2014 at 6:29 AM, Tian, Kevin kevin.t...@intel.com wrote: We're not there in the current design, purely because XenGT has to be in dom0 (so it can trivially DoS Xen by rebooting the host). Can we really decouple dom0 from DoS Xen? I know there's on-going effort like PVH Dom0, however there are lots of trickiness in Dom0 which can put the platform into a bad state. One example is ACPI. All the platform details are encapsulated in AML language, and only dom0 knows how to handle ACPI events. Unless Xen has another parser to guard all possible resources which might be touched thru ACPI, a tampered dom0 has many way to break out. But that'd be very challenging and complex. If we can't containerize Dom0's behavior completely, I would think dom0 and Xen actually in the same trust zone, so putting XenGT in Dom0 shouldn't make things worse. The question here is, If a malicious guest can manage to break into XenGT, what can they do? If XenGT is running in dom0, then the answer is, At very least, they can DoS the host because dom0 is allowed to reboot; they can probably do lots of other nasty things as well. If XenGT is running in its own domain, and can only add IOMMU entries for MFNs belonging to XenGT-only VMs, then the answer is, They can access other XenGT-enabled VMs, but they cannot shut down the host or access non-XenGT VMs. Slides 8-11 of a presentation I gave (http://www.slideshare.net/xen_com_mgr/a-brief-tutorial-on-xens-advanced-s ecurity-features) can give you a graphical idea of what we're' talking about. I agree we need to make XenGT more isolated following on-going trend from previous discussion, but regarding to whether Dom0/Xen are in the same security domain, I don't see my statement is changed w/ above attempts which just try to move privileged Xen stuff away from dom0, but all existing Linux vulnerabilities allow a tampered Dom0 do many evil things with root permission or even tampered kernel to DoS Xen (e.g. w/ ACPI). PVH dom0 can help performance... but itself alone doesn't change the fact that Dom0/Xen are actually in the same security domain. :-) Thanks Kevin ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] xen/x86: properly retrieve NMI reason
David Vrabel david.vra...@citrix.com 01/05/15 11:35 AM On 19/12/14 16:16, Jan Beulich wrote: Using the native code here can't work properly, as the hypervisor would normally have cleared the two reason bits by the time Dom0 gets to see the NMI (if passed to it at all). There's a shared info field for this, and there's an existing hook to use - just fit the two together. Note that the hook can (and should) be used irrespective of whether being in Dom0, as accessing port 0x61 in a DomU would be even worse, while the shared info field would just hold zero all the time. Signed-off-by: Jan Beulich jbeul...@suse.com This doesn't build. In file included from /local/davidvr/work/k.org/tip/arch/x86/xen/enlighten.c:43:0: /local/davidvr/work/k.org/tip/include/xen/interface/nmi.h:44:1: warning: data definition has no type or storage class [enabled by default] /local/davidvr/work/k.org/tip/include/xen/interface/nmi.h:44:1: error: type defaults to ‘int’ in declaration of ‘DEFINE_XEN_GUEST_HANDLE’ [-Werror=implicit-int] cc1: some warnings being treated as errors Hmm, I can see why this happens (Linux renaming the macro from what the canonical headers use), but I'll have to check why my build test didn't catch this... Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] One question about the hypercall to translate gfn to mfn.
From: Tim Deegan [mailto:t...@xen.org] Sent: Thursday, December 18, 2014 11:47 PM Hi, At 07:24 + on 12 Dec (1418365491), Tian, Kevin wrote: I'm afraid not. There's nothing worrying per se in a backend knowing the MFNs of the pages -- the worry is that the backend can pass the MFNs to hardware. If the check happens only at lookup time, then XenGT can (either through a bug or a security breach) just pass _any_ MFN to the GPU for DMA. But even without considering the security aspects, this model has bugs that may be impossible for XenGT itself to even detect. E.g.: 1. Guest asks its virtual GPU to DMA to a frame of memory; 2. XenGT looks up the GFN-MFN mapping; 3. Guest balloons out the page; 4. Xen allocates the page to a different guest; 5. XenGT passes the MFN to the GPU, which DMAs to it. Whereas if stage 2 is a _mapping_ operation, Xen can refcount the underlying memory and make sure it doesn't get reallocated until XenGT is finished with it. yes, I see your point. Now we can't support ballooning in VM given above reason, and refcnt is required to close that gap. but just to confirm one point. from my understanding whether it's a mapping operation doesn't really matter. We can invent an interface to get p2m mapping and then increase refcnt. the key is refcnt here. when XenGT constructs a shadow GPU page table, it creates a reference to guest memory page so the refcnt must be increased. :-) True. :) But Xen does need to remember all the refcounts that were created (so it can tidy up if the domain crashes). If Xen is already doing that it might as well do it in the IOMMU tables since that solves other problems. would a refcnt in p2m layer enough so we don't need separate refcnt in both EPT and IOMMU page table? [First some hopefully-helpful diagrams to explain my thinking. I'll borrow 'BFN' from Malcolm's discussion of IOMMUs to describe the addresses that devices issue their DMAs in: what's 'BFN' short for? Bus Frame Number? Yes, I think so. If we replace that lookup with a _map_ hypercall, either with Xen choosing the BFN (as happens in the PV grant map operation) or with the guest choosing an unused address (as happens in the HVM/PVH grant map operation), then: - the only extra code in XenGT itself is that you need to unmap when you change the GTT; - Xen can track and control exactly which MFNs XenGT/the GPU can access; - running XenGT in a driver domain or PVH dom0 ought to work; and - we fix the race condition I described above. ok, I see your point here. It does sound like a better design to meet Xen hypervisor's security requirement and can also work with PVH Dom0 or driver domain. Previously even when we said a MFN is required, it's actually a BFN due to IOMMU existence, and it works just because we have a 1:1 identity mapping in-place. And by finding a BFN some follow-up think here: - one extra unmap call will have some performance impact, especially for media processing workloads where GPU page table modifications are hot. but suppose this can be optimized with batch request Yep. In general I'd hope that the extra overhead of unmap is small compared with the trap + emulate + ioreq + schedule that's just happened. Though I know that IOTLB shootdowns are potentially rather expensive right now so it might want some measurement. yes, that's the hard part requiring experiments to find a good balance between complexity and performance. IOMMU page table is not designed with same frequent modifications as CPU/GPU page tables, but following above trend make them connected. Another option might be reserve a big enough BFNs to cover all available guest memory at boot time, so to eliminate run-time modification overhead. - is there existing _map_ call for this purpose per your knowledge, or a new one is required? If the latter, what's the additional logic to be implemented there? For PVH, the XENMEM_add_to_physmap (gmfn_foreign) path ought to do what you need, I think. For PV, I think we probably need a new map operation with sensible semantics. My inclination would be to have it follow the grant-map semantics (i.e. caller supplies domid + gfn, hypervisor supplies BFN and success/failure code). setup mapping is not a big problem. it's more about finding available BFNs in a way not conflicting with other usages e.g. memory hotplug, ballooning (well for this I'm not sure now whether it's only for existing gfns from other thread...) Malcolm might have opinions about this -- it starts looking like the sort of PV IOMMU interface he's suggested before. we'd like to hear Malcolm's suggestion here. - when you say _map_, do you expect this mapped into dom0's virtual address space, or just guest physical space? For PVH, I mean into guest physical address space (and iommu tables, since those
Re: [Xen-devel] Xen 4.5 Development Update (GA slip by a week)
Monday, January 5, 2015, 9:08:32 PM, you wrote: Xen 4.5-rc4 was out on Monday (Dec 15th). The GA General Release is on Jan 7th^H^H^14th! There are some outstanding patches on which we need to figure out whether we will commit them in or not. When we commit a patch in, the OSSTest takes a day or so to push it to 'master' - and if it fails during that time patches that are later in the sequence are not applied. Hence if everything works out great - we get the patches to show up next day - however if something breaks - we are stalled. Ian(s) has pointed to me that the OSSTest is sometimes on the fritz and that it might take more than one day to push patches through which means we won't make it by Wednesday. As such, moving it the release by a week to give us ample room to get through those changes. These are the patches that need to be investigated whether they should go in or not: VT-d: don't crash when PTE bits 52 and up are non-zero VT-d: extend XSA-59 workaround to XeonE5 v3 (Haswell) VT-d: make XSA-59 workaround fully cover XeonE5/E7 v2 x86/VPMU: Clear last_vcpu when destroying VPMU tools/hotplug: add wrapper to start xenstored tools/hotplug: remove EnvironmentFile from xen-qemu-dom0-disk-backend.service tools/hotplug: use XENCONSOLED_TRACE in xenconsoled.service tools/hotplug: use xencommons as EnvironmentFile in xenconsoled.service tools/hotplug: xendomains.service depends on network tools/hotplug: remove XENSTORED_ROOTDIR from xenstored.service tools/hotplug: remove SELinux options from var-lib-xenstored.mount tools/libxl: Use of init()/dispose() to avoid leaking libxl_dominfo.ss xen: arm: correct off-by-one error in consider_module Hi Konrad, Has this: http://lists.xen.org/archives/html/xen-devel/2014-12/msg01715.html patch slipped through the cracks ? It has your release-ack but isn't applied yet, nor is it on the above short list. BTW: Will there be a branch off and one last non-debug RC before release ? (i thought that has been done in the past, but could be mistaken) -- Sander = Timeline = Xen 4.5 is a 10 month release. The dates are: * Feature Freeze: 24th September 2014 * First RC: 24th October [Friday!] * RC2: Nov 11th * RC2 Test-day: Nov 13th * RC3: Dec 3rd. * RC3 Test-day: Dec 4th * RC4: Dec 15th * RC4 Test-day: Dec 17th WE ARE HERE === Release Date: Jan 14th. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Parallel make supported?
On Tue, 2015-01-06 at 10:36 +, Wei Liu wrote: On Tue, Jan 06, 2015 at 12:08:33AM +, Peter Kay wrote: Peter, could you not top post and do trim your quotes please. root[xen-4.5.0-rc4]# ls -l tools/xenstore/libxenstore* -rw-r--r-- 1 root root 98580 Dec 19 22:02 tools/xenstore/libxenstore.a -rwxr-xr-x 1 root root 82624 Dec 19 22:02 tools/xenstore/libxenstore.so.3.0.3 Please see output of make -d -C tools/xenstore init-xenstore-domain attached - it's quite long uncompressed The log file suggests compilation of init-xenstore-domain is successful. :-/ If you encounter that problem with parallel build you might want to invoke make with -j? Sorry, my fault for not including that in the initial suggestion. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [Qemu-devel] bind interdomain ioctl error xen-kvm.c
On Mon, 2015-01-05 at 11:10 -0800, Rishi Ranjan wrote: Hi Stefano, Please find my answers inline. However Anthony (CC'ed) should have some patches for it. Anthony, can you please share any patch that can help me with this? Can you post the full output of the logs? I have attached the output of sudo xl -v create /etc/xen/qemu-pv.cfg as xl_create.txt. I have also enabled DEBUG_XEN_HVM in xen-hvm.c and pasted output of sudo ./x86_64-softmmu/qemu-system-x86_64 -machine q35,accel=xen -cpu qemu64 -xen-domid 13 below: Have you done anything which stops xl create from also launching a qemu? The guest cfg file you posted earlier didn't suggest so. Running two qemu's against the same domain doesn't seem likely to result in good things... Did you execute the xencommons init script at boot time? On Ubuntu I don't see /etc/init.d/xencommon but there is a /etc/init.d/xen script which starts xenstored and xenconsoled. Yes, Debian and Ubuntu don't use the upstream initscript but have their own. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [Qemu-devel] bind interdomain ioctl error xen-kvm.c
On Mon, Jan 05, 2015 at 11:10:34AM -0800, Rishi Ranjan wrote: However Anthony (CC'ed) should have some patches for it. Anthony, can you please share any patch that can help me with this? Hi, The patches are in two repos: git://xenbits.xen.org/people/aperard/xen-unstable.git branch: machine-q35-wip git://xenbits.xen.org/people/aperard/qemu-dm.git branch: xen-q35-wip For the xen tree, it's the 3 top commit, and the top commit for qemu. Once applied, hvmloader will only work with Q35 and not with the default machine. -- Anthony PERARD ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/7] tools/hotplug: remove SELinux options from var-lib-xenstored.mount
On Fri, 2014-12-19 at 12:25 +0100, Olaf Hering wrote: Using SELinux mount options per default breaks several systems. Either the context= mount option is not known at all to the kernel, as reported for ArchLinux. Or the default value none is unknown to SELinux, as reported for Fedora. In both cases the unit will fail. The proper place to specify mount options is /etc/fstab. Appearently systemd is kind enough to use values from there even if Options= or What= is specified in a .mount file. Remove XENSTORED_MOUNT_CTX, the reference to a non-existant EnvironmentFile and trim default Options= for the mount point. The removed code was first mentioned in the patch referenced below, with the following description: ... * Some systems define the selinux context in the systemd Option for the /var/lib/xenstored tmpfs: Options=mode=755,context=system_u:object_r:xenstored_var_lib_t:s0 For the upstream version we remove that and let systems specify the context on their system /etc/default/xenstored or /etc/sysconfig/xenstored $XENSTORED_MOUNT_CTX variable ... It is nowhere stated (on xen-devel) what Some systems means, which is unfortunately common practice in nearly all opensource projects. http://lists.xenproject.org/archives/html/xen-devel/2014-03/msg02462.html Signed-off-by: Olaf Hering o...@aepfle.de Cc: Ian Jackson ian.jack...@eu.citrix.com Cc: Stefano Stabellini stefano.stabell...@eu.citrix.com Acked-by: Ian Campbell ian.campb...@citrix.com (on commit s/Appearently/Apparently/; s/non-existant/non-existent/ in the commit log) -Options=mode=755,context=$XENSTORED_MOUNT_CTX +Options=mode=755 FWIW an alternative might have been: Options=mode=755,$XENSTORED_MOUNT_OPTIONS where the variable from the EnvironmentFile could contain context= as necessary (and maybe even mode=... by default). But if /etc/fstab is the Right Place(tm) then lets go with that for 4.5. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 4/7] tools/hotplug: use xencommons as EnvironmentFile in xenconsoled.service
On Fri, 2014-12-19 at 12:25 +0100, Olaf Hering wrote:
The referenced sysconfig/xenconsoled does not exist. If anything
needs to be specified it has to go into the existing
sysconfig/xencommons file.
That seems consistent with the initscript and the xencommons sysconfig
template even includes XENCONSOLED_TRACE as an example, so I think this
is correct.
Signed-off-by: Olaf Hering o...@aepfle.de
Cc: Ian Jackson ian.jack...@eu.citrix.com
Cc: Stefano Stabellini stefano.stabell...@eu.citrix.com
Acked-by: Ian Campbell ian.campb...@citrix.com
Cc: Wei Liu wei.l...@citrix.com
---
tools/hotplug/Linux/systemd/xenconsoled.service.in | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/hotplug/Linux/systemd/xenconsoled.service.in
b/tools/hotplug/Linux/systemd/xenconsoled.service.in
index cb44cd6..74d0428 100644
--- a/tools/hotplug/Linux/systemd/xenconsoled.service.in
+++ b/tools/hotplug/Linux/systemd/xenconsoled.service.in
@@ -9,7 +9,7 @@ Type=simple
Environment=XENCONSOLED_ARGS=
Environment=XENCONSOLED_LOG=none
Environment=XENCONSOLED_LOG_DIR=@XEN_LOG_DIR@/console
-EnvironmentFile=-@CONFIG_DIR@/@CONFIG_LEAF_DIR@/xenconsoled
+EnvironmentFile=@CONFIG_DIR@/@CONFIG_LEAF_DIR@/xencommons
PIDFile=@XEN_RUN_DIR@/xenconsoled.pid
ExecStartPre=/bin/grep -q control_d /proc/xen/capabilities
ExecStartPre=/bin/mkdir -p ${XENCONSOLED_LOG_DIR}
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 5/7] tools/hotplug: use XENCONSOLED_TRACE in xenconsoled.service
On Fri, 2014-12-19 at 12:25 +0100, Olaf Hering wrote:
Instead of inventing a new XENCONSOLED_LOG= variable reuse the
existing XENCONSOLED_TRACE= variable in xenconsoled.service.
Signed-off-by: Olaf Hering o...@aepfle.de
Cc: Ian Jackson ian.jack...@eu.citrix.com
Cc: Stefano Stabellini stefano.stabell...@eu.citrix.com
Acked-by: Ian Campbell ian.campb...@citrix.com
(should XENCONSOLED_LOG_DIR be changed for consistency?)
Cc: Wei Liu wei.l...@citrix.com
---
tools/hotplug/Linux/systemd/xenconsoled.service.in | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/hotplug/Linux/systemd/xenconsoled.service.in
b/tools/hotplug/Linux/systemd/xenconsoled.service.in
index 74d0428..4788129 100644
--- a/tools/hotplug/Linux/systemd/xenconsoled.service.in
+++ b/tools/hotplug/Linux/systemd/xenconsoled.service.in
@@ -7,13 +7,13 @@ ConditionPathExists=/proc/xen/capabilities
[Service]
Type=simple
Environment=XENCONSOLED_ARGS=
-Environment=XENCONSOLED_LOG=none
+Environment=XENCONSOLED_TRACE=none
Environment=XENCONSOLED_LOG_DIR=@XEN_LOG_DIR@/console
EnvironmentFile=@CONFIG_DIR@/@CONFIG_LEAF_DIR@/xencommons
PIDFile=@XEN_RUN_DIR@/xenconsoled.pid
ExecStartPre=/bin/grep -q control_d /proc/xen/capabilities
ExecStartPre=/bin/mkdir -p ${XENCONSOLED_LOG_DIR}
-ExecStart=@sbindir@/xenconsoled --pid-file @XEN_RUN_DIR@/xenconsoled.pid
--log=${XENCONSOLED_LOG} --log-dir=${XENCONSOLED_LOG_DIR} $XENCONSOLED_ARGS
+ExecStart=@sbindir@/xenconsoled --pid-file @XEN_RUN_DIR@/xenconsoled.pid
--log=${XENCONSOLED_TRACE} --log-dir=${XENCONSOLED_LOG_DIR} $XENCONSOLED_ARGS
[Install]
WantedBy=multi-user.target
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [Qemu-devel] bind interdomain ioctl error xen-kvm.c
On Tue, Jan 06, 2015 at 11:11:48AM +, Anthony PERARD wrote: On Mon, Jan 05, 2015 at 11:10:34AM -0800, Rishi Ranjan wrote: However Anthony (CC'ed) should have some patches for it. Anthony, can you please share any patch that can help me with this? Hi, The patches are in two repos: git://xenbits.xen.org/people/aperard/xen-unstable.git branch: machine-q35-wip git://xenbits.xen.org/people/aperard/qemu-dm.git branch: xen-q35-wip For the xen tree, it's the 3 top commit, and the top commit for qemu. Once applied, hvmloader will only work with Q35 and not with the default machine. To start a guest, I have this in the guest config: disk = [ 'phy:/dev/mapper/vg-guest_q35,sda,w' ] machine='q35' If you wish, you can recompile only hvmloader and qemu and have something like this in your guest config: firmware_override = '/root/hvmloader-q35' device_model_override = '/root/qemu-xen-q35' device_model_version = 'qemu-xen' device_model_args_hvm = [ '-machine', 'q35,accel=xen' ] Hope that help. -- Anthony PERARD ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 6/7] tools/hotplug: remove EnvironmentFile from xen-qemu-dom0-disk-backend.service
On Fri, 2014-12-19 at 12:25 +0100, Olaf Hering wrote: The references Environment file does not exist, and the service file referenced does not make use of variables anyway. In principal the env vars are also for the benefit of the thing launched by the Exec line too, not just the unit file. qemu-system-i386 does use getenv() but not in any way which looks relevant under Xen (e.g. linux-user/main.c uses it, but we don't care). If someone changes exec to something (e.g. a wrapper) which cares about envvars they can equally well set EnvironmentFile too. So: 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] [PATCH] tools: libxl: link libxlu against libxl.
On Wed, 2014-12-17 at 15:54 -0500, Konrad Rzeszutek Wilk wrote: On Mon, Dec 15, 2014 at 10:02:31AM +, Ian Campbell wrote: On Mon, 2014-08-04 at 10:58 +0100, Ian Campbell wrote: Ping again. This issue has resurfaced in the Debian packaging of the 4.5 rcs. I think we should fix this for 4.5, the risks are minimal. Ah, the patch did not have 'for-xen-4.5' in it :-P It uses libxl_defbool_set and must therefore be linked against the right library. Spotted by dpkg-shlibdeps and pointed out by Bastian Blank: dpkg-shlibdeps: warning: symbol libxl_defbool_set used by debian/libxen-4.4/usr/lib/libxlutil-4.4.so found in none of the libraries This required switching the make rule from $^ to an explicit LIBXLU_OBJS since the former now includes libxenlight.so. Signed-off-by: Ian Campbell ian.campb...@citrix.com Cc: Bastian Blank wa...@debian.org Shouldn't this be 'Reported-by: Anyhow, Release-Acked-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com Applied. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Xen 4.5 Development Update (GA slip by a week)
On Mon, 2015-01-05 at 15:08 -0500, konrad.w...@oracle.com wrote: tools/libxl: Use of init()/dispose() to avoid leaking libxl_dominfo.ss xen: arm: correct off-by-one error in consider_module I've just now applied both. Also I found these with release acks and applied them: tools: libxl: link libxlu against libxl. xen/arm: Initialize the domain vgic lock reset PCI devices on force removal even when QEMU returns error I was a little unsure about enacting Release-Acks given more than a few weeks ago, but I figured we could always revert if your opinion was that it was now too close to the release (my main concern would be the third one, the other two seem trivial enough). I also saw some patches regarding a Bison update, 21639.5225.596115.600...@mariner.uk.xensource.com et al, which I was expecting Ian J to take care of. I've not done anything about it either. I think it might be too late. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH for 4.5] xen/arm: Initialize the domain vgic lock
On Fri, 2014-12-19 at 09:23 -0500, Konrad Rzeszutek Wilk wrote: On Thu, Dec 18, 2014 at 09:47:37AM +, Ian Campbell wrote: On Wed, 2014-12-17 at 15:40 +, Julien Grall wrote: The domain vgic lock is used uninitialized. Signed-off-by: Julien Grall julien.gr...@linaro.org Acked-by: Ian Campbell ian.campb...@citrix.com Release-Acked-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com Applied. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH for-4.5] reset PCI devices on force removal even when QEMU returns error
On Wed, 2014-12-17 at 16:07 -0500, Konrad Rzeszutek Wilk wrote: On Mon, Dec 15, 2014 at 11:13:06AM +, Stefano Stabellini wrote: On Fri, 12 Dec 2014, Konrad Rzeszutek Wilk wrote: On Fri, Dec 12, 2014 at 04:13:52PM +0100, Sander Eikelenboom wrote: Hi Konrad, This doesn't seem to be applied yet, nor does it seem to have a release-(N)ACK from you ? Hm, Stefano: - Is this a regression? I don't think so. Probably a regression compared to the xend toolstack though. OK, so that is Xen 4.4 - Xen 4.5 regression then. Release-Acked-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com An updated version with the logging which I had indicated I would prefer doesn't appear to be forthcoming so I've just applied this one. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [Xen-users] HVM PCI Passthrough: Code 12: Undersized PCI MMIO region?
On Tue, Dec 02, 2014 at 10:08:35PM -0500, Stephen Oberholtzer wrote: All, Hello, Please bear with me. I don't fully understand all of the mechanisms involved here, so this message contains a large quantity of data, including some links to even larger quantities of data. The short version is: I think something isn't reserving enough (GPFN) address space for MMIO. This issue probably should be taken to xen-devel mailinglist.. CC added.. I'm trying to do a three-part PCI passthrough to a HVM domU running Windows 8.1: 00:14.0, An xHCI (USB 3.0) controller 01:00.0, Function 0 of an ATI card (VGA controller, non-primary passthrough) 01:00.1, Function 1 of the same ATI card (HDMI audio) The USB controller seems to work fine. USB mouse/keyboard are functional, and I plugged in a few Mass Storage devices and they work fine. The HDMI audio controller is harder to vet, because I don't have anything that will process audio without an associated video stream. However, I don't get any complains from the software. For the the VGA controller (01:00.0), Windows reports Code 12 and complains about insufficient resources being available for the device. I tried to gather all of the information I could on the memory layouts involved, from three sources: (1) From dom0 and Xen itself (2) From domU running Windows, using a program called SIV (System Information Viewer) (3) From domU running Linux (by booting a Knoppix live DVD image) --- Information from dom0: http://www.klozoff.org/xen/dom0-xl-info.txt - 'xl info' http://www.klozoff.org/xen/dom0-xl-dmesg.txt - 'xl dmesg' http://www.klozoff.org/xen/dom0-proc_iomem.txt - 'cat /proc/iomem' http://www.klozoff.org/xen/dom0-lspci-output.txt - 'lspci -vvv' for the three devices I'm forwarding. Information from domU (Windows): http://www.klozoff.org/xen/domU-device-manager-info.txt - Text transcribed from Windows' Device Manager http://www.klozoff.org/xen/domU-siv-usb-controller-info.txt - Information on 00:14.0 from SIV http://www.klozoff.org/xen/domU-siv-video-card-info.txt - Information on 01:00.0 from SIV http://www.klozoff.org/xen/domU-siv-hdmi-audio-info.txt - Information on 01:00.1 from SIV Information from domU (Linux/Knoppix): http://www.klozoff.org/xen/domU-knoppix-proc-iomem.txt - 'cat /proc/iomem' http://www.klozoff.org/xen/domU-knoppix-lspci-output.txt - 'lspci -vvv' for the three devices. --- Of particular interest to me is domU-knoppix-lspci-output.txt, which for the VGA controller, says: Region 0: Memory at ignored (64-bit, prefetchable) Region 2: Memory at f304 (64-bit, non-prefetchable) [size=256K] In dom0, this showed as: Region 0: Memory at d000 (64-bit, prefetchable) [size=256M] Region 2: Memory at efc0 (64-bit, non-prefetchable) [size=256K] I looked closer by running the following script: perl -lne '/^([0-9a-f]+)-([0-9a-f]+)/ print $_, (, ((hex($2) - hex($1)) 20), MB)' /proc/iomem In dom0, I see this: 0010-99f53fff : System RAM (2462 MB) bf20-feaf : PCI Bus :00 (1016 MB) - Region 0 is in this range 1-83edf : System RAM (29677 MB) In domU, I see this: 0010-effecfff : System RAM (3838 MB) f000-fbff : PCI Bus :00 (191 MB)- Definitely not big enough to hold the 256MB we need 1-20f7f : System RAM (4343 MB) Now, I don't fully understand how this stuff all works, but here's what appears to be happening: Xen isn't reserving enough contiguous GPFN (virtual machine address space) for all of the devices on the virtual PCI bus -- in particular, for what is probably a big honkin' window into the card's onboard RAM. So my two questions are: (1) Is my guess correct? Or at least close? (2) What the heck do I do about it? I don't see any options in xl.cfg(5) for specifying the size of the MMIO region for the virtual PCI bus, or anything similar to that. NOTE: If I assign 2048MB or less RAM to this VM, the VM crashes at bootup, and has a nasty tendency to take the host with it (lockup). -- -- Stevie-O Real programmers use COPY CON PROGRAM.EXE -- Pasi ___ Xen-users mailing list xen-us...@lists.xen.org http://lists.xen.org/xen-users ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH for-4.5] tools/libxl: Use of init()/dispose() to avoid leaking libxl_dominfo.ssid_label
On Mon, 2015-01-05 at 10:33 -0500, Konrad Rzeszutek Wilk wrote:
On Mon, Jan 05, 2015 at 02:19:58PM +, Andrew Cooper wrote:
libxl_dominfo contains a ssid_label pointer which will have memory allocated
for it in libxl_domain_info() if the hypervisor has CONFIG_XSM compiled.
However, the lack of appropriate use of libxl_dominfo_{init,dispose}() will
cause the label string to be leaked, even in success cases.
This was discovered by XenServers Coverity scanning, and are issues not
identified by upstream Coverity Scan.
Signed-off-by: Andrew Cooper andrew.coop...@citrix.com
CC: Ian Campbell ian.campb...@citrix.com
CC: Ian Jackson ian.jack...@eu.citrix.com
CC: Wei Liu wei.l...@citrix.com
CC: Konrad Rzeszutek Wilk konrad.w...@oracle.com
---
Requesting a release-exception as suggested by IanJ. These are memory leaks
which accumulate via the successful completion of libxl library functions
(if
XSM is enabled), which will undoubtedly cause issues for the likes of
libvirt
and xenopsd-libxl which use libxl in daemon processes.
Release-Acked-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com
Somehow I don't seem to have the original in any folder, I probably fat
fingered the D key at some point.
Anyway, this looks good to me for 4.5:
Acked-by: Ian Campbell ian.campb...@citrix.com
Applied.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 1/4] pci: Do not ignore device's PXM information
On 06/01/15 02:18, Boris Ostrovsky wrote:
diff --git a/xen/include/xen/pci.h b/xen/include/xen/pci.h
index 5f295f3..a5eb81c 100644
--- a/xen/include/xen/pci.h
+++ b/xen/include/xen/pci.h
@@ -56,6 +56,8 @@ struct pci_dev {
u8 phantom_stride;
+int node; /* NUMA node */
+
enum pdev_type {
DEV_TYPE_PCI_UNKNOWN,
DEV_TYPE_PCIe_ENDPOINT,
@@ -102,7 +104,8 @@ void setup_hwdom_pci_devices(struct domain *,
int pci_release_devices(struct domain *d);
int pci_add_segment(u16 seg);
const unsigned long *pci_get_ro_map(u16 seg);
-int pci_add_device(u16 seg, u8 bus, u8 devfn, const struct pci_dev_info *);
+int pci_add_device(u16 seg, u8 bus, u8 devfn,
+ const struct pci_dev_info *, int);
Please use parameter names in definitions.
~Andrew
int pci_remove_device(u16 seg, u8 bus, u8 devfn);
int pci_ro_device(int seg, int bus, int devfn);
void arch_pci_ro_device(int seg, int bdf);
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH] xen/blkfront: restart request queue when there is enough persistent_gnts_c
When there is no enough free grants, gnttab_alloc_grant_references() will fail and block request queue will stop. If the system is always lack of grants, blkif_restart_queue_callback() can't be scheduled and block request queue can't be restart(block I/O hang). But when there are former requests complete, some grants may free to persistent_gnts_c, we can give the request queue another chance to restart and avoid block hang. Reported-by: Junxiao Bi junxiao...@oracle.com Signed-off-by: Bob Liu bob@oracle.com --- drivers/block/xen-blkfront.c | 11 +++ 1 file changed, 11 insertions(+) diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c index 2236c6f..dd30f99 100644 --- a/drivers/block/xen-blkfront.c +++ b/drivers/block/xen-blkfront.c @@ -1125,6 +1125,17 @@ static void blkif_completion(struct blk_shadow *s, struct blkfront_info *info, } } } + + /* +* Request queue would be stopped if failed to alloc enough grants and +* won't be restarted until gnttab_free_count = info-callback-count. +* +* But there is another case, once we have enough persistent grants we +* can try to restart the request queue instead of continue to wait for +* 'gnttab_free_count'. +*/ + if (info-persistent_gnts_c = info-callback.count) + schedule_work(info-work); } static irqreturn_t blkif_interrupt(int irq, void *dev_id) -- 1.7.10.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 7/7] tools/hotplug: add wrapper to start xenstored
On Fri, 2014-12-19 at 12:25 +0100, Olaf Hering wrote: The shell wrapper in xenstored.service does not handle XENSTORE_TRACE. Create a separate wrapper script which is used in the sysv runlevel script and in systemd xenstored.service. It preserves existing behaviour by handling the XENSTORE_TRACE boolean. It also implements the handling of XENSTORED_ARGS=. This variable has to be added to sysconfig/xencommons. Why don't we just drop XENSTORED_* in favour of XENSTORED_ARGS (with an example in the sysconfig file of enabling tracing if you like)? Going to a wrapper script just to make some fairly uncommon debugging option marginally more convenient seems like overkill to me, plus XENSTORED_ARGS would allow for passing other useful options to xenstored. The wrapper uses exec unconditionally. This works because the systemd service file passes --no-fork, which has the desired effect that the binary launched by systemd becomes the final daemon process. The sysv script does not pass --no-fork, which causes xenstored to fork internally to return to the caller of the wrapper script. The place of the wrapper is currently LIBEXEC_BIN, it has to be decided what the final location is supposed to be. IanJ wants it in /etc. If we go this route then I agree with Ian J. (/etc/xen/scripts, I suppose). Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen: arm: correct off-by-one error in consider_modules
On Mon, 2015-01-05 at 11:17 -0500, Konrad Rzeszutek Wilk wrote: On Mon, Dec 22, 2014 at 11:54:01AM +0100, Julien Grall wrote: Hi Ian, On 21/12/2014 12:18, Ian Campbell wrote: By iterating up to = mi-nr_mods we are running off the end of the boot modules, but more importantly it causes us to then skip the first FDT reserved region, meaning we might clobber it. Oops. Good catch! OOI, how did you find it? Signed-off-by: Ian Campbell i...@hellion.org.uk Reviewed-by: Julien Grall julien.gr...@linaro.org --- For 4.5: I think this bug fix should go in, it fixes a real issue and is low risk. Release-Acked-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com Applied, thanks. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] smmu/ccp warnings on Seattle
Hello, On 06/01/15 12:50, Jintack Lim wrote: While Xen was booting on Seattle, I got warnings/errors related to smmu and ccp. Eventually Seattle was rebooted. These are the relevant logs (and more warnings in a full log at the bottom). The support of Seattle in the SMMU drivers is missing. I would advise you to disable the IOMMU for now (iommu=disable on Xen command line). Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Xen 4.5 Development Update (GA slip by a week)
On Tue, Jan 06, 2015 at 11:43:47AM +, Ian Campbell wrote: On Mon, 2015-01-05 at 15:08 -0500, konrad.w...@oracle.com wrote: tools/libxl: Use of init()/dispose() to avoid leaking libxl_dominfo.ss xen: arm: correct off-by-one error in consider_module I've just now applied both. Also I found these with release acks and applied them: tools: libxl: link libxlu against libxl. xen/arm: Initialize the domain vgic lock reset PCI devices on force removal even when QEMU returns error I was a little unsure about enacting Release-Acks given more than a few weeks ago, but I figured we could always revert if your opinion was that it was now too close to the release (my main concern would be the third one, the other two seem trivial enough). I am OK with the Release-Acks staying active. Thank you for checking. I also saw some patches regarding a Bison update, 21639.5225.596115.600...@mariner.uk.xensource.com et al, which I was expecting Ian J to take care of. I've not done anything about it either. I think it might be too late. I was OK with the bison update patch. Ian J convienced me it is worth it. IanJ, are you OK putting it in or would prefer to skip to 4.6? Or alternatively I can dig up the patch and apply it. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Xen 4.5 Development Update (GA slip by a week)
(CC list massively trimmed) Konrad Rzeszutek Wilk writes (Re: Xen 4.5 Development Update (GA slip by a week)): On Tue, Jan 06, 2015 at 11:43:47AM +, Ian Campbell wrote: I also saw some patches regarding a Bison update, 21639.5225.596115.600...@mariner.uk.xensource.com et al, which I was expecting Ian J to take care of. I've not done anything about it either. I think it might be too late. I was OK with the bison update patch. Ian J convienced me it is worth it. IanJ, are you OK putting it in or would prefer to skip to 4.6? I will do this today. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC 2/2] x86, vdso, pvclock: Simplify and speed up the vdso pvclock reader
On Mon, Jan 05, 2015 at 10:56:07AM -0800, Andy Lutomirski wrote:
On Mon, Jan 5, 2015 at 7:25 AM, Marcelo Tosatti mtosa...@redhat.com wrote:
On Mon, Dec 22, 2014 at 04:39:57PM -0800, Andy Lutomirski wrote:
The pvclock vdso code was too abstracted to understand easily and
excessively paranoid. Simplify it for a huge speedup.
This opens the door for additional simplifications, as the vdso no
longer accesses the pvti for any vcpu other than vcpu 0.
Before, vclock_gettime using kvm-clock took about 64ns on my machine.
With this change, it takes 19ns, which is almost as fast as the pure TSC
implementation.
Signed-off-by: Andy Lutomirski l...@amacapital.net
---
arch/x86/vdso/vclock_gettime.c | 82
--
1 file changed, 47 insertions(+), 35 deletions(-)
diff --git a/arch/x86/vdso/vclock_gettime.c
b/arch/x86/vdso/vclock_gettime.c
index 9793322751e0..f2e0396d5629 100644
--- a/arch/x86/vdso/vclock_gettime.c
+++ b/arch/x86/vdso/vclock_gettime.c
@@ -78,47 +78,59 @@ static notrace const struct pvclock_vsyscall_time_info
*get_pvti(int cpu)
static notrace cycle_t vread_pvclock(int *mode)
{
- const struct pvclock_vsyscall_time_info *pvti;
+ const struct pvclock_vcpu_time_info *pvti = get_pvti(0)-pvti;
cycle_t ret;
- u64 last;
- u32 version;
- u8 flags;
- unsigned cpu, cpu1;
-
+ u64 tsc, pvti_tsc;
+ u64 last, delta, pvti_system_time;
+ u32 version, pvti_tsc_to_system_mul, pvti_tsc_shift;
/*
- * Note: hypervisor must guarantee that:
- * 1. cpu ID number maps 1:1 to per-CPU pvclock time info.
- * 2. that per-CPU pvclock time info is updated if the
- *underlying CPU changes.
- * 3. that version is increased whenever underlying CPU
- *changes.
+ * Note: The kernel and hypervisor must guarantee that cpu ID
+ * number maps 1:1 to per-CPU pvclock time info.
+ *
+ * Because the hypervisor is entirely unaware of guest userspace
+ * preemption, it cannot guarantee that per-CPU pvclock time
+ * info is updated if the underlying CPU changes or that that
+ * version is increased whenever underlying CPU changes.
+ *
+ * On KVM, we are guaranteed that pvti updates for any vCPU are
+ * atomic as seen by *all* vCPUs. This is an even stronger
+ * guarantee than we get with a normal seqlock.
*
+ * On Xen, we don't appear to have that guarantee, but Xen still
+ * supplies a valid seqlock using the version field.
+
+ * We only do pvclock vdso timing at all if
+ * PVCLOCK_TSC_STABLE_BIT is set, and we interpret that bit to
+ * mean that all vCPUs have matching pvti and that the TSC is
+ * synced, so we can just look at vCPU 0's pvti.
*/
Can Xen guarantee that ?
I think so, vacuously. Xen doesn't seem to set PVCLOCK_TSC_STABLE_BIT
at all. I have no idea going forward, though.
Xen people?
The person who would know of the top of his head is Dan Magenheimer, who
is now enjoy retirement :-(
I will have to dig in the code to answer this - that will take a bit of time
sadly (I am sick this week).
- do {
- cpu = __getcpu() VGETCPU_CPU_MASK;
- /* TODO: We can put vcpu id into higher bits of pvti.version.
- * This will save a couple of cycles by getting rid of
- * __getcpu() calls (Gleb).
- */
-
- pvti = get_pvti(cpu);
-
- version = __pvclock_read_cycles(pvti-pvti, ret, flags);
-
- /*
- * Test we're still on the cpu as well as the version.
- * We could have been migrated just after the first
- * vgetcpu but before fetching the version, so we
- * wouldn't notice a version change.
- */
- cpu1 = __getcpu() VGETCPU_CPU_MASK;
- } while (unlikely(cpu != cpu1 ||
- (pvti-pvti.version 1) ||
- pvti-pvti.version != version));
-
- if (unlikely(!(flags PVCLOCK_TSC_STABLE_BIT)))
+
+ if (unlikely(!(pvti-flags PVCLOCK_TSC_STABLE_BIT))) {
*mode = VCLOCK_NONE;
+ return 0;
+ }
This check must be performed after reading a stable pvti.
We can even read it in the middle, guarded by the version checks.
I'll do that for v2.
+
+ do {
+ version = pvti-version;
+
+ /* This is also a read barrier, so we'll read version first.
*/
+ rdtsc_barrier();
+ tsc = __native_read_tsc();
+
+ pvti_tsc_to_system_mul = pvti-tsc_to_system_mul;
+ pvti_tsc_shift = pvti-tsc_shift;
+ pvti_system_time = pvti-system_time;
+ pvti_tsc = pvti-tsc_timestamp;
+
+
Re: [Xen-devel] [PATCH 4/7] tools/hotplug: use xencommons as EnvironmentFile in xenconsoled.service
Olaf Hering writes ([PATCH 4/7] tools/hotplug: use xencommons as EnvironmentFile in xenconsoled.service): The referenced sysconfig/xenconsoled does not exist. If anything needs to be specified it has to go into the existing sysconfig/xencommons file. Acked-by: Ian Jackson ian.jack...@eu.citrix.com Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 2/4] sysctl: Make XEN_SYSCTL_topologyinfo sysctl a little more efficient
On 06/01/15 02:18, Boris Ostrovsky wrote:
Instead of copying data for each field in xen_sysctl_topologyinfo separately
put cpu/socket/node into a single structure and do a single copy for each
processor.
There is also no need to copy whole op to user at the end, max_cpu_index is
sufficient
Rename xen_sysctl_topologyinfo and XEN_SYSCTL_topologyinfo to reflect the fact
that these are used for CPU topology. Subsequent patch will add support for
PCI topology sysctl.
Signed-off-by: Boris Ostrovsky boris.ostrov...@oracle.com
If we are going to change the hypercall, then can we see about making it
a stable interface (i.e. not a sysctl/domctl)? There are non-toolstack
components which might want/need access to this information. (i.e. I am
still looking for a reasonable way to get this information from Xen in
hwloc)
snip
+if ( cpu_online(i) )
{
-uint32_t socket = cpu_online(i) ? cpu_to_socket(i) : ~0u;
-if ( copy_to_guest_offset(ti-cpu_to_socket, i, socket, 1) )
-break;
+cputopo.core = cpu_to_core(i);
+cputopo.socket = cpu_to_socket(i);
+cputopo.node = cpu_to_node(i);
}
-if ( !guest_handle_is_null(ti-cpu_to_node) )
+else
+cputopo.core = cputopo.socket =
+cputopo.node = INVALID_TOPOLOGY_ID;
+
In particular, can we fix this broken behaviour. The cpu being online
or not has no bearing on whether Xen has topology information, and a
side effect is that when the cpu governer powers down a cpu, it
disappears from the reported topology.
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [qemu-mainline test] 33176: regressions - trouble: blocked/fail/pass/preparing/queued/running
flight 33176 qemu-mainline running [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/33176/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-win7-amd64none executed queued test-amd64-i386-xl-win7-amd64none executed queued test-amd64-i386-xl-qemuu-winxpsp3-vcpus1none executed queued test-amd64-i386-xl-winxpsp3 none executed queued test-amd64-i386-xl-qemuu-winxpsp3none executed queued test-amd64-i386-qemuu-rhel6hvm-intelnone executed queued test-amd64-i386-freebsd10-i386none executed queued test-amd64-i386-xl-qemuu-ovmf-amd64none executed queued test-amd64-amd64-xl-winxpsp3none executed queued test-amd64-amd64-xl-qemuu-ovmf-amd64none executed queued test-amd64-amd64-xl-pvh-intelnone executed queued test-amd64-i386-freebsd10-amd64none executed queued test-amd64-i386-xl-qemuu-debianhvm-amd64none executed queued test-amd64-i386-xl-qemuu-win7-amd64none executed queued test-amd64-i386-xl-winxpsp3-vcpus1none executed queued test-amd64-i386-qemuu-rhel6hvm-amdnone executed queued test-amd64-i386-rhel6hvm-intelnone executed queued test-amd64-i386-rhel6hvm-amdnone executed queued test-amd64-amd64-xl-qemuu-winxpsp3none executed queued test-armhf-armhf-xl 3 host-install(3) running [st=running!] test-amd64-amd64-libvirtnone executed queued test-amd64-amd64-xl-pcipt-intelnone executed queued test-amd64-amd64-xl-qemuu-win7-amd64none executed queued test-amd64-amd64-xl-qemuu-debianhvm-amd64none executedqueued test-amd64-i386-qemut-rhel6hvm-amdnone executed queued build-i386-libvirt none executed queued test-amd64-amd64-xl-pvh-amd none executed queued test-amd64-i386-libvirt none executed queued test-amd64-i386-qemut-rhel6hvm-intelnone executed queued test-amd64-amd64-xl none executed queued test-amd64-amd64-xl-sedf-pinnone executed queued test-amd64-i386-xl none executed queued test-amd64-i386-xl-credit2 none executed queued test-amd64-i386-xl-qemut-win7-amd64none executed queued test-amd64-amd64-xl-sedfnone executed queued build-armhf-libvirt 5 libvirt-build fail REGR. vs. 32598 build-i386-pvops 2 hosts-allocate running [st=running!] build-amd64-libvirt none executed queued test-amd64-i386-xl-qemut-winxpsp3-vcpus1none executed queued test-amd64-amd64-pair none executed queued test-amd64-amd64-xl-qemut-winxpsp3none executed queued test-amd64-i386-xl-qemut-debianhvm-amd64none executed queued test-amd64-i386-xl-multivcpunone executed queued build-amd64-pvops 2 hosts-allocate running [st=running!] build-amd64 2 hosts-allocate running [st=running!] test-amd64-amd64-xl-qemut-win7-amd64none executed queued build-i3862 hosts-allocate running [st=running!] test-amd64-amd64-xl-qemut-debianhvm-amd64none executedqueued test-amd64-i386-xl-qemut-winxpsp3none executed queued test-amd64-i386-pairnone executed queued Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 1 build-check(1) blocked n/a version targeted for testing: qemuuab0302ee764fd702465aef6d88612cdff4302809 baseline version: qemuu7e58e2ac7778cca3234c33387e49577bb7732714 People who touched revisions under test: Alex Williamson alex.william...@redhat.com Eric Auger eric.au...@linaro.org Fabian Aggeler aggel...@ethz.ch Frank Blaschka blasc...@linux.vnet.ibm.com Greg Bellows greg.bell...@linaro.org Kim Phillips kim.phill...@linaro.org Laszlo Ersek ler...@redhat.com Marcel Apfelbaum marce...@redhat.com Paolo Bonzini pbonz...@redhat.com Peter Maydell peter.mayd...@linaro.org jobs: build-amd64 preparing build-armhf pass build-i386 preparing build-amd64-libvirt queued build-armhf-libvirt
[Xen-devel] [xen-4.4-testing test] 33181: trouble: pass/preparing/queued/running
flight 33181 xen-4.4-testing running [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/33181/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-rhel6hvm-amdnone executed queued build-amd64-libvirt none executed queued test-amd64-amd64-xl-qemuu-ovmf-amd64none executed queued build-amd64-xend 2 hosts-allocate running [st=running!] test-amd64-amd64-pv none executed queued test-amd64-i386-pairnone executed queued test-amd64-i386-xl-winxpsp3-vcpus1none executed queued test-amd64-i386-qemuu-rhel6hvm-intelnone executed queued build-i386-xend 2 hosts-allocate running [st=running!] test-amd64-i386-xl-win7-amd64none executed queued test-amd64-i386-qemut-rhel6hvm-intelnone executed queued test-amd64-i386-xl-qemuu-ovmf-amd64none executed queued build-armhf-pvops 5 kernel-build running [st=running!] test-amd64-i386-pv none executed queued test-amd64-amd64-xl-qemuu-winxpsp3none executed queued test-amd64-i386-qemut-rhel6hvm-amdnone executed queued test-armhf-armhf-libvirtnone executed queued test-amd64-amd64-xl-pcipt-intelnone executed queued test-amd64-i386-xl-qemuu-winxpsp3-vcpus1none executed queued test-amd64-i386-freebsd10-amd64none executed queued test-amd64-i386-rumpuserxen-i386none executed queued test-amd64-amd64-xl-qemuu-debianhvm-amd64none executedqueued test-amd64-i386-xl-qemut-winxpsp3-vcpus1none executed queued test-amd64-i386-rhel6hvm-intelnone executed queued test-amd64-amd64-xl-sedfnone executed queued test-amd64-i386-xend-winxpsp3none executed queued test-amd64-amd64-xl-winxpsp3none executed queued test-amd64-i386-libvirt none executed queued test-amd64-amd64-pair none executed queued test-amd64-i386-xl-multivcpunone executed queued build-armhf-libvirt 2 hosts-allocate running [st=running!] build-amd64-rumpuserxen none executed queued test-amd64-amd64-rumpuserxen-amd64none executed queued test-amd64-i386-freebsd10-i386none executed queued build-i386-libvirt none executed queued test-amd64-amd64-xl none executed queued test-amd64-i386-xl-qemut-win7-amd64none executed queued test-amd64-amd64-libvirtnone executed queued test-amd64-amd64-xl-qemuu-win7-amd64none executed queued test-armhf-armhf-xl none executed queued test-amd64-i386-xend-qemut-winxpsp3none executed queued test-amd64-i386-xl-qemuu-win7-amd64none executed queued test-amd64-amd64-xl-win7-amd64none executed queued test-amd64-amd64-xl-qemut-winxpsp3none executed queued build-amd64-pvops 2 hosts-allocate running [st=running!] test-amd64-amd64-xl-qemut-debianhvm-amd64none executedqueued test-amd64-i386-xl-credit2 none executed queued test-amd64-i386-xl-qemut-debianhvm-amd64none executed queued test-amd64-amd64-xl-qemut-win7-amd64none executed queued build-i3862 hosts-allocate running [st=running!] test-amd64-i386-qemuu-rhel6hvm-amdnone executed queued test-amd64-i386-xl-qemuu-debianhvm-amd64none executed queued build-i386-rumpuserxen none executed queued build-amd64 2 hosts-allocate running [st=running!] test-amd64-amd64-xl-sedf-pinnone executed queued test-amd64-i386-xl none executed queued build-i386-pvops 2 hosts-allocate running [st=running!] version targeted for testing: xen 089dd62211042011e26de1b87b558394cdfe388b baseline version: xen 7bb6b2722be1e27f99948e5c68f7f42eb23f8e53 People who touched revisions under test: Mihai DonÈu mdo...@bitdefender.com RÄzvan Cojocaru rcojoc...@bitdefender.com jobs: build-amd64-xend preparing build-i386-xend preparing build-amd64 preparing build-armhf
Re: [Xen-devel] [PATCH OSSTEST v3] ts-libvirt-build: use Osstest::BuildSupport::submodulefixup
On Mon, 2015-01-05 at 15:53 +, Ian Campbell wrote: On Mon, 2015-01-05 at 15:36 +, Ian Campbell wrote: Instead of cloning gnulib manually which can break if upstream gnulib gets ahead of libvirt.git (which applies patches on the fly etc). By using submodulefixup we automatically DTRT and use the version of gnulib specified by the libvirt.git submodule metadata, but with a runvar override if necessary. This also removes a whole bunch of faffing in ap-*, cr-daily-branch and mfi-common to get the version of gnulib to use, which was always a bit of a wart (ungated for one thing...). We continue to use --no-git and GNULIB_SRCDIR because otherwise autogen.sh (via bootstrap) will force its own version, overwriting what submodulefixup has done. For this we need a way to get the hash representing the module, so introduce submodule_find (and rework submodule_have in terms of it). Tested in standalone mode with build-amd64-libvirt and build-amd64-rumpuserxen (because I touched submodule_have, AFAICT the bodges were not run). The libvirt build was tested both with the automatic revisions and with: revision_libvirt=2360fe5d24175835d3f5fd1c7e8e6e13addab629 revision_libvirt_gnulib=16518d9ed8f25d3e53931dd1aa343072933e4604 (used in successful libvirt flight 32648), in both cases confirming that the build used the desired versions. Signed-off-by: Ian Campbell ian.campb...@citrix.com Ian J acked on IRC so I have pushed to osstests' pretest branch. The flight which tested this had a couple of fails, but everything related to this change passed, so after consulting with Ian J I force pushed this changeset and killed all the inprogress jobs (none of which could have passed). Any new flights have a chance of passing again now. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [linux-linus test] 33156: regressions - trouble: blocked/fail/pass/preparing/queued/running
flight 33156 linux-linus running [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/33156/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-pvh-intelnone executed queued test-amd64-i386-libvirt none executed queued test-amd64-amd64-rumpuserxen-amd64none executed queued test-amd64-i386-rumpuserxen-i386 2 hosts-allocate running [st=running!] test-amd64-amd64-libvirtnone executed queued test-amd64-amd64-xl-pvh-amd none executed queued test-amd64-amd64-xl-pcipt-intelnone executed queued test-amd64-i386-rhel6hvm-amd 2 hosts-allocate running [st=running!] test-amd64-i386-qemut-rhel6hvm-amd 2 hosts-allocate running [st=running!] test-amd64-i386-qemuu-rhel6hvm-amd 2 hosts-allocate running [st=running!] build-i386-libvirt3 host-install(3) running [st=running!] test-amd64-i386-freebsd10-i386 2 hosts-allocate running [st=running!] test-amd64-amd64-xl none executed queued test-amd64-amd64-xl-sedfnone executed queued test-amd64-amd64-xl-sedf-pinnone executed queued test-amd64-i386-qemut-rhel6hvm-intel 2 hosts-allocate running [st=running!] test-amd64-i386-xl-multivcpu 2 hosts-allocate running [st=running!] build-amd64-libvirt 2 hosts-allocate running [st=running!] test-amd64-i386-xl3 host-install(3) running [st=running!] test-amd64-i386-qemuu-rhel6hvm-intel 2 hosts-allocate running [st=running!] build-armhf-libvirt 5 libvirt-build fail REGR. vs. 32879 test-amd64-i386-xl-credit22 hosts-allocate running [st=running!] test-amd64-i386-rhel6hvm-intel 2 hosts-allocate running [st=running!] build-amd64-pvops 2 hosts-allocate running [st=running!] test-amd64-amd64-xl-winxpsp3none executed queued test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 2 hosts-allocate running [st=running!] test-amd64-i386-xl-qemuu-winxpsp3 2 hosts-allocate running [st=running!] test-amd64-i386-xl-qemuu-ovmf-amd64 2 hosts-allocaterunning [st=running!] test-amd64-i386-xl-qemut-debianhvm-amd64 2 hosts-allocate running [st=running!] test-amd64-i386-xl-qemuu-debianhvm-amd64 2 hosts-allocate running [st=running!] test-amd64-i386-xl-qemut-win7-amd64 2 hosts-allocaterunning [st=running!] test-amd64-amd64-pair none executed queued test-amd64-i386-xl-qemuu-win7-amd64 2 hosts-allocaterunning [st=running!] test-amd64-i386-xl-win7-amd64 2 hosts-allocate running [st=running!] test-amd64-amd64-xl-win7-amd64none executed queued test-amd64-amd64-xl-qemut-debianhvm-amd64none executedqueued test-amd64-amd64-xl-qemuu-debianhvm-amd64none executedqueued test-amd64-amd64-xl-qemuu-ovmf-amd64none executed queued test-amd64-i386-xl-winxpsp3-vcpus1 2 hosts-allocate running [st=running!] test-amd64-amd64-xl-qemut-winxpsp3none executed queued test-amd64-i386-xl-qemut-winxpsp3-vcpus1 2 hosts-allocate running [st=running!] test-amd64-i386-pair 2 hosts-allocate running [st=running!] test-amd64-i386-xl-winxpsp3 2 hosts-allocate running [st=running!] test-amd64-amd64-xl-qemut-win7-amd64none executed queued test-amd64-i386-xl-qemut-winxpsp3 2 hosts-allocate running [st=running!] test-amd64-amd64-xl-qemuu-winxpsp3none executed queued test-amd64-amd64-xl-qemuu-win7-amd64none executed queued Regressions which are regarded as allowable (not blocking): test-amd64-i386-freebsd10-amd64 7 freebsd-install fail like 32879 Tests which did not succeed, but are not blocking: test-armhf-armhf-xl 10 migrate-support-checkfail never pass test-armhf-armhf-libvirt 1 build-check(1) blocked n/a version targeted for testing: linuxb1940cd21c0f4abdce101253e860feff547291b0 baseline version: linux9bb29b6b927bcd79cf185ee67bcebfe630f0dea1 People who touched revisions under test: Alan Stern st...@rowland.harvard.edu Andrew Jackson andrew.jack...@arm.com Anil Chintalapati (achintal) achin...@cisco.com Anil Chintalapati achin...@cisco.com Christoph Hellwig h...@lst.de Daniel Borkmann dbork...@redhat.com Daniel Walter d.wal...@0x90.at Fang, Yang A yang.a.f...@intel.com Hannes Reinecke h...@suse.de Hari Bathini hbath...@linux.vnet.ibm.com Herbert Xu herb...@gondor.apana.org.au Hiral Shah his...@cisco.com James Bottomley jbottom...@parallels.com Jarkko Nikula jarkko.nik...@linux.intel.com Jianqun Xu jay...@rock-chips.com Jie
[Xen-devel] [xen-4.3-testing test] 33179: regressions - trouble: fail/pass/preparing/queued/running
flight 33179 xen-4.3-testing running [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/33179/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-rhel6hvm-amdnone executed queued build-amd64-libvirt none executed queued test-amd64-amd64-xl-qemuu-ovmf-amd64none executed queued test-amd64-amd64-pv none executed queued test-amd64-i386-pairnone executed queued test-amd64-i386-xl-winxpsp3-vcpus1none executed queued test-amd64-i386-qemuu-rhel6hvm-intelnone executed queued test-amd64-i386-xl-win7-amd64none executed queued test-amd64-i386-qemut-rhel6hvm-intelnone executed queued test-amd64-i386-xl-qemuu-ovmf-amd64none executed queued build-armhf-pvops 5 kernel-build running [st=running!] test-amd64-i386-pv none executed queued test-amd64-amd64-xl-qemuu-winxpsp3none executed queued test-amd64-i386-qemut-rhel6hvm-amdnone executed queued test-armhf-armhf-libvirtnone executed queued test-amd64-amd64-xl-pcipt-intelnone executed queued test-amd64-i386-xl-qemuu-winxpsp3-vcpus1none executed queued test-amd64-i386-freebsd10-amd64none executed queued test-amd64-i386-rumpuserxen-i386none executed queued test-amd64-amd64-xl-qemuu-debianhvm-amd64none executedqueued test-amd64-i386-xl-qemut-winxpsp3-vcpus1none executed queued test-amd64-i386-rhel6hvm-intelnone executed queued test-amd64-amd64-xl-sedfnone executed queued test-amd64-i386-xend-winxpsp3none executed queued test-amd64-amd64-xl-winxpsp3none executed queued test-amd64-i386-libvirt none executed queued build-armhf-libvirt 5 libvirt-build fail REGR. vs. 32282 test-amd64-amd64-pair none executed queued test-amd64-i386-xl-multivcpunone executed queued build-amd64-rumpuserxen none executed queued test-amd64-amd64-rumpuserxen-amd64none executed queued test-amd64-i386-freebsd10-i386none executed queued build-i386-libvirt none executed queued test-amd64-amd64-xl none executed queued test-amd64-i386-xl-qemut-win7-amd64none executed queued test-amd64-amd64-libvirtnone executed queued test-amd64-amd64-xl-qemuu-win7-amd64none executed queued test-armhf-armhf-xl none executed queued test-amd64-i386-xend-qemut-winxpsp3none executed queued test-amd64-i386-xl-qemuu-win7-amd64none executed queued test-amd64-amd64-xl-win7-amd64none executed queued test-amd64-amd64-xl-qemut-winxpsp3none executed queued build-amd64-pvops 2 hosts-allocate running [st=running!] test-amd64-amd64-xl-qemut-debianhvm-amd64none executedqueued test-amd64-i386-xl-credit2 none executed queued test-amd64-i386-xl-qemut-debianhvm-amd64none executed queued test-amd64-amd64-xl-qemut-win7-amd64none executed queued test-amd64-i386-qemuu-rhel6hvm-amdnone executed queued build-i3862 hosts-allocate running [st=running!] test-amd64-i386-xl-qemuu-debianhvm-amd64none executed queued build-i386-rumpuserxen none executed queued build-amd64 2 hosts-allocate running [st=running!] test-amd64-amd64-xl-sedf-pinnone executed queued test-amd64-i386-xl none executed queued build-i386-pvops 2 hosts-allocate running [st=running!] version targeted for testing: xen 5d4e3ff19c33770ce01bec949c50326b11088fef baseline version: xen 5cd7ed02530eb86ffee6f5b9c7f04743c726754f People who touched revisions under test: Mihai DonÈu mdo...@bitdefender.com RÄzvan Cojocaru rcojoc...@bitdefender.com jobs: build-amd64 preparing build-armhf pass build-i386 preparing build-amd64-libvirt queued build-armhf-libvirt fail build-i386-libvirt
Re: [Xen-devel] [PATCH v2 2/5] vTPM: limit libxl__add_vtpms() function to para virtual machine
-Original Message-
From: Wei Liu [mailto:wei.l...@citrix.com]
Sent: Tuesday, January 06, 2015 5:45 PM
To: Xu, Quan
Cc: Wei Liu; xen-devel@lists.xen.org; ian.jack...@eu.citrix.com;
stefano.stabell...@eu.citrix.com; ian.campb...@citrix.com
Subject: Re: [PATCH v2 2/5] vTPM: limit libxl__add_vtpms() function to para
virtual machine
On Tue, Jan 06, 2015 at 02:17:36AM +, Xu, Quan wrote:
-Original Message-
From: Wei Liu [mailto:wei.l...@citrix.com]
Sent: Monday, January 05, 2015 8:53 PM
To: Xu, Quan
Cc: xen-devel@lists.xen.org; ian.jack...@eu.citrix.com;
stefano.stabell...@eu.citrix.com; ian.campb...@citrix.com;
wei.l...@citrix.com
Subject: Re: [PATCH v2 2/5] vTPM: limit libxl__add_vtpms() function
to para virtual machine
On Tue, Dec 30, 2014 at 11:45:02PM -0500, Quan Xu wrote:
Signed-off-by: Quan Xu quan...@intel.com
---
tools/libxl/libxl_create.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/tools/libxl/libxl_create.c
b/tools/libxl/libxl_create.c index b1ff5ae..0a09925 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -1358,8 +1358,9 @@ static void
domcreate_attach_vtpms(libxl__egc
*egc,
goto error_out;
}
-/* Plug vtpm devices */
- if (d_config-num_vtpms 0) {
+ /* Plug vtpm devices for para virtual domain*/
+ if (d_config-num_vtpms 0
+ d_config-b_info.type == LIBXL_DOMAIN_TYPE_PV) {
It's unclear to me why you stub out HVM domain. You need to state
your reasoning in comment and commit log. :-/
In brief, it is different to plug vtpm device for HVM/PV domain. I will try
to
describe more detailed in next v3. Thanks Wei.
I got that idea when I read your later patch. But stubbing out PV here is
wrong. Essentially this patch introduces a functional regression by itself
because now you can't add vtpms for PV. I doubt that you will still need this
patch in your next round. See my reply to patch 4/5.
Okay, I will reply with that email directly..
Quan
Wei.
Thanks
Quan Xu
Wei.
/* Attach vtpms */
libxl__multidev_begin(ao, dcs-multidev);
dcs-multidev.callback = domcreate_attach_pci;
--
1.8.3.2
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [xen-4.2-testing test] 33180: trouble: preparing/queued
flight 33180 xen-4.2-testing running [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/33180/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-rhel6hvm-amdnone executed queued build-amd64-libvirt none executed queued test-amd64-amd64-xl-qemuu-ovmf-amd64none executed queued test-amd64-amd64-pv none executed queued test-amd64-i386-pairnone executed queued test-amd64-i386-xl-winxpsp3-vcpus1none executed queued test-amd64-i386-qemuu-rhel6hvm-intelnone executed queued test-i386-i386-xl-winxpsp3 none executed queued test-i386-i386-libvirt none executed queued test-amd64-i386-xl-win7-amd64none executed queued test-amd64-i386-qemut-rhel6hvm-intelnone executed queued test-amd64-i386-xl-qemuu-ovmf-amd64none executed queued test-amd64-i386-pv none executed queued test-amd64-i386-qemuu-freebsd10-i386none executed queued test-amd64-amd64-xl-qemuu-winxpsp3none executed queued test-amd64-i386-qemut-rhel6hvm-amdnone executed queued test-i386-i386-xl none executed queued test-amd64-amd64-xl-pcipt-intelnone executed queued test-amd64-i386-xl-qemuu-winxpsp3-vcpus1none executed queued test-amd64-i386-rumpuserxen-i386none executed queued test-amd64-amd64-xl-qemuu-debianhvm-amd64none executedqueued test-i386-i386-pair none executed queued test-i386-i386-pv none executed queued test-amd64-i386-xl-qemut-winxpsp3-vcpus1none executed queued test-amd64-i386-rhel6hvm-intelnone executed queued test-i386-i386-rumpuserxen-i386none executed queued test-i386-i386-xl-qemuu-winxpsp3none executed queued test-amd64-amd64-xl-sedfnone executed queued test-amd64-i386-xend-winxpsp3none executed queued test-amd64-amd64-xl-winxpsp3none executed queued test-amd64-i386-libvirt none executed queued test-amd64-amd64-pair none executed queued test-amd64-i386-xl-multivcpunone executed queued build-amd64-rumpuserxen none executed queued test-amd64-amd64-rumpuserxen-amd64none executed queued test-i386-i386-xl-qemut-winxpsp3none executed queued build-i386-libvirt none executed queued test-amd64-amd64-xl none executed queued test-amd64-i386-xl-qemut-win7-amd64none executed queued test-amd64-amd64-libvirtnone executed queued test-amd64-amd64-xl-qemuu-win7-amd64none executed queued test-amd64-i386-xend-qemut-winxpsp3none executed queued test-amd64-i386-xl-qemuu-win7-amd64none executed queued test-amd64-amd64-xl-win7-amd64none executed queued test-amd64-amd64-xl-qemut-winxpsp3none executed queued build-amd64-pvops 2 hosts-allocate running [st=running!] test-amd64-amd64-xl-qemut-debianhvm-amd64none executedqueued test-amd64-i386-xl-credit2 none executed queued test-amd64-i386-qemuu-freebsd10-amd64none executed queued test-amd64-i386-xl-qemut-debianhvm-amd64none executed queued test-amd64-amd64-xl-qemut-win7-amd64none executed queued test-amd64-i386-qemuu-rhel6hvm-amdnone executed queued build-i3862 hosts-allocate running [st=running!] test-amd64-i386-xl-qemuu-debianhvm-amd64none executed queued build-amd64 2 hosts-allocate running [st=running!] build-i386-rumpuserxen none executed queued test-amd64-amd64-xl-sedf-pinnone executed queued test-amd64-i386-xl none executed queued build-i386-pvops 2 hosts-allocate running [st=running!] version targeted for testing: xen 95af3f09eeef089e0100a8518f7ca75206e33c7c baseline version: xen 353de6b221c2d0fb59edfceb1f535357e4d84825 People who touched revisions under test: Mihai DonÈu mdo...@bitdefender.com RÄzvan Cojocaru rcojoc...@bitdefender.com jobs: build-amd64 preparing build-i386
[Xen-devel] [OSSTEST PATCH] README.dev: Document how to do a force push.
Signed-off-by: Ian Campbell ian.campb...@citrix.com --- README.dev | 9 + 1 file changed, 9 insertions(+) diff --git a/README.dev b/README.dev index eb72659..1257649 100644 --- a/README.dev +++ b/README.dev @@ -123,3 +123,12 @@ initial push works When pushing the patches, be sure to make sure that the for-$branch.git repo can fast forward to the pushed version (perhaps by resetting it). + +Force pushing a branch +== + +As osstest user on test controller +$ cd ~/branches/for-$branch.git +$ OSSTEST_CONFIG=production-config ./ap-push $branch $revision + +NOTE: $revision must be a revision *not* a tag. -- 2.1.1 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] smmu/ccp warnings on Seattle
While Xen was booting on Seattle, I got warnings/errors related to smmu and ccp. Eventually Seattle was rebooted. These are the relevant logs (and more warnings in a full log at the bottom). (XEN) smmu: /smb/motherboard/smmu@00C0: Try to add master ccp (XEN) smmu: /smb/motherboard/smmu@00C0: duplicate stream ID (11) (XEN) smmu: /smb/motherboard/smmu@00C0: failed to add master ccp ... ... (XEN) arm-smmu: attach /smb/motherboard/ccp@0010 to domain 0 (XEN) /smb/motherboard/ccp@0010: cannot attach to SMMU, is it on the same bus? (XEN) Failed to setup the IOMMU for /smb/motherboard/ccp@0010 (XEN) Device tree generation failed (-19). Even after removing smmu/ccp nodes from the DT, I got an unexpected hypervisor trap on cpu0, and Seattle was rebooted again. Here's the full log WITH smmu/ccp. Shell FS0:\xen\xenImg.gz Xen 4.5.0-rc (c/s Mon Dec 15 09:30:05 2014 +0100 git:2676bc9) EFI loader Using configuration file 'xenImg.cfg' v318: 0x0083fbd93000-0x0083fc4eada0 Xen 4.5.0-rc (XEN) Xen version 4.5.0-rc (soccertack@) (aarch64-linux-gnu-gcc (crosstool-NG linaro-1.13.1-4.9-2014.09 - Linaro GC C 4.9-2014.09) 4.9.2 20140904 (prerelease)) debug=y Wed Dec 17 11:50:57 EST 2014 (XEN) Latest ChangeSet: Mon Dec 15 09:30:05 2014 +0100 git:2676bc9 (XEN) Processor: 410fd070: ARM Limited, variant: 0x0, part 0xd07, rev 0x0 (XEN) 64-bit Execution: (XEN) Processor Features: (XEN) Exception Levels: EL3:64+32 EL2:64+32 EL1:64+32 EL0:64+32 (XEN) Extensions: FloatingPoint AdvancedSIMD (XEN) Debug Features: 10305106 (XEN) Auxiliary Features: (XEN) Memory Model Features: 1124 (XEN) ISA Features: 00011120 (XEN) 32-bit Execution: (XEN) Processor Features: 0131:00011011 (XEN) Instruction Sets: AArch32 A32 Thumb Thumb-2 Jazelle (XEN) Extensions: GenericTimer Security (XEN) Debug Features: 03010066 (XEN) Auxiliary Features: (XEN) Memory Model Features: 10101105 4000 0126 02102211 (XEN) ISA Features: 02101110 13112111 21232042 01112131 00011142 00011121 (XEN) Platform: SEATTLE (XEN) Using PSCI-0.1 for SMP bringup (XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27 (XEN) Using generic timer at 187500 KHz (XEN) GICv2 initialization: (XEN) gic_dist_addr=e111 (XEN) gic_cpu_addr=e112f000 (XEN) gic_hyp_addr=e114 (XEN) gic_vcpu_addr=e116 (XEN) gic_maintenance_irq=24 (XEN) GICv2: 448 lines, 8 cpus, secure (IID 0200143b). (XEN) Using scheduler: SMP Credit Scheduler (credit) (XEN) Xen WARN at device_tree.c:1191 (XEN) [ Xen-4.5.0-rc arm64 debug=y Not tainted ] (XEN) CPU:0 (XEN) PC: 002038dc __dt_parse_phandle_with_args+0x160/0x220 (XEN) LR: 00203858 (XEN) SP: 002b7c40 (XEN) CPSR: 2249 MODE:64-bit EL2h (Hypervisor, handler) (XEN) X0: 0020 X1: 0001 X2: 0004 (XEN) X3: X4: 0080 X5: 6c61626f6c672300 (XEN) X6: 8023676c6f62616c X7: 6b60616e6b6621ff X8: 7f7f7f7f7f7f7f7f (XEN) X9: fffb X10: 0101010101010101 X11: (XEN) X12: 0018 X13: X14: 00219438 (XEN) X15: X16: 00289298 X17: (XEN) X18: X19: 0004 X20: (XEN) X21: 8003d384 X22: 8003d404 X23: 8003fff82ba0 (XEN) X24: X25: 0001 X26: (XEN) X27: 00270940 X28: 002b7d40 FP: 002b7c40 (XEN) (XEN) VTCR_EL2: 8000 (XEN) VTTBR_EL2: (XEN) (XEN) SCTLR_EL2: 30cd183d (XEN)HCR_EL2: 0038643f (XEN) TTBR0_EL2: 008027ef4000 (XEN) (XEN)ESR_EL2: f201 (XEN) HPFAR_EL2: (XEN)FAR_EL2: (XEN) (XEN) Xen stack trace from sp=002b7c40: (XEN)002b7cc0 00204c88 8003fbd90660 0002 (XEN)0002 0001 00270440 0004 (XEN) 00270940 00270440 0027 (XEN)8003fff82d78 0100 002b7cd0 00840020 (XEN)002b7cd0 00280f84 002b7da0 00286204 (XEN)00278a30 0001 00278a90 8003fff82d78 (XEN) 0004 002a0108 00800100 (XEN)0084 000d 00278a90 00270958 (XEN)002b7d50 00203aa8 002b7d80 00286154 (XEN)00290050 8003fff82d78 002b7da0 000c002861b4 (XEN)002b7da0 002861e4 0001 e040 (XEN)002b7de0 0028093c 8003fff82d78
Re: [Xen-devel] [PATCH for-4.5] reset PCI devices on force removal even when QEMU returns error
Tuesday, January 6, 2015, 12:45:17 PM, you wrote: On Wed, 2014-12-17 at 16:07 -0500, Konrad Rzeszutek Wilk wrote: On Mon, Dec 15, 2014 at 11:13:06AM +, Stefano Stabellini wrote: On Fri, 12 Dec 2014, Konrad Rzeszutek Wilk wrote: On Fri, Dec 12, 2014 at 04:13:52PM +0100, Sander Eikelenboom wrote: Hi Konrad, This doesn't seem to be applied yet, nor does it seem to have a release-(N)ACK from you ? Hm, Stefano: - Is this a regression? I don't think so. Probably a regression compared to the xend toolstack though. OK, so that is Xen 4.4 - Xen 4.5 regression then. Release-Acked-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com An updated version with the logging which I had indicated I would prefer doesn't appear to be forthcoming so I've just applied this one. I wasn't aware of that, thx for applying ! -- Sander ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [linux-3.10 test] 33150: regressions - trouble: blocked/fail/pass/preparing/queued
flight 33150 linux-3.10 running [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/33150/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-pvh-intelnone executed queued test-amd64-amd64-rumpuserxen-amd64none executed queued test-amd64-i386-rumpuserxen-i386none executed queued build-armhf-libvirt 5 libvirt-build fail REGR. vs. 26303 test-amd64-i386-libvirt none executed queued test-amd64-amd64-libvirtnone executed queued test-amd64-amd64-xl-pcipt-intelnone executed queued test-amd64-amd64-xl-pvh-amd none executed queued build-i386-libvirt2 hosts-allocate running [st=running!] test-amd64-amd64-xl none executed queued test-amd64-i386-rhel6hvm-amdnone executed queued test-amd64-i386-qemuu-rhel6hvm-amdnone executed queued test-amd64-i386-qemut-rhel6hvm-amdnone executed queued test-amd64-i386-qemut-rhel6hvm-intelnone executed queued test-amd64-amd64-xl-sedf-pinnone executed queued test-amd64-i386-xl-credit2 none executed queued test-amd64-i386-rhel6hvm-intelnone executed queued test-amd64-i386-xl none executed queued test-amd64-i386-qemuu-rhel6hvm-intelnone executed queued test-amd64-amd64-xl-sedfnone executed queued test-amd64-i386-xl-qemut-win7-amd64none executed queued test-amd64-i386-freebsd10-i386none executed queued test-amd64-i386-freebsd10-amd64none executed queued build-amd64-libvirt none executed queued test-amd64-amd64-xl-qemuu-winxpsp3none executed queued build-amd64-rumpuserxen none executed queued test-amd64-i386-xl-winxpsp3-vcpus1none executed queued build-amd64-pvops 2 hosts-allocate running [st=running!] test-amd64-i386-xl-qemut-debianhvm-amd64none executed queued test-amd64-i386-xl-multivcpunone executed queued build-amd64 2 hosts-allocate running [st=running!] test-amd64-i386-xl-qemuu-debianhvm-amd64none executed queued test-amd64-i386-xl-qemuu-win7-amd64none executed queued test-amd64-amd64-pair none executed queued test-amd64-i386-xl-winxpsp3 none executed queued test-amd64-amd64-xl-win7-amd64none executed queued test-amd64-amd64-xl-qemut-win7-amd64none executed queued test-amd64-amd64-xl-qemuu-win7-amd64none executed queued test-amd64-i386-xl-qemut-winxpsp3none executed queued test-amd64-i386-xl-qemuu-ovmf-amd64none executed queued test-amd64-amd64-xl-qemut-debianhvm-amd64none executedqueued test-amd64-amd64-xl-qemuu-debianhvm-amd64none executedqueued test-amd64-amd64-xl-qemuu-ovmf-amd64none executed queued test-amd64-i386-xl-qemut-winxpsp3-vcpus1none executed queued test-amd64-i386-xl-qemuu-winxpsp3-vcpus1none executed queued test-amd64-i386-pairnone executed queued test-amd64-i386-xl-win7-amd64none executed queued test-amd64-amd64-xl-winxpsp3none executed queued test-amd64-amd64-xl-qemut-winxpsp3none executed queued test-amd64-i386-xl-qemuu-winxpsp3none executed queued Tests which did not succeed, but are not blocking: test-armhf-armhf-xl 5 xen-boot fail never pass test-armhf-armhf-libvirt 1 build-check(1) blocked n/a version targeted for testing: linuxa472efc75989c7092187fe00f0400e02c495c436 baseline version: linuxbe67db109090b17b56eb8eb2190cd70700f107aa 816 people touched revisions under test, not listing them all jobs: build-amd64 preparing build-armhf pass build-i386 pass build-amd64-libvirt queued build-armhf-libvirt fail build-i386-libvirt preparing build-amd64-pvopspreparing build-armhf-pvopspass build-i386-pvops
Re: [Xen-devel] Xen 4.5 Development Update (GA slip by a week)
(CC list replaced by just the list.) konrad.w...@oracle.com writes (Xen 4.5 Development Update (GA slip by a week)): WE ARE HERE === Release Date: Jan 14th. There are two remaining dates left unspecified in your mail: * When do we branch for 4.5 ? I think we should do this right away so that we can set up osstest to have a working push gate for 4.5 by the time of the release. This will work best with coordination with all committers to avoid stuff appearing on staging after staging-4.5 is created. The implication of branching of course is that 4.6-unstable becomes open for business. * What is the last commit deadline for 4.5 ? We need time to wait for a test push, discover a possible problem, and perhaps revert. A week would be best, but maybe a bit less would be OK. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 2/4] sysctl: Make XEN_SYSCTL_topologyinfo sysctl a little more efficient
On 01/06/2015 08:41 AM, Andrew Cooper wrote:
On 06/01/15 02:18, Boris Ostrovsky wrote:
Instead of copying data for each field in xen_sysctl_topologyinfo separately
put cpu/socket/node into a single structure and do a single copy for each
processor.
There is also no need to copy whole op to user at the end, max_cpu_index is
sufficient
Rename xen_sysctl_topologyinfo and XEN_SYSCTL_topologyinfo to reflect the fact
that these are used for CPU topology. Subsequent patch will add support for
PCI topology sysctl.
Signed-off-by: Boris Ostrovsky boris.ostrov...@oracle.com
If we are going to change the hypercall, then can we see about making it
a stable interface (i.e. not a sysctl/domctl)? There are non-toolstack
components which might want/need access to this information. (i.e. I am
still looking for a reasonable way to get this information from Xen in
hwloc)
Can't those components dlopen libxl? That's what I was assuming we'd do
with hwlock.
snip
+if ( cpu_online(i) )
{
-uint32_t socket = cpu_online(i) ? cpu_to_socket(i) : ~0u;
-if ( copy_to_guest_offset(ti-cpu_to_socket, i, socket, 1) )
-break;
+cputopo.core = cpu_to_core(i);
+cputopo.socket = cpu_to_socket(i);
+cputopo.node = cpu_to_node(i);
}
-if ( !guest_handle_is_null(ti-cpu_to_node) )
+else
+cputopo.core = cputopo.socket =
+cputopo.node = INVALID_TOPOLOGY_ID;
+
In particular, can we fix this broken behaviour. The cpu being online
or not has no bearing on whether Xen has topology information, and a
side effect is that when the cpu governer powers down a cpu, it
disappears from the reported topology.
Yes, I should fix that as well.
-boris
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/7] tools/hotplug: remove SELinux options from var-lib-xenstored.mount
Olaf Hering writes ([PATCH 1/7] tools/hotplug: remove SELinux options from var-lib-xenstored.mount): Using SELinux mount options per default breaks several systems. Either the context= mount option is not known at all to the kernel, as reported for ArchLinux. Or the default value none is unknown to SELinux, as reported for Fedora. In both cases the unit will fail. ... Signed-off-by: Olaf Hering o...@aepfle.de Acked-by: Ian Jackson ian.jack...@eu.citrix.com When applied along with the README change provided by Konrad. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 7/7] tools/hotplug: add wrapper to start xenstored
Olaf Hering writes ([PATCH 7/7] tools/hotplug: add wrapper to start
xenstored):
The shell wrapper in xenstored.service does not handle XENSTORE_TRACE.
...
+XENSTORED_LIBEXEC = xenstored.sh
Should be in /etc as previously discussed. Previously I wrote:
Bottom line: as relevant maintainer, I'm afraid I'm going to insist
that this script be in /etc.
I'm disappointed. It is not acceptable to resubmit a change ignoring
such unequivocal feedback.
Nacked-by: Ian Jackson ian.jack...@eu.citrix.com
+hotplug/Linux/xenstored.sh
Although many of the existing hotplug scripts have this notion of
calling things foo.sh because they happen to be written in shell, I
think this is bad practice.
I would prefer xenstored-wrap or some such. (My co-maintainers may
disagree...) But this is a bit of a bikeshed issue.
echo -n Starting $XENSTORED...
- $XENSTORED --pid-file /var/run/xenstored.pid $XENSTORED_ARGS
+ XENSTORED=$XENSTORED \
+ XENSTORED_TRACE=$XENSTORED_TRACE \
+ XENSTORED_ARGS=$XENSTORED_ARGS \
+ ${LIBEXEC_BIN}/xenstored.sh --pid-file
/var/run/xenstored.pid
It might be easier to . xenstore-wrap. Failing that using `export'
will avoid this rather odd and repetitive style.
diff --git a/tools/hotplug/Linux/xenstored.sh.in
b/tools/hotplug/Linux/xenstored.sh.in
new file mode 100644
index 000..dc806ee
--- /dev/null
+++ b/tools/hotplug/Linux/xenstored.sh.in
@@ -0,0 +1,6 @@
+#!/bin/sh
+if test -n $XENSTORED_TRACE
+then
+ XENSTORED_ARGS= -T /var/log/xen/xenstored-trace.log
+fi
+exec $XENSTORED $@ $XENSTORED_ARGS
This should probably have around $@ just in case.
Thanks,
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 0/7 v3] tools/hotplug: systemd changes for 4.5
Konrad Rzeszutek Wilk writes (Re: [Xen-devel] [PATCH 0/7 v3] tools/hotplug: systemd changes for 4.5): #4 (tools/hotplug: use xencommons as EnvironmentFile in xenconsoled.service) #5 (tools/hotplug: use XENCONSOLED_TRACE in xenconsoled.service) #6 (tools/hotplug: remove EnvironmentFile from xen-qemu-dom0-disk-backend.service) need Acks. Done. For patch #1 (tools/hotplug: remove SELinux options from var-lib-xenstored.mount) Release-Acked-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com Tested-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com with the below change to README file. It also needs an Ack. Done. For patch #7 ( tools/hotplug: add wrapper to start xenstored) Tested-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com However there is a question in there for Ian: The place of the wrapper is currently LIBEXEC_BIN, it has to be decided what the final location is supposed to be. IanJ wants it in /etc. IanJ - any specific reasons for having it in /etc instead of LIBEXEC_BIN? This is in regards to the introduction of this file: I explained this in my previous response and made what I thought was an unequivocal declaration about the location of the file. Such as this might be good (Or perhaps move it to the INSTALL file) ... --- a/README +++ b/README ... +Release Issues +== I'm happy to have this particular issue here in the README. But I think the release notes need to be out of tree. This is so that if we discover an issue between last commit deadline and release, we can update the release notes. Thanks, Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Xen 4.5 Development Update (GA slip by a week)
Hi all (and a Happy New Year), besides the actual release and the remaining code issues there are a few other items that typically need to be done. I am listing these below. Some have owners, others don't. If you are on the CC list, please have a look at the unowned pages and see whether you can help. Once all the outstanding changes have made it into master, please let me know such that I can re-run the stats. If not, people may not be credited for their contribution. = (Owned) Documentation - needs checking = * Lars: http://wiki.xenproject.org/wiki/Xen_Project_4.5_Feature_List ** it is possible that a feature you developed was missed or wrongly described. Feel free to add to the page or update it. * Lars: http://wiki.xenproject.org/wiki/Xen_Project_Release_Features ** The Host Limits need to be checked. I believe the limits for ARM increased. Not sure about x98 = (Unowned) Documentation = These will need to be checked by someone who knows the relevant functionality. Please reply to this section. * http://wiki.xenproject.org/wiki/Linux_PVH - not sure whether this page correct. Someone in the know please have a look and ACK or point out issues * http://wiki.xenproject.org/wiki/Xen_Project_4.5_Release_Notes - I can populate some of it. Will need help for the known issues section though * http://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions/OdroidXU - missing = (Owned) Documentation = * Lars: http://wiki.xenproject.org/wiki/Xen_Project_4.5_Acknowledgements - will populate after I ran the stats script after the last commit * Lars: http://wiki.xenproject.org/wiki/Xen_Project_4.5_Man_Pages - done, but links are broken until the branch is made = (Owned) Making the Release = Typically done by Ian Jackson and me. See http://wiki.xenproject.org/wiki/Checklist/XenHypervisorRelease = (Owned) Press release / Blog post = Done by Sarah Conway and me Status: have a draft press release and blog post (see http://lists.xenproject.org/archives/html/publicity/2015-01/msg1.html) - feel free to check your feature description Open Issue: Konrad to check whether he is allowed to publish the blog post under his name. If not we can create a Release Manager account to publish it under. Cheers Lars On 5 Jan 2015, at 20:08, konrad.w...@oracle.com wrote: Xen 4.5-rc4 was out on Monday (Dec 15th). The GA General Release is on Jan 7th^H^H^14th! There are some outstanding patches on which we need to figure out whether we will commit them in or not. When we commit a patch in, the OSSTest takes a day or so to push it to 'master' - and if it fails during that time patches that are later in the sequence are not applied. Hence if everything works out great - we get the patches to show up next day - however if something breaks - we are stalled. Ian(s) has pointed to me that the OSSTest is sometimes on the fritz and that it might take more than one day to push patches through which means we won't make it by Wednesday. As such, moving it the release by a week to give us ample room to get through those changes. These are the patches that need to be investigated whether they should go in or not: VT-d: don't crash when PTE bits 52 and up are non-zero VT-d: extend XSA-59 workaround to XeonE5 v3 (Haswell) VT-d: make XSA-59 workaround fully cover XeonE5/E7 v2 x86/VPMU: Clear last_vcpu when destroying VPMU tools/hotplug: add wrapper to start xenstored tools/hotplug: remove EnvironmentFile from xen-qemu-dom0-disk-backend.service tools/hotplug: use XENCONSOLED_TRACE in xenconsoled.service tools/hotplug: use xencommons as EnvironmentFile in xenconsoled.service tools/hotplug: xendomains.service depends on network tools/hotplug: remove XENSTORED_ROOTDIR from xenstored.service tools/hotplug: remove SELinux options from var-lib-xenstored.mount tools/libxl: Use of init()/dispose() to avoid leaking libxl_dominfo.ss xen: arm: correct off-by-one error in consider_module = Timeline = Xen 4.5 is a 10 month release. The dates are: * Feature Freeze: 24th September 2014 * First RC: 24th October [Friday!] * RC2: Nov 11th * RC2 Test-day: Nov 13th * RC3: Dec 3rd. * RC3 Test-day: Dec 4th * RC4: Dec 15th * RC4 Test-day: Dec 17th WE ARE HERE === Release Date: Jan 14th. ___ 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] Xen 4.5 Development Update (GA slip by a week)
On Tue, Jan 06, 2015 at 02:40:31PM +, Ian Jackson wrote: (CC list replaced by just the list.) konrad.w...@oracle.com writes (Xen 4.5 Development Update (GA slip by a week)): WE ARE HERE === Release Date: Jan 14th. There are two remaining dates left unspecified in your mail: * When do we branch for 4.5 ? I think we should do this right away so that we can set up osstest to have a working push gate for 4.5 by the time of the release. I concur. Would you be OK doing that? This will work best with coordination with all committers to avoid stuff appearing on staging after staging-4.5 is created. Um, not following you. I think we want people to put patches in staging, just not 4.5 material? The implication of branching of course is that 4.6-unstable becomes open for business. Right. * What is the last commit deadline for 4.5 ? We need time to wait for a test push, discover a possible problem, and perhaps revert. A week would be best, but maybe a bit less How long do those 'test push' take? would be OK. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 0/7 v3] tools/hotplug: systemd changes for 4.5
On Tue, Jan 06, 2015 at 03:00:16PM +, Ian Jackson wrote: Konrad Rzeszutek Wilk writes (Re: [Xen-devel] [PATCH 0/7 v3] tools/hotplug: systemd changes for 4.5): #4 (tools/hotplug: use xencommons as EnvironmentFile in xenconsoled.service) #5 (tools/hotplug: use XENCONSOLED_TRACE in xenconsoled.service) #6 (tools/hotplug: remove EnvironmentFile from xen-qemu-dom0-disk-backend.service) need Acks. Done. Thank you. Let me apply #1-#6 in staging then. For patch #1 (tools/hotplug: remove SELinux options from var-lib-xenstored.mount) Release-Acked-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com Tested-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com with the below change to README file. It also needs an Ack. Done. For patch #7 ( tools/hotplug: add wrapper to start xenstored) Tested-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com However there is a question in there for Ian: The place of the wrapper is currently LIBEXEC_BIN, it has to be decided what the final location is supposed to be. IanJ wants it in /etc. IanJ - any specific reasons for having it in /etc instead of LIBEXEC_BIN? This is in regards to the introduction of this file: I explained this in my previous response and made what I thought was an unequivocal declaration about the location of the file. Such as this might be good (Or perhaps move it to the INSTALL file) ... --- a/README +++ b/README ... +Release Issues +== I'm happy to have this particular issue here in the README. But I think the release notes need to be out of tree. This is so that if we discover an issue between last commit deadline and release, we can update the release notes. nods Will create one on the Wiki and add it there. Thanks, Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] libxl: Fix building libxlu_cfg_y.y with bison 3.0
Konrad Rzeszutek Wilk writes (Re: [Xen-devel] [PATCH] libxl: Fix building libxlu_cfg_y.y with bison 3.0): On Wed, Dec 10, 2014 at 04:44:00PM +, Ian Campbell wrote: On Wed, 2014-12-10 at 11:41 -0500, Konrad Rzeszutek Wilk wrote: On Tue, Dec 09, 2014 at 03:25:29PM +, Ian Jackson wrote: I think for 4.5 we should: * Regenerate the flex files with current wheezy's flex. (I have reviewed the diff in the generated code. It produces trivial changes which add declarations of xlu__cfg_yyget_column and xlu__cfg_yyset_column, but no code body changes - see below.) * Take the patch from Ed and regenerate the bison files too. Konrad: can we have two freeze exceptions please ? ... Based on that reasoning (And thank you for pointing out the developers factors), I retract my earlier reason and: Release-Acked-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com Thanks. I have now pushed these two. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 6/7] tools/hotplug: remove EnvironmentFile from xen-qemu-dom0-disk-backend.service
Olaf Hering writes ([PATCH 6/7] tools/hotplug: remove EnvironmentFile from xen-qemu-dom0-disk-backend.service): The references Environment file does not exist, and the service file does not make use of variables anyway. Acked-by: Ian Jackson ian.jack...@eu.citrix.com Although of course this will have to come back in a slightly different form if we ever start honouring env settings for any reason. Thanks, Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Xen 4.5 Development Update (GA slip by a week)
On Tue, Jan 06, 2015 at 03:11:21PM +, Lars Kurth wrote: Hi all (and a Happy New Year), besides the actual release and the remaining code issues there are a few other items that typically need to be done. I am listing these below. Some have owners, others don't. If you are on the CC list, please have a look at the unowned pages and see whether you can help. Once all the outstanding changes have made it into master, please let me know such that I can re-run the stats. If not, people may not be credited for their contribution. = (Owned) Documentation - needs checking = * Lars: http://wiki.xenproject.org/wiki/Xen_Project_4.5_Feature_List ** it is possible that a feature you developed was missed or wrongly described. Feel free to add to the page or update it. * Lars: http://wiki.xenproject.org/wiki/Xen_Project_Release_Features ** The Host Limits need to be checked. I believe the limits for ARM increased. Not sure about x98 = (Unowned) Documentation = These will need to be checked by someone who knows the relevant functionality. Please reply to this section. * http://wiki.xenproject.org/wiki/Linux_PVH - not sure whether this page correct. Someone in the know please have a look and ACK or point out issues * http://wiki.xenproject.org/wiki/Xen_Project_4.5_Release_Notes - I can populate some of it. Will need help for the known issues section though * http://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions/OdroidXU - missing = (Owned) Documentation = * Lars: http://wiki.xenproject.org/wiki/Xen_Project_4.5_Acknowledgements - will populate after I ran the stats script after the last commit * Lars: http://wiki.xenproject.org/wiki/Xen_Project_4.5_Man_Pages - done, but links are broken until the branch is made = (Owned) Making the Release = Typically done by Ian Jackson and me. See http://wiki.xenproject.org/wiki/Checklist/XenHypervisorRelease = (Owned) Press release / Blog post = Done by Sarah Conway and me Status: have a draft press release and blog post (see http://lists.xenproject.org/archives/html/publicity/2015-01/msg1.html) - feel free to check your feature description Open Issue: Konrad to check whether he is allowed to publish the blog post under his name. If not we can create a Release Manager account to publish it under. No problem with me doing the blogs. Cheers Lars On 5 Jan 2015, at 20:08, konrad.w...@oracle.com wrote: Xen 4.5-rc4 was out on Monday (Dec 15th). The GA General Release is on Jan 7th^H^H^14th! There are some outstanding patches on which we need to figure out whether we will commit them in or not. When we commit a patch in, the OSSTest takes a day or so to push it to 'master' - and if it fails during that time patches that are later in the sequence are not applied. Hence if everything works out great - we get the patches to show up next day - however if something breaks - we are stalled. Ian(s) has pointed to me that the OSSTest is sometimes on the fritz and that it might take more than one day to push patches through which means we won't make it by Wednesday. As such, moving it the release by a week to give us ample room to get through those changes. These are the patches that need to be investigated whether they should go in or not: VT-d: don't crash when PTE bits 52 and up are non-zero VT-d: extend XSA-59 workaround to XeonE5 v3 (Haswell) VT-d: make XSA-59 workaround fully cover XeonE5/E7 v2 x86/VPMU: Clear last_vcpu when destroying VPMU tools/hotplug: add wrapper to start xenstored tools/hotplug: remove EnvironmentFile from xen-qemu-dom0-disk-backend.service tools/hotplug: use XENCONSOLED_TRACE in xenconsoled.service tools/hotplug: use xencommons as EnvironmentFile in xenconsoled.service tools/hotplug: xendomains.service depends on network tools/hotplug: remove XENSTORED_ROOTDIR from xenstored.service tools/hotplug: remove SELinux options from var-lib-xenstored.mount tools/libxl: Use of init()/dispose() to avoid leaking libxl_dominfo.ss xen: arm: correct off-by-one error in consider_module = Timeline = Xen 4.5 is a 10 month release. The dates are: * Feature Freeze: 24th September 2014 * First RC: 24th October [Friday!] * RC2: Nov 11th * RC2 Test-day: Nov 13th * RC3: Dec 3rd. * RC3 Test-day: Dec 4th * RC4: Dec 15th * RC4 Test-day: Dec 17th WE ARE HERE === Release Date: Jan 14th. ___ 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 5/7] tools/hotplug: use XENCONSOLED_TRACE in xenconsoled.service
On Tue, Jan 06, 2015 at 11:30:38AM +, Ian Campbell wrote:
On Fri, 2014-12-19 at 12:25 +0100, Olaf Hering wrote:
Instead of inventing a new XENCONSOLED_LOG= variable reuse the
existing XENCONSOLED_TRACE= variable in xenconsoled.service.
Signed-off-by: Olaf Hering o...@aepfle.de
Cc: Ian Jackson ian.jack...@eu.citrix.com
Cc: Stefano Stabellini stefano.stabell...@eu.citrix.com
Acked-by: Ian Campbell ian.campb...@citrix.com
(should XENCONSOLED_LOG_DIR be changed for consistency?)
To XENCONSOLED_TRACE_DIR ? It could but lets leave that for
another patch.
Cc: Wei Liu wei.l...@citrix.com
---
tools/hotplug/Linux/systemd/xenconsoled.service.in | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/hotplug/Linux/systemd/xenconsoled.service.in
b/tools/hotplug/Linux/systemd/xenconsoled.service.in
index 74d0428..4788129 100644
--- a/tools/hotplug/Linux/systemd/xenconsoled.service.in
+++ b/tools/hotplug/Linux/systemd/xenconsoled.service.in
@@ -7,13 +7,13 @@ ConditionPathExists=/proc/xen/capabilities
[Service]
Type=simple
Environment=XENCONSOLED_ARGS=
-Environment=XENCONSOLED_LOG=none
+Environment=XENCONSOLED_TRACE=none
Environment=XENCONSOLED_LOG_DIR=@XEN_LOG_DIR@/console
EnvironmentFile=@CONFIG_DIR@/@CONFIG_LEAF_DIR@/xencommons
PIDFile=@XEN_RUN_DIR@/xenconsoled.pid
ExecStartPre=/bin/grep -q control_d /proc/xen/capabilities
ExecStartPre=/bin/mkdir -p ${XENCONSOLED_LOG_DIR}
-ExecStart=@sbindir@/xenconsoled --pid-file @XEN_RUN_DIR@/xenconsoled.pid
--log=${XENCONSOLED_LOG} --log-dir=${XENCONSOLED_LOG_DIR} $XENCONSOLED_ARGS
+ExecStart=@sbindir@/xenconsoled --pid-file @XEN_RUN_DIR@/xenconsoled.pid
--log=${XENCONSOLED_TRACE} --log-dir=${XENCONSOLED_LOG_DIR}
$XENCONSOLED_ARGS
[Install]
WantedBy=multi-user.target
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] Xen 4.5 Development Update (GA slip by a week)
(culling CCs) On Tue, 2015-01-06 at 15:11 +, Lars Kurth wrote: * http://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions/OdroidXU - missing The link to this from [Xen_ARM_with_Virtualization_Extensions] seems to have been added by[0] the user Suriyan, who I presume to is the same Suriyan as is now CCd. Suriyan, Do you have any content for this page? Since the Odroid's are also Exynos based perhaps it should just link to the Arndale page, which could become a more generic Exynos page? If not then we should remove the link and add to the hardware section instead. (Or perhaps we should nuke this Platform specific section and inline the links into the list of supported hardware, since having what is effectively two lists of supported hardware seems a bit pointless). Ian. [0] Does media wiki really lack a git blame analogue? It was very tedious to work this out by hand... ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] README, xen/Makefile: Update to Xen 4.5.0
On 01/06/15 14:14, Pasi Kärkkäinen wrote: On Tue, Jan 06, 2015 at 01:21:58PM -0500, Konrad Rzeszutek Wilk wrote: On Tue, Jan 06, 2015 at 06:06:23PM +, Ian Jackson wrote: Konrad Rzeszutek Wilk writes ([Xen-devel] [PATCH] README, xen/Makefile: Update to Xen 4.5.0): -The 4.3 release offers a number of improvements, including NUMA -scheduling affinity, openvswitch integration, and defaulting to -qemu-xen rather than qemu-traditional for non-stubdom guests. -(qemu-xen is kept very close to the upstream project.) We also have a -number of updates to vTPM, and improvements to XSM and Flask to allow -greater disaggregation. Additionally, 4.3 contains a basic version of -Xen for the new ARM server architecture, both 32- and 64-bit. And as -always, there are a number of performance, stability, and security +The 4.5 release offers a number of improvements: including shedding Should read +The 4.5 release offers a number of improvements, including: shedding (note two punctuation changes) and the list items should all be separated with semicolons IMO. Thank you for your update. I've incorporated feedback from all folks I hope. Would this be satisfactory? Do we want to mention things like HVM guest direct kernel boot, or HVM guests MMIO hole resize support? It is not resize support, it is configure size support. And yes it might be good to list it. -Don Slutz And I think there was optimizations to oxenstored to support up to 1000 VMs per host.. -- Pasi ___ 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 v2 1/5] vTPM: event channel bind interdomain with para/hvm virtual machine
On 01/06/2015 11:46 AM, Xu, Quan wrote: -Original Message- From: Daniel De Graaf [mailto:dgde...@tycho.nsa.gov] On 12/30/2014 11:44 PM, Quan Xu wrote:[...] diff --git a/extras/mini-os/tpmback.c b/extras/mini-os/tpmback.c [...] + domid = (domtype == T_DOMAIN_TYPE_HVM) ? 0 : tpmif-domid; Unless I'm missing something, this still assumes that the HVM device model is located in domain 0, and so it will not work if a stub domain is used for qemu. QEMU is running in Dom0 as usual, so the domid is 0. as similar to Linux PV frontend driver, this frontend driver is enabled in QEMU. This is a valid configuration of Xen and these patches do suffice to make it work. I am trying to ensure that an additional type of guest setup will also work with these patches. A useful feature of Xen is the ability to execute the QEMU device model in a domain instead of a process in dom0. When combined with driver domains for devices, this can significantly reduce both the attack surface of and amount of trust required of domain 0. Any doubt, feel free to contact. I will try my best to explain. I think your suggestions are very helpful in previous email(Oct. 31th, 2014. ' Re: FW: [PATCH 1/6] vTPM: event channel bind interdomain with para/hvm virtual machine') Maybe this is still a vague description :( This is accurate but possibly incomplete. This is my current understanding of the communications paths and support for vTPMs in Xen: Physical TPM (1.2; with new patches, may also be 2.0) | [MMIO pass-through] | vtpmmgr domain | [minios tpmback/front] - ((other domains' vTPMs)) | vTPM domain (currently always emulates a TPM v1.2) | [minios tpmback]+[Linux tpmfront]-- PV Linux domain (fully working) | \ | +--[Linux tpmfront]-- HVM Linux with optional PV drivers | \ [QEMU XenDevOps] [minios or Linux tpmfront] | | QEMU dom0 process QEMU stub-domain | | [MMIO emulation] [MMIO emulation] | | Any HVM guest Any HVM guest The series you are sending will enable QEMU to talk to tpmback directly. This is the best solution when QEMU is running inside domain 0, because it is not currently a good idea to use Linux's tpmfront driver to talk to each guest's vTPM domain. When QEMU is run inside a stub domain, there are a few more things to consider: * This stub domain will not have domain 0; the vTPM must bind to another domain ID. * It is possible to use the native TPM driver for the stub domain (which may either run Linux or mini-os) because there is no conflict with a real TPM software stack running inside domain 0 Supporting this feature requires more granularity in the TPM backend changes. The vTPM domain's backend must be able to handle: (1) guest domains which talk directly to the vTPM on their own behalf (2) QEMU processes in domain 0 (3) QEMU domains which talk directly to the vTPM on behalf of a guest Cases (1) and (3) are already handled by the existing tpmback if the proper domain ID is used. Your patch set currently breaks case (1) and (3) for HVM guests while enabling case (2). An alternate solution that does not break these cases while enabling case (2) is preferable. My thoughts on extending the xenstore interface via an example: Domain 0: runs QEMU for guest A Domain 1: vtpmmgr Domain 2: vTPM for guest A Domain 3: HVM guest A Domain 4: vTPM for guest B Domain 5: QEMU stubdom for guest B Domain 6: HVM guest B /local/domain/2/backend/vtpm/3/0/*: backend A-PV /local/domain/3/device/vtpm/0/*: frontend A-PV /local/domain/2/backend/vtpm/0/3/*: backend A-QEMU /local/domain/0/qemu-device/vtpm/3/*: frontend A-QEMU (uses XenDevOps) /local/domain/4/backend/vtpm/5/0/*: backend B-QEMU /local/domain/5/device/vtpm/0/*: frontend B-QEMU /local/domain/4/backend/vtpm/6/0/*: backend B-PV /local/domain/6/device/vtpm/0/*: frontend B-PV Connections A-PV, B-PV, and B-QEMU would be created in the same manner as the existing xl vtpm-attach command does now. If the HVM guest is not running Linux with the Xen tpmfront.ko loaded, the A-PV and B-PV devices will remain unconnected; this is fine. Connection A-QEMU has a modified frontend state path to prevent Linux from attaching its own TPM driver to the guest's TPM. This requires a few changes: libxl must support changing the frontend path; this is similar to how disk backend supports both qdisk and vbd (and others), but instead changes the path for the frontend. The minios backend also needs to change the sscanf in parse_eventstr to something like /local/domain/%u/%*[^/]/vtpm/%u/%40s. In any case, the vTPM does not need to know if the guest is PV, HVM, or PVH. BTW, professor J. Wang(Wuhan University, China) and I have enabled TPM 2.0 simulator for Linux, Maybe we will try to integrate with vtpm domain to provide TPM 2.0 vtpm function for virtual
Re: [Xen-devel] Nominations for Xen 4.5 stable tree maintainer.
On 06/01/15 16:15, Konrad Rzeszutek Wilk wrote: Hello, Per http://wiki.xenproject.org/wiki/Xen_Project_Maintenance_Releases: Each stable branch has a maintainer who is nominated/volunteers according to the Maintainer Election process described in the project governance document [http://www.xenproject.org/governance.html]. This will resulting in the MAINTAINERS file in the relevant branch being patched to include the maintainer. For the past year or so Jan Beulich has been the stable tree maintainer. Since Xen 4.5 has branched that opens up a new stable tree and we can also stop maintaining Xen 4.3 stable tree. The nominations are open - please volunteer yourself. In case nobody volunteers I can also take the role. I ask folks to finish voting/nominating by Jan 14th so that when Xen 4.5 comes out we have an viable stable tree maintainer. Thank you! I will be performing this task inside XenServer anyway. If Jan wants a break, I would be happy to volunteer. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Xen 4.5 Development Update (GA slip by a week)
On Tue, Jan 6, 2015 at 10:54 AM, Suriyan Ramasami suriya...@gmail.com wrote: On Tue, Jan 6, 2015 at 10:51 AM, Lars Kurth lars.kurth@gmail.com wrote: On 6 Jan 2015, at 18:08, Suriyan Ramasami suriya...@gmail.com wrote: I shall try my hand at updating the information again. If this needs to be done (yesterday), then as a temporary solution we could just delete this information for now, and I shall work on it soon. Ideally it needs to be done by next Wed. If you have the content, you could send it to me and I can fix the page Thanks Lars for the offer. I just started editing the page, and looks simple enough to get some content out there. I should have updated the relevant information in a few hours from now. Please do help me in fixing the page once its done (if it needs fixing) Thanks! - Suriyan Hello Lars/Ian, I have updated the wiki somewhat to an OK level of information. Lars, I think there might be other links that need to be set to point to this OdroidXU wiki? Any help in polishing this would be appreciated! Thanks - Suriyan Lars ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 01/12] mm: allow for an alternate set of pages for userspace mappings
Add an optional array of pages to struct vm_area_struct that can be
used find the page backing a VMA. This is useful in cases where the
normal mechanisms for finding the page don't work. This array is only
inspected if the PTE is special.
Splitting a VMA with such an array of pages is trivially done by
adjusting vma-pages. The original creator of the VMA must only free
the page array once all sub-VMAs are closed (e.g., by ref-counting in
vm_ops-open and vm_ops-close).
One use case is a Xen PV guest mapping foreign pages into userspace.
In a Xen PV guest, the PTEs contain MFNs so get_user_pages() (for
example) must do an MFN to PFN (M2P) lookup before it can get the
page. For foreign pages (those owned by another guest) the M2P lookup
returns the PFN as seen by the foreign guest (which would be
completely the wrong page for the local guest).
This cannot be fixed up improving the M2P lookup since one MFN may be
mapped onto two or more pages so getting the right page is impossible
given just the MFN.
Signed-off-by: David Vrabel david.vra...@citrix.com
---
include/linux/mm_types.h |8
mm/memory.c |2 ++
mm/mmap.c| 12 +++-
3 files changed, 21 insertions(+), 1 deletion(-)
diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
index 6d34aa2..4f34609 100644
--- a/include/linux/mm_types.h
+++ b/include/linux/mm_types.h
@@ -309,6 +309,14 @@ struct vm_area_struct {
#ifdef CONFIG_NUMA
struct mempolicy *vm_policy;/* NUMA policy for the VMA */
#endif
+ /*
+* Array of pages to override the default vm_normal_page()
+* result iff the PTE is special.
+*
+* The memory for this should be refcounted in vm_ops-open
+* and vm_ops-close.
+*/
+ struct page **pages;
};
struct core_thread {
diff --git a/mm/memory.c b/mm/memory.c
index ca920d1..98520f6 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -754,6 +754,8 @@ struct page *vm_normal_page(struct vm_area_struct *vma,
unsigned long addr,
if (HAVE_PTE_SPECIAL) {
if (likely(!pte_special(pte)))
goto check_pfn;
+ if (vma-pages)
+ return vma-pages[(addr - vma-vm_start) PAGE_SHIFT];
if (vma-vm_flags (VM_PFNMAP | VM_MIXEDMAP))
return NULL;
if (!is_zero_pfn(pfn))
diff --git a/mm/mmap.c b/mm/mmap.c
index 7b36aa7..504dc5c 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -2448,6 +2448,7 @@ static int __split_vma(struct mm_struct *mm, struct
vm_area_struct *vma,
unsigned long addr, int new_below)
{
struct vm_area_struct *new;
+ unsigned long delta;
int err = -ENOMEM;
if (is_vm_hugetlb_page(vma) (addr
@@ -2463,11 +2464,20 @@ static int __split_vma(struct mm_struct *mm, struct
vm_area_struct *vma,
INIT_LIST_HEAD(new-anon_vma_chain);
+ delta = (addr - vma-vm_start) PAGE_SHIFT;
+
if (new_below)
new-vm_end = addr;
else {
new-vm_start = addr;
- new-vm_pgoff += ((addr - vma-vm_start) PAGE_SHIFT);
+ new-vm_pgoff += delta;
+ }
+
+ if (vma-pages) {
+ if (new_below)
+ vma-pages += delta;
+ else
+ new-pages += delta;
}
err = vma_dup_policy(vma, new);
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 05/12] x86/xen: require ballooned pages for grant maps
From: Jenny Herbert jennifer.herb...@citrix.com
Ballooned pages are always used for grant maps which means the
original frame does not need to be saved in page-index nor restored
after the grant unmap.
This allows the workaround in netback for the conflicting use of the
(unionized) page-index and page-pfmemalloc to be removed.
Signed-off-by: Jenny Herbert jennifer.herb...@citrix.com
Signed-off-by: David Vrabel david.vra...@citrix.com
---
arch/x86/xen/p2m.c|5 +++--
drivers/net/xen-netback/netback.c |6 --
2 files changed, 3 insertions(+), 8 deletions(-)
diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index 8f34ed4..0d70814 100644
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -682,9 +682,10 @@ int set_foreign_p2m_mapping(struct gnttab_map_grant_ref
*map_ops,
pfn = page_to_pfn(pages[i]);
WARN_ON(PagePrivate(pages[i]));
+ WARN(pfn_to_mfn(pfn) != INVALID_P2M_ENTRY, page must be
ballooned);
+
SetPagePrivate(pages[i]);
set_page_private(pages[i], mfn);
- pages[i]-index = pfn_to_mfn(pfn);
if (unlikely(!set_phys_to_machine(pfn, FOREIGN_FRAME(mfn {
ret = -ENOMEM;
@@ -718,7 +719,7 @@ int clear_foreign_p2m_mapping(struct gnttab_unmap_grant_ref
*unmap_ops,
set_page_private(pages[i], INVALID_P2M_ENTRY);
WARN_ON(!PagePrivate(pages[i]));
ClearPagePrivate(pages[i]);
- set_phys_to_machine(pfn, pages[i]-index);
+ set_phys_to_machine(pfn, INVALID_P2M_ENTRY);
}
if (kunmap_ops)
ret = HYPERVISOR_grant_table_op(GNTTABOP_unmap_grant_ref,
diff --git a/drivers/net/xen-netback/netback.c
b/drivers/net/xen-netback/netback.c
index 908e65e..6441318 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -1241,12 +1241,6 @@ static void xenvif_fill_frags(struct xenvif_queue
*queue, struct sk_buff *skb)
/* Take an extra reference to offset network stack's put_page */
get_page(queue-mmap_pages[pending_idx]);
}
- /* FIXME: __skb_fill_page_desc set this to true because page-pfmemalloc
-* overlaps with index, and mapping is not set. I think mapping
-* should be set. If delivered to local stack, it would drop this
-* skb in sk_filter unless the socket has the right to use it.
-*/
- skb-pfmemalloc = false;
}
static int xenvif_get_extras(struct xenvif_queue *queue,
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 02/12] mm: add 'foreign' alias for the 'pinned' page flag
From: Jenny Herbert jennifer.herb...@citrix.com
The foreign page flag will be used by Xen guests to mark pages that
have grant mappings of frames from other (foreign) guests.
The foreign flag is an aliases the existing (Xen-specific) pinned
flag. This is safe because pinned is only used on pages used for page
tables and these cannot also be foreign.
Signed-off-by: Jenny Herbert jennifer.herb...@citrix.com
Signed-off-by: David Vrabel david.vra...@citrix.com
---
include/linux/page-flags.h |2 ++
1 file changed, 2 insertions(+)
diff --git a/include/linux/page-flags.h b/include/linux/page-flags.h
index e1f5fcd..7734cc8 100644
--- a/include/linux/page-flags.h
+++ b/include/linux/page-flags.h
@@ -123,6 +123,7 @@ enum pageflags {
/* XEN */
PG_pinned = PG_owner_priv_1,
PG_savepinned = PG_dirty,
+ PG_foreign = PG_owner_priv_1,
/* SLOB */
PG_slob_free = PG_private,
@@ -215,6 +216,7 @@ __PAGEFLAG(Slab, slab)
PAGEFLAG(Checked, checked) /* Used by some filesystems */
PAGEFLAG(Pinned, pinned) TESTSCFLAG(Pinned, pinned)/* Xen */
PAGEFLAG(SavePinned, savepinned); /* Xen */
+PAGEFLAG(Foreign, foreign);/* Xen */
PAGEFLAG(Reserved, reserved) __CLEARPAGEFLAG(Reserved, reserved)
PAGEFLAG(SwapBacked, swapbacked) __CLEARPAGEFLAG(SwapBacked, swapbacked)
__SETPAGEFLAG(SwapBacked, swapbacked)
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 06/12] xen: mark grant mapped pages as foreign
From: Jenny Herbert jennifer.herb...@citrix.com
Use the foreign page flag to mark pages that have a grant map. Use
page-private to store information of the grant (the granting domain
and the grant reference).
Signed-off-by: Jenny Herbert jenny.herb...@citrix.com
Signed-off-by: David Vrabel david.vra...@citrix.com
---
arch/x86/xen/p2m.c| 50 ++---
include/xen/grant_table.h | 13
2 files changed, 56 insertions(+), 7 deletions(-)
diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index 0d70814..22624a3 100644
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -648,6 +648,43 @@ bool set_phys_to_machine(unsigned long pfn, unsigned long
mfn)
return true;
}
+static int
+init_page_grant_ref(struct page *p, domid_t domid, grant_ref_t grantref)
+{
+#ifdef CONFIG_X86_64
+ uint64_t gref;
+ uint64_t* gref_p = gref;
+#else
+ uint64_t* gref_p = kmalloc(sizeof(uint64_t), GFP_KERNEL);
+ if (!gref)
+ return -ENOMEM;
+ uint64_t* gref = gref_p;
+#endif
+
+ *gref_p = ((uint64_t) grantref 32) | domid;
+ p-private = gref;
+
+ WARN_ON(PagePrivate(p));
+ WARN_ON(PageForeign(p));
+ SetPagePrivate(p);
+ SetPageForeign(p);
+ return 0;
+}
+
+static void
+clear_page_grant_ref(struct page *p)
+{
+ WARN_ON(!PagePrivate(p));
+ WARN_ON(!PageForeign(p));
+
+#ifndef CONFIG_X86_64
+ kfree(p-private);
+#endif
+ p-private = 0;
+ ClearPagePrivate(p);
+ ClearPageForeign(p);
+}
+
int set_foreign_p2m_mapping(struct gnttab_map_grant_ref *map_ops,
struct gnttab_map_grant_ref *kmap_ops,
struct page **pages, unsigned int count)
@@ -681,11 +718,12 @@ int set_foreign_p2m_mapping(struct gnttab_map_grant_ref
*map_ops,
}
pfn = page_to_pfn(pages[i]);
- WARN_ON(PagePrivate(pages[i]));
- WARN(pfn_to_mfn(pfn) != INVALID_P2M_ENTRY, page must be
ballooned);
+ ret = init_page_grant_ref(pages[i],
+ map_ops[i].dom, map_ops[i].ref);
+ if (ret 0)
+ goto out;
- SetPagePrivate(pages[i]);
- set_page_private(pages[i], mfn);
+ WARN(pfn_to_mfn(pfn) != INVALID_P2M_ENTRY, page must be
ballooned);
if (unlikely(!set_phys_to_machine(pfn, FOREIGN_FRAME(mfn {
ret = -ENOMEM;
@@ -716,9 +754,7 @@ int clear_foreign_p2m_mapping(struct gnttab_unmap_grant_ref
*unmap_ops,
goto out;
}
- set_page_private(pages[i], INVALID_P2M_ENTRY);
- WARN_ON(!PagePrivate(pages[i]));
- ClearPagePrivate(pages[i]);
+ clear_page_grant_ref(pages[i]);
set_phys_to_machine(pfn, INVALID_P2M_ENTRY);
}
if (kunmap_ops)
diff --git a/include/xen/grant_table.h b/include/xen/grant_table.h
index 7235d8f..381f007 100644
--- a/include/xen/grant_table.h
+++ b/include/xen/grant_table.h
@@ -45,6 +45,7 @@
#include asm/xen/hypervisor.h
#include xen/features.h
+#include linux/mm_types.h
#define GNTTAB_RESERVED_XENSTORE 1
@@ -182,4 +183,16 @@ int gnttab_unmap_refs(struct gnttab_unmap_grant_ref
*unmap_ops,
void gnttab_batch_map(struct gnttab_map_grant_ref *batch, unsigned count);
void gnttab_batch_copy(struct gnttab_copy *batch, unsigned count);
+static inline void
+get_page_grant_ref(struct page *p, domid_t* domid, grant_ref_t* grantref)
+{
+#ifdef CONFIG_X86_64
+ uint64_t gref = p-private;
+#else
+ uint64_t gref = *p-private;
+#endif
+ *domid = gref 0x;
+ *grantref = gref 32;
+}
+
#endif /* __ASM_GNTTAB_H__ */
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 04/12] xen: remove scratch frames for ballooned pages and m2p override
The scratch frame mappings for ballooned pages and the m2p override
are broken. Remove them in preparation for replacing them with
simpler mechanisms that works.
The scratch pages did not ensure that the page was not in use. In
particular, the foreign page could still be in use by hardware. If
the guest reused the frame the hardware could read or write that
frame.
The m2p override did not handle the same frame being granted by two
different grant references. Trying an M2P override lookup in this
case is impossible.
Signed-off-by: David Vrabel david.vra...@citrix.com
---
arch/x86/include/asm/xen/page.h | 18 +--
arch/x86/xen/p2m.c | 254 ++-
drivers/xen/balloon.c | 86 +
3 files changed, 14 insertions(+), 344 deletions(-)
diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
index e9f52fe..358dcd3 100644
--- a/arch/x86/include/asm/xen/page.h
+++ b/arch/x86/include/asm/xen/page.h
@@ -57,7 +57,6 @@ extern int set_foreign_p2m_mapping(struct
gnttab_map_grant_ref *map_ops,
extern int clear_foreign_p2m_mapping(struct gnttab_unmap_grant_ref *unmap_ops,
struct gnttab_unmap_grant_ref *kunmap_ops,
struct page **pages, unsigned int count);
-extern unsigned long m2p_find_override_pfn(unsigned long mfn, unsigned long
pfn);
/*
* Helper functions to write or read unsigned long values to/from
@@ -154,21 +153,12 @@ static inline unsigned long mfn_to_pfn(unsigned long mfn)
return mfn;
pfn = mfn_to_pfn_no_overrides(mfn);
- if (__pfn_to_mfn(pfn) != mfn) {
- /*
-* If this appears to be a foreign mfn (because the pfn
-* doesn't map back to the mfn), then check the local override
-* table to see if there's a better pfn to use.
-*
-* m2p_find_override_pfn returns ~0 if it doesn't find anything.
-*/
- pfn = m2p_find_override_pfn(mfn, ~0);
- }
+ if (__pfn_to_mfn(pfn) != mfn)
+ pfn = ~0;
/*
-* pfn is ~0 if there are no entries in the m2p for mfn or if the
-* entry doesn't map back to the mfn and m2p_override doesn't have a
-* valid entry for it.
+* pfn is ~0 if there are no entries in the m2p for mfn or the
+* entry doesn't map back to the mfn.
*/
if (pfn == ~0 __pfn_to_mfn(mfn) == IDENTITY_FRAME(mfn))
pfn = mfn;
diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index 9fd5f70..8f34ed4 100644
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -84,8 +84,6 @@
#define PMDS_PER_MID_PAGE (P2M_MID_PER_PAGE / PTRS_PER_PTE)
-static void __init m2p_override_init(void);
-
unsigned long *xen_p2m_addr __read_mostly;
EXPORT_SYMBOL_GPL(xen_p2m_addr);
unsigned long xen_p2m_size __read_mostly;
@@ -399,8 +397,6 @@ void __init xen_vmalloc_p2m_tree(void)
xen_p2m_size = xen_max_p2m_pfn;
xen_inv_extra_mem();
-
- m2p_override_init();
}
unsigned long get_phys_to_machine(unsigned long pfn)
@@ -652,100 +648,21 @@ bool set_phys_to_machine(unsigned long pfn, unsigned
long mfn)
return true;
}
-#define M2P_OVERRIDE_HASH_SHIFT10
-#define M2P_OVERRIDE_HASH (1 M2P_OVERRIDE_HASH_SHIFT)
-
-static struct list_head *m2p_overrides;
-static DEFINE_SPINLOCK(m2p_override_lock);
-
-static void __init m2p_override_init(void)
-{
- unsigned i;
-
- m2p_overrides = alloc_bootmem_align(
- sizeof(*m2p_overrides) * M2P_OVERRIDE_HASH,
- sizeof(unsigned long));
-
- for (i = 0; i M2P_OVERRIDE_HASH; i++)
- INIT_LIST_HEAD(m2p_overrides[i]);
-}
-
-static unsigned long mfn_hash(unsigned long mfn)
-{
- return hash_long(mfn, M2P_OVERRIDE_HASH_SHIFT);
-}
-
-/* Add an MFN override for a particular page */
-static int m2p_add_override(unsigned long mfn, struct page *page,
- struct gnttab_map_grant_ref *kmap_op)
-{
- unsigned long flags;
- unsigned long pfn;
- unsigned long uninitialized_var(address);
- unsigned level;
- pte_t *ptep = NULL;
-
- pfn = page_to_pfn(page);
- if (!PageHighMem(page)) {
- address = (unsigned long)__va(pfn PAGE_SHIFT);
- ptep = lookup_address(address, level);
- if (WARN(ptep == NULL || level != PG_LEVEL_4K,
-m2p_add_override: pfn %lx not mapped, pfn))
- return -EINVAL;
- }
-
- if (kmap_op != NULL) {
- if (!PageHighMem(page)) {
- struct multicall_space mcs =
- xen_mc_entry(sizeof(*kmap_op));
-
- MULTI_grant_table_op(mcs.mc,
- GNTTABOP_map_grant_ref, kmap_op, 1);
-
[Xen-devel] [PATCH 07/12] xen-netback: use foreign page information from the pages themselves
From: Jenny Herbert jenny.herb...@citrix.com
Use the foreign page flag in netback to get the domid and grant ref
needed for the grant copy. This signficiantly simplifies the netback
code and makes netback work with foreign pages from other backends
(e.g., blkback).
This allows blkback to use iSCSI disks provided by domUs running on
the same host.
Signed-off-by: Jenny Herbert jennifer.herb...@citrix.com
Signed-off-by: David Vrabel david.vra...@citrix.com
---
drivers/net/xen-netback/netback.c | 97 +++--
1 file changed, 6 insertions(+), 91 deletions(-)
diff --git a/drivers/net/xen-netback/netback.c
b/drivers/net/xen-netback/netback.c
index 6441318..997088b 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -314,9 +314,7 @@ static struct xenvif_rx_meta *get_next_rx_buffer(struct
xenvif_queue *queue,
static void xenvif_gop_frag_copy(struct xenvif_queue *queue, struct sk_buff
*skb,
struct netrx_pending_operations *npo,
struct page *page, unsigned long size,
-unsigned long offset, int *head,
-struct xenvif_queue *foreign_queue,
-grant_ref_t foreign_gref)
+unsigned long offset, int *head)
{
struct gnttab_copy *copy_gop;
struct xenvif_rx_meta *meta;
@@ -361,9 +359,9 @@ static void xenvif_gop_frag_copy(struct xenvif_queue
*queue, struct sk_buff *skb
copy_gop-flags = GNTCOPY_dest_gref;
copy_gop-len = bytes;
- if (foreign_queue) {
- copy_gop-source.domid = foreign_queue-vif-domid;
- copy_gop-source.u.ref = foreign_gref;
+ if (PageForeign(page)) {
+ get_page_grant_ref(page, copy_gop-source.domid,
+ copy_gop-source.u.ref);
copy_gop-flags |= GNTCOPY_source_gref;
} else {
copy_gop-source.domid = DOMID_SELF;
@@ -406,35 +404,6 @@ static void xenvif_gop_frag_copy(struct xenvif_queue
*queue, struct sk_buff *skb
}
/*
- * Find the grant ref for a given frag in a chain of struct ubuf_info's
- * skb: the skb itself
- * i: the frag's number
- * ubuf: a pointer to an element in the chain. It should not be NULL
- *
- * Returns a pointer to the element in the chain where the page were found. If
- * not found, returns NULL.
- * See the definition of callback_struct in common.h for more details about
- * the chain.
- */
-static const struct ubuf_info *xenvif_find_gref(const struct sk_buff *const
skb,
- const int i,
- const struct ubuf_info *ubuf)
-{
- struct xenvif_queue *foreign_queue = ubuf_to_queue(ubuf);
-
- do {
- u16 pending_idx = ubuf-desc;
-
- if (skb_shinfo(skb)-frags[i].page.p ==
- foreign_queue-mmap_pages[pending_idx])
- break;
- ubuf = (struct ubuf_info *) ubuf-ctx;
- } while (ubuf);
-
- return ubuf;
-}
-
-/*
* Prepare an SKB to be transmitted to the frontend.
*
* This function is responsible for allocating grant operations, meta
@@ -459,8 +428,6 @@ static int xenvif_gop_skb(struct sk_buff *skb,
int head = 1;
int old_meta_prod;
int gso_type;
- const struct ubuf_info *ubuf = skb_shinfo(skb)-destructor_arg;
- const struct ubuf_info *const head_ubuf = ubuf;
old_meta_prod = npo-meta_prod;
@@ -507,68 +474,16 @@ static int xenvif_gop_skb(struct sk_buff *skb,
len = skb_tail_pointer(skb) - data;
xenvif_gop_frag_copy(queue, skb, npo,
-virt_to_page(data), len, offset, head,
-NULL,
-0);
+virt_to_page(data), len, offset, head);
data += len;
}
for (i = 0; i nr_frags; i++) {
- /* This variable also signals whether foreign_gref has a real
-* value or not.
-*/
- struct xenvif_queue *foreign_queue = NULL;
- grant_ref_t foreign_gref;
-
- if ((skb_shinfo(skb)-tx_flags SKBTX_DEV_ZEROCOPY)
- (ubuf-callback == xenvif_zerocopy_callback)) {
- const struct ubuf_info *const startpoint = ubuf;
-
- /* Ideally ubuf points to the chain element which
-* belongs to this frag. Or if frags were removed from
-* the beginning, then shortly before it.
-*/
- ubuf = xenvif_find_gref(skb, i, ubuf);
-
- /*
[Xen-devel] [RFC PATCH 00/12] xen: fix many long-standing grant mapping bugs
This series fixes a number of long-standing bugs in the handling of grant maps. Refer to the following for all the details. http://xenbits.xen.org/people/dvrabel/grant-improvements-B.pdf In summary, the important uses that this enables are: 1. Block backends can use networked storage safely. 2. Block backends can use network storage provided by other guests on the same host. 3. User space block backends can use direct I/O or asynchronous I/O. The first two patches are the core MM changes necessary. I shall be sending these to the MM maintainers seperately. Patches #3 and #4 remove existing (broken) mechanisms. This does temporarily break some previously working use cases, but it does make the subsequent additions much easier to review. As a happy side effect, performance is also likely to be improved in some areas (but I've not got any measurements yet). User space backends using grant mapping should see some good improvements from reduced overheads and better unmap batching. VIF to VIF network traffic may also see a small improvement. This is RFC because: - It needs more testing. - I've not checked what changes (if any) are needed for ARM. Finally, thanks to Jenny who did much of the implementation. David ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 03/12] xen/grant-table: pre-populate kernel unmap ops for xen_gnttab_unmap_refs()
When unmapping grants, instead of converting the kernel map ops to
unmap ops on the fly, pre-populate the set of unmap ops.
This allows the grant unmap for the kernel mappings to be trivially
batched in the future.
Signed-off-by: David Vrabel david.vra...@citrix.com
---
arch/arm/include/asm/xen/page.h |2 +-
arch/arm/xen/p2m.c |2 +-
arch/x86/include/asm/xen/page.h |2 +-
arch/x86/xen/p2m.c | 21 ++---
drivers/xen/gntdev.c| 26 ++
drivers/xen/grant-table.c |4 ++--
include/xen/grant_table.h |2 +-
7 files changed, 34 insertions(+), 25 deletions(-)
diff --git a/arch/arm/include/asm/xen/page.h b/arch/arm/include/asm/xen/page.h
index 68c739b..2f7e6ff 100644
--- a/arch/arm/include/asm/xen/page.h
+++ b/arch/arm/include/asm/xen/page.h
@@ -92,7 +92,7 @@ extern int set_foreign_p2m_mapping(struct
gnttab_map_grant_ref *map_ops,
struct page **pages, unsigned int count);
extern int clear_foreign_p2m_mapping(struct gnttab_unmap_grant_ref *unmap_ops,
-struct gnttab_map_grant_ref *kmap_ops,
+struct gnttab_unmap_grant_ref *kunmap_ops,
struct page **pages, unsigned int count);
bool __set_phys_to_machine(unsigned long pfn, unsigned long mfn);
diff --git a/arch/arm/xen/p2m.c b/arch/arm/xen/p2m.c
index 0548577..cb7a14c 100644
--- a/arch/arm/xen/p2m.c
+++ b/arch/arm/xen/p2m.c
@@ -102,7 +102,7 @@ int set_foreign_p2m_mapping(struct gnttab_map_grant_ref
*map_ops,
EXPORT_SYMBOL_GPL(set_foreign_p2m_mapping);
int clear_foreign_p2m_mapping(struct gnttab_unmap_grant_ref *unmap_ops,
- struct gnttab_map_grant_ref *kmap_ops,
+ struct gnttab_unmap_grant_ref *kunmap_ops,
struct page **pages, unsigned int count)
{
int i;
diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
index 5eea099..e9f52fe 100644
--- a/arch/x86/include/asm/xen/page.h
+++ b/arch/x86/include/asm/xen/page.h
@@ -55,7 +55,7 @@ extern int set_foreign_p2m_mapping(struct
gnttab_map_grant_ref *map_ops,
struct gnttab_map_grant_ref *kmap_ops,
struct page **pages, unsigned int count);
extern int clear_foreign_p2m_mapping(struct gnttab_unmap_grant_ref *unmap_ops,
-struct gnttab_map_grant_ref *kmap_ops,
+struct gnttab_unmap_grant_ref *kunmap_ops,
struct page **pages, unsigned int count);
extern unsigned long m2p_find_override_pfn(unsigned long mfn, unsigned long
pfn);
diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index edbc7a6..9fd5f70 100644
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -816,7 +816,7 @@ static struct page *m2p_find_override(unsigned long mfn)
}
static int m2p_remove_override(struct page *page,
- struct gnttab_map_grant_ref *kmap_op,
+ struct gnttab_unmap_grant_ref *kunmap_op,
unsigned long mfn)
{
unsigned long flags;
@@ -840,7 +840,7 @@ static int m2p_remove_override(struct page *page,
list_del(page-lru);
spin_unlock_irqrestore(m2p_override_lock, flags);
- if (kmap_op != NULL) {
+ if (kunmap_op != NULL) {
if (!PageHighMem(page)) {
struct multicall_space mcs;
struct gnttab_unmap_and_replace *unmap_op;
@@ -855,13 +855,13 @@ static int m2p_remove_override(struct page *page,
* issued. In this case handle is going to -1 because
* it hasn't been modified yet.
*/
- if (kmap_op-handle == -1)
+ if (kunmap_op-handle == -1)
xen_mc_flush();
/*
* Now if kmap_op-handle is negative it means that the
* hypercall actually returned an error.
*/
- if (kmap_op-handle == GNTST_general_error) {
+ if (kunmap_op-handle == GNTST_general_error) {
pr_warn(m2p_remove_override: pfn %lx mfn %lx,
failed to modify kernel mappings,
pfn, mfn);
put_balloon_scratch_page();
@@ -873,9 +873,9 @@ static int m2p_remove_override(struct page *page,
mcs = __xen_mc_entry(
sizeof(struct gnttab_unmap_and_replace));
unmap_op = mcs.args;
- unmap_op-host_addr = kmap_op-host_addr;
+ unmap_op-host_addr = kunmap_op-host_addr;
Re: [Xen-devel] [PATCH] xen-netback: fixing the propagation of the transmit shaper timeout
From: Ian Campbell ian.campb...@citrix.com Date: Tue, 6 Jan 2015 15:54:07 + On Tue, 2015-01-06 at 16:44 +0100, Imre Palik wrote: From: Palik, Imre im...@amazon.de Since e9ce7cb6b107 (xen-netback: Factor queue-specific data into queue struct), the transimt shaper timeout is always set to 0. The value the user sets via xenbus is never propagated to the transmit shaper. This patch fixes the issue. Cc: Anthony Liguori aligu...@amazon.com Signed-off-by: Imre Palik im...@amazon.de Acked-by: Ian Campbell ian.campb...@citrix.com Applied and queued up for -stable, thanks. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 12/12] xen/gntdev: provide a set of pages for each VMA
From: Jenny Herbert jennifer.herb...@citrix.com For each VMA for grant maps, provide the correct array of pages so get_user_pages() on foreign mappings works in PV guests. Signed-off-by: Jenny Herbert jennifer.herb...@citrix.com Signed-off-by: David Vrabel david.vra...@citrix.com --- drivers/xen/gntdev.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c index 5d73fe8..09e7863 100644 --- a/drivers/xen/gntdev.c +++ b/drivers/xen/gntdev.c @@ -870,6 +870,8 @@ static int gntdev_mmap(struct file *flip, struct vm_area_struct *vma) vma-vm_end - vma-vm_start, set_grant_ptes_as_special, NULL); } + + vma-pages = map-pages; } return 0; -- 1.7.10.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] README, xen/Makefile: Update to Xen 4.5.0
Tuesday, January 6, 2015, 7:21:58 PM, you wrote: On Tue, Jan 06, 2015 at 06:06:23PM +, Ian Jackson wrote: Konrad Rzeszutek Wilk writes ([Xen-devel] [PATCH] README, xen/Makefile: Update to Xen 4.5.0): -The 4.3 release offers a number of improvements, including NUMA -scheduling affinity, openvswitch integration, and defaulting to -qemu-xen rather than qemu-traditional for non-stubdom guests. -(qemu-xen is kept very close to the upstream project.) We also have a -number of updates to vTPM, and improvements to XSM and Flask to allow -greater disaggregation. Additionally, 4.3 contains a basic version of -Xen for the new ARM server architecture, both 32- and 64-bit. And as -always, there are a number of performance, stability, and security +The 4.5 release offers a number of improvements: including shedding Should read +The 4.5 release offers a number of improvements, including: shedding (note two punctuation changes) and the list items should all be separated with semicolons IMO. Thank you for your update. I've incorporated feedback from all folks I hope. Would this be satisfactory? From 89041667dfdc298dbe0f17a1f66a748a1a13089f Mon Sep 17 00:00:00 2001 From: Konrad Rzeszutek Wilk konrad.w...@oracle.com Date: Tue, 6 Jan 2015 12:03:10 -0500 Subject: [PATCH] README, xen/Makefile: Update to Xen 4.5.0 Expand the README file to give a brief view of what went in Xen 4.5.0. Also change the Makefile to not use the '-rc' postfix. Signed-off-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com --- README | 45 - xen/Makefile | 2 +- 2 files changed, 33 insertions(+), 14 deletions(-) diff --git a/README b/README index 412607a..641bb23 100644 --- a/README +++ b/README @@ -1,9 +1,9 @@ # -__ ___ ___ _ -\ \/ /___ _ __ | || | | ___| _ _ _ __ ___| |_ __ _| |__ | | ___ - \ // _ \ '_ \ | || |_ |___ \ _| | | | '_ \/ __| __/ _` | '_ \| |/ _ \ - / \ __/ | | | |__ _| ___) |_| |_| | | | \__ \ || (_| | |_) | | __/ -/_/\_\___|_| |_||_|(_)/ \__,_|_| |_|___/\__\__,_|_.__/|_|\___| +__ ___ _ ___ +\ \/ /___ _ __ | || | | ___| / _ \ + \ // _ \ '_ \ | || |_ |___ \| | | | + / \ __/ | | | |__ _| ___) | |_| | +/_/\_\___|_| |_||_|(_)(_)___/ # @@ -19,14 +19,33 @@ is freely-distributable Open Source software, released under the GNU GPL. Since its initial public release, Xen has grown a large development community, spearheaded by xen.org (http://www.xen.org). Shouldn't this be Xen-project and http://www.xenproject.org;, since the transition to the Linux foundation ? (there are a lot more in-tree places where this could/should be changed for 4.6) -- Sander -The 4.3 release offers a number of improvements, including NUMA -scheduling affinity, openvswitch integration, and defaulting to -qemu-xen rather than qemu-traditional for non-stubdom guests. -(qemu-xen is kept very close to the upstream project.) We also have a -number of updates to vTPM, and improvements to XSM and Flask to allow -greater disaggregation. Additionally, 4.3 contains a basic version of -Xen for the new ARM server architecture, both 32- and 64-bit. And as -always, there are a number of performance, stability, and security +The 4.5 release offers a number of improvements, including: improvements for +large scale machines during bootup and for PCI passthrough; multiple IO-REQ +servers (many QEMUs for a guest); soft affinity for vCPUs (aka NUMA affinity); +and API expansion for guest introspection. We also have number of updates for +CPU specific changes, such as: Broadwell Supervisor Mode Access Prevention; +Haswell Server Cache QoS Monitoring aka Intel Resource Director Technology; +further extensions to vAPIC (SandyBridge feature); fixes in AMD microcode +loading; Data Breaking Extensions and masking MSR support on AMD. + +On the experimental side we have added a new Real-Time Deferrable Server Based +CPU Scheduler (rtds), and PVH initial domain (dom0) support for Intel CPUs. + +Additionally, 4.5 has a huge update to the ARM code, including support for: +up to 1TB in guests; up to 8 CPUs; Power State Coordination Interface (0.2) +to power up and down CPUs; UEFI booting; IOMMU support (SMMUv1); Super Page +(2MB) support; passthrough of MMIO regions to guests; and lower interrupt +latency. + +The toolstack has expanded to include support for: VM Generation ID (a Windows +2012 Server requirement); Remus initial support (for high availability) +in libxl (since xend has been removed); libxenlight JSON support and persistent +configuration support, systemd support; and support in QEMU for expanding the +PCI hole. + +Lastly, we have removed the Python toolstack (xend). + +And as always, there
Re: [Xen-devel] [RFC 2/2] x86, vdso, pvclock: Simplify and speed up the vdso pvclock reader
On Tue, Jan 06, 2015 at 10:26:22AM -0800, Andy Lutomirski wrote:
On Tue, Jan 6, 2015 at 10:13 AM, Marcelo Tosatti mtosa...@redhat.com wrote:
On Tue, Jan 06, 2015 at 08:56:40AM -0800, Andy Lutomirski wrote:
On Jan 6, 2015 4:01 AM, Paolo Bonzini pbonz...@redhat.com wrote:
On 06/01/2015 09:42, Paolo Bonzini wrote:
Still confused. So we can freeze all vCPUs in the host, then
update
pvti 1, then resume vCPU 1, then update pvti 0? In that case, we
have
a problem, because vCPU 1 can observe pvti 0 mid-update, and KVM
doesn't increment the version pre-update, and we can return
completely
bogus results.
Yes.
But then the getcpu test would fail (1-0). Even if you have an ABA
situation (1-0-1), it's okay because the pvti that is fetched is the
one returned by the first getcpu.
... this case of partial update of pvti, which is caught by the version
field, if of course different from the other (extremely unlikely) that
Andy pointed out. That is when the getcpus are done on the same vCPU,
but the rdtsc is another.
That one can be fixed by rdtscp, like
do {
// get a consistent (pvti, v, tsc) tuple
do {
cpu = get_cpu();
pvti = get_pvti(cpu);
v = pvti-version ~1;
// also acts as rmb();
rdtsc_barrier();
tsc = rdtscp(cpu1);
Off-topic note: rdtscp doesn't need a barrier at all. AIUI AMD
specified it that way and both AMD and Intel implement it correctly.
(rdtsc, on the other hand, definitely needs the barrier beforehand.)
// control dependency, no need for rdtsc_barrier?
} while(cpu != cpu1);
// ... compute nanoseconds from pvti and tsc ...
rmb();
} while(v != pvti-version);
Still no good. We can migrate a bunch of times so we see the same CPU
all three times and *still* don't get a consistent read, unless we
play nasty games with lots of version checks (I have a patch for that,
but I don't like it very much). The patch is here:
https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/commit/?h=x86/vdso_paranoiaid=a69754dc5ff33f5187162b5338854ad23dd7be8d
but I don't like it.
Thus far, I've been told unambiguously that a guest can't observe pvti
while it's being written, and I think you're now telling me that this
isn't true and that a guest *can* observe pvti while it's being
written while the low bit of the version field is not set. If so,
this is rather strongly incompatible with the spec in the KVM docs.
I don't suppose that you and Marcelo could agree on what the actual
semantics that KVM provides are and could write it down in a way that
people who haven't spent a long time staring at the request code
understand? And maybe you could even fix the implementation while
you're at it if the implementation is, indeed, broken. I have ugly
patches to fix it here:
https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/commit/?h=x86/vdso_paranoiaid=3b718a050cba52563d831febc2e1ca184c02bac0
but I'm not thrilled with them.
--Andy
I suppose that separating the version write from the rest of the pvclock
structure is sufficient, as that would guarantee the writes are not
reordered even with fast string REP MOVS.
Thanks for catching this Andy!
Don't you stil need:
version++;
write the rest;
version++;
with possible smp_wmb() in there to keep the compiler from messing around?
Correct. Could just as well follow the protocol and use odd/even, which
is what your patch does.
What is the point with the new flags bit though?
Also, if you do this, can you also make setting and clearing
STABLE_BIT properly atomic across all vCPUs? Or at least do something
like setting it last and clearing it first on vPCU 0?
If the version seqlock works properly across vCPUs, why do you need
STABLE_BIT properly atomic ?
Please define what you mean by properly atomic.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] Xen 4.5 Development Update (GA slip by a week)
On Tue, Jan 6, 2015 at 10:51 AM, Lars Kurth lars.kurth@gmail.com wrote: On 6 Jan 2015, at 18:08, Suriyan Ramasami suriya...@gmail.com wrote: I shall try my hand at updating the information again. If this needs to be done (yesterday), then as a temporary solution we could just delete this information for now, and I shall work on it soon. Ideally it needs to be done by next Wed. If you have the content, you could send it to me and I can fix the page Thanks Lars for the offer. I just started editing the page, and looks simple enough to get some content out there. I should have updated the relevant information in a few hours from now. Please do help me in fixing the page once its done (if it needs fixing) Thanks! - Suriyan Lars ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Xen 4.5 Development Update (GA slip by a week)
On 6 Jan 2015, at 18:08, Suriyan Ramasami suriya...@gmail.com wrote: I shall try my hand at updating the information again. If this needs to be done (yesterday), then as a temporary solution we could just delete this information for now, and I shall work on it soon. Ideally it needs to be done by next Wed. If you have the content, you could send it to me and I can fix the page Lars ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [Xen-users] HVM PCI Passthrough: Code 12: Undersized PCI MMIO region?
On 01/06/15 08:00, Pasi Kärkkäinen wrote: On Tue, Dec 02, 2014 at 10:08:35PM -0500, Stephen Oberholtzer wrote: All, Hello, Please bear with me. I don't fully understand all of the mechanisms involved here, so this message contains a large quantity of data, including some links to even larger quantities of data. The short version is: I think something isn't reserving enough (GPFN) address space for MMIO. ... Now, I don't fully understand how this stuff all works, but here's what appears to be happening: Xen isn't reserving enough contiguous GPFN (virtual machine address space) for all of the devices on the virtual PCI bus -- in particular, for what is probably a big honkin' window into the card's onboard RAM. So my two questions are: (1) Is my guess correct? Or at least close? I think so. (2) What the heck do I do about it? I don't see any options in xl.cfg(5) for specifying the size of the MMIO region for the virtual PCI bus, or anything similar to that. There is a new feature in xen 4.5 (soon to be released) that you can add to the config file (xl.cfg): Memory layout mmio_hole=MBYTES Specifies the size the MMIO hole below 4GiB will be. Only valid for device_model_version = qemu-xen. Cannot be smaller than 256. Cannot be larger than 3840. Known good large value is 3072. Subject: [Xen-devel] Xen Project 4.5 RC4 is Ready Today; Test Day is Wednesday Date: Mon, 15 Dec 2014 14:33:33 -0500 From: Russ Pavlicek russell.pavli...@xenproject.org To: xen-devel@lists.xen.org, xen-us...@lists.xen.org xen-us...@lists.xen.org, xen-annou...@lists.xenproject.org, xs-de...@lists.xenserver.org, mirageos-de...@lists.xenproject.org, xen-...@lists.xen.org Folks, This Wednesday, December 17, is our fourth and FINAL Test Day for the 4.5 release cycle (barring any changes which may result from Wednesday's Test Day). Release Candidate 4 is available for assessment today. If you've held off testing the new release until it matures, delay no longer! Test and state your concerns now or the next release you see could be the official one Information about testing this release can be found here: http://wiki.xenproject.org/wiki/Xen_4.5_RC4_test_instructions To learn more about Test Days, including the scheduled date for the final release, check out: http://wiki.xenproject.org/wiki/Xen_Project_Test_Days -Don Slutz NOTE: If I assign 2048MB or less RAM to this VM, the VM crashes at bootup, and has a nasty tendency to take the host with it (lockup). -- -- Stevie-O Real programmers use COPY CON PROGRAM.EXE -- Pasi ___ Xen-users mailing list xen-us...@lists.xen.org http://lists.xen.org/xen-users ___ 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 11/12] xen/gntdev: mark userspace PTEs as special on x86 PV guests
In an x86 PV guest, get_user_pages_fast() on a userspace address range
containing foreign mappings does not work correctly because the M2P
lookup of the MFN from a userspace PTE may return the wrong page.
Force get_user_pages_fast() to fail on such addresses by marking the PTEs
as special.
If Xen has XENFEAT_gnttab_map_avail_bits (available since at least
4.0), we can do so efficiently in the grant map hypercall. Otherwise,
it needs to be done afterwards. This is both inefficient and racy
(the mapping is visible to the task before we fixup the PTEs), but
will be fine for well-behaved applications that do not use the mapping
until after the mmap() system call returns.
Guests with XENFEAT_auto_translated_physmap (ARM and x86 HVM or PVH)
do not need this since get_user_pages() has always worked correctly
for them.
Signed-off-by: David Vrabel david.vra...@citrix.com
---
drivers/xen/gntdev.c| 32 ++--
include/xen/interface/features.h|6 ++
include/xen/interface/grant_table.h |7 +++
3 files changed, 43 insertions(+), 2 deletions(-)
diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
index a740dce..5d73fe8 100644
--- a/drivers/xen/gntdev.c
+++ b/drivers/xen/gntdev.c
@@ -244,11 +244,24 @@ static int find_grant_ptes(pte_t *pte, pgtable_t token,
BUG_ON(pgnr = map-count);
pte_maddr = arbitrary_virt_to_machine(pte).maddr;
+ /*
+* Set the PTE as special to force get_user_pages_fast() fall
+* back to the slow path. If this is not supported as part of
+* the grant map, it will be done afterwards.
+*/
+ if (xen_feature(XENFEAT_gnttab_map_avail_bits))
+ flags |= (1 _GNTMAP_guest_avail0);
+
gnttab_set_map_op(map-map_ops[pgnr], pte_maddr, flags,
map-grants[pgnr].ref,
map-grants[pgnr].domid);
- gnttab_set_unmap_op(map-unmap_ops[pgnr], pte_maddr, flags,
- -1 /* handle */);
+ return 0;
+}
+
+static int set_grant_ptes_as_special(pte_t *pte, pgtable_t token,
+unsigned long addr, void *data)
+{
+ set_pte_at(current-mm, addr, pte, pte_mkspecial(*pte));
return 0;
}
@@ -842,6 +855,21 @@ static int gntdev_mmap(struct file *flip, struct
vm_area_struct *vma)
if (err)
goto out_put_map;
}
+ } else {
+ /*
+* If the PTEs were not made special by the grant map
+* hypercall, do so here.
+*
+* This is racy since the mapping is already visible
+* to userspace but userspace should be well-behaved
+* enough to not touch it until the mmap() call
+* returns.
+*/
+ if (!xen_feature(XENFEAT_gnttab_map_avail_bits)) {
+ apply_to_page_range(vma-vm_mm, vma-vm_start,
+ vma-vm_end - vma-vm_start,
+ set_grant_ptes_as_special, NULL);
+ }
}
return 0;
diff --git a/include/xen/interface/features.h b/include/xen/interface/features.h
index 131a6cc..6ad3d11 100644
--- a/include/xen/interface/features.h
+++ b/include/xen/interface/features.h
@@ -41,6 +41,12 @@
/* x86: Does this Xen host support the MMU_PT_UPDATE_PRESERVE_AD hypercall? */
#define XENFEAT_mmu_pt_update_preserve_ad 5
+/*
+ * If set, GNTTABOP_map_grant_ref honors flags to be placed into guest kernel
+ * available pte bits.
+ */
+#define XENFEAT_gnttab_map_avail_bits 7
+
/* x86: Does this Xen host support the HVM callback vector type? */
#define XENFEAT_hvm_callback_vector8
diff --git a/include/xen/interface/grant_table.h
b/include/xen/interface/grant_table.h
index bcce564..56806bc 100644
--- a/include/xen/interface/grant_table.h
+++ b/include/xen/interface/grant_table.h
@@ -526,6 +526,13 @@ DEFINE_GUEST_HANDLE_STRUCT(gnttab_cache_flush);
#define GNTMAP_contains_pte (1_GNTMAP_contains_pte)
/*
+ * Bits to be placed in guest kernel available PTE bits (architecture
+ * dependent; only supported when XENFEAT_gnttab_map_avail_bits is set).
+ */
+#define _GNTMAP_guest_avail0(16)
+#define GNTMAP_guest_avail_mask ((uint32_t)~0 _GNTMAP_guest_avail0)
+
+/*
* Values for error status returns. All errors are -ve.
*/
#define GNTST_okay (0) /* Normal return.*/
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC 2/2] x86, vdso, pvclock: Simplify and speed up the vdso pvclock reader
On Tue, Jan 06, 2015 at 11:49:09AM -0800, Andy Lutomirski wrote: What is the point with the new flags bit though? To try to work around the problem on old hosts. I'm not at all convinced that this is worthwhile or that it helps, though. Don't think so. Just fix the host bug. Also, if you do this, can you also make setting and clearing STABLE_BIT properly atomic across all vCPUs? Or at least do something like setting it last and clearing it first on vPCU 0? If the version seqlock works properly across vCPUs, why do you need STABLE_BIT properly atomic ? Please define what you mean by properly atomic. I'd like to be able to rely using vCPU 0's pvti even from other vCPUs in the vdso if the stable bit is set. That means that the host should avoid doing things like migrating the guest, clearing the stable bit for vCPU 1, resuming vCPU 1, and waiting long enough to clear the stable bit for vCPU 0 that vCPU 1's vdso code could see invalid data and return a bad timestamp. Maybe this scenario is impossible, but getting rid of any getcpu-like operation in the vdso has really nice benefits. You can park every vCPU in host while updating vCPU-0's timestamp. See kvm_gen_update_masterclock: + /* no guest entries from this point */ + pvclock_update_vm_gtod_copy(kvm); - touch guest memory + /* guest entries allowed */ + kvm_for_each_vcpu(i, vcpu, kvm) + clear_bit(KVM_REQ_MCLOCK_INPROGRESS, vcpu-requests); It's faster and it lets us guarantee that the vdso's pvti data fits in a single page. The latter means that we can easily make it work like the hpet mapping, which gets us 32-bit support and will *finally* let us turn off user access to the fixmap if vsyscall=none. (We can, of course, still do this if the pvti data needs to be an array, but it's messier.) --Andy ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable test] 33183: trouble: broken/fail/pass
flight 33183 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/33183/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-libvirt 3 host-install(3) broken REGR. vs. 32877 test-amd64-amd64-libvirt 3 host-install(3) broken REGR. vs. 32877 test-amd64-i386-libvirt 3 host-install(3) broken REGR. vs. 32877 test-amd64-i386-rhel6hvm-amd 3 host-install(3) broken REGR. vs. 33112 test-amd64-i386-rhel6hvm-intel 3 host-install(3) broken REGR. vs. 33112 test-amd64-i386-qemut-rhel6hvm-intel 3 host-install(3) broken REGR. vs. 33112 test-amd64-i386-xl-qemuu-debianhvm-amd64 3 host-install(3) broken REGR. vs. 33112 test-amd64-amd64-xl-winxpsp3 3 host-install(3) broken REGR. vs. 33112 test-amd64-i386-xl-qemuu-ovmf-amd64 3 host-install(3) broken REGR. vs. 33112 test-amd64-amd64-xl-qemuu-ovmf-amd64 3 host-install(3) broken REGR. vs. 33112 test-amd64-i386-xl-win7-amd64 3 host-install(3)broken REGR. vs. 33112 test-amd64-i386-pair 4 host-install/dst_host(4) broken REGR. vs. 33112 test-amd64-i386-pair 3 host-install/src_host(3) broken REGR. vs. 33112 test-amd64-amd64-xl-qemut-winxpsp3 3 host-install(3) broken REGR. vs. 33112 test-amd64-amd64-xl-qemut-win7-amd64 3 host-install(3) broken REGR. vs. 33112 test-amd64-amd64-xl-qemuu-winxpsp3 3 host-install(3) broken REGR. vs. 33112 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-pcipt-intel 3 host-install(3) broken REGR. vs. 33112 test-amd64-amd64-xl-sedf 3 host-install(3) broken REGR. vs. 33112 test-amd64-i386-xl-multivcpu 3 host-install(3) broken like 32646 Tests which did not succeed, but are not blocking: test-armhf-armhf-xl 10 migrate-support-checkfail never pass test-amd64-amd64-xl-pvh-amd 9 guest-start fail never pass test-amd64-amd64-xl-pvh-intel 9 guest-start fail never pass test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-qemut-winxpsp3 14 guest-stopfail never pass test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stopfail never pass test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-amd64-xl-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-i386-xl-winxpsp3 14 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop fail never pass version targeted for testing: xen d3c151fd3a4365fc6107198bfc975807d40d157d baseline version: xen 36174af3fbeb1b662c0eadbfa193e77f68cc955b People who touched revisions under test: Andrew Cooper andrew.coop...@citrix.com Ian Campbell ian.campb...@citrix.com Ian Campbell i...@hellion.org.uk Ian Jackson ian.jack...@eu.citrix.com Ian Jackson i...@mariner.uk.xensource.com Jan Beulich jbeul...@suse.com Julien Grall julien.gr...@linaro.org Konrad Rzeszutek Wilk konrad.w...@oracle.com Mihai DonÈu mdo...@bitdefender.com Robert Hu robert...@intel.com RÄzvan Cojocaru rcojoc...@bitdefender.com Stefano Stabellini stefano.stabell...@eu.citrix.com Wei Liu wei.l...@citrix.com Yang Hongyang yan...@cn.fujitsu.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-oldkern pass build-i386-oldkern pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass build-amd64-rumpuserxen pass build-i386-rumpuserxen pass test-amd64-amd64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-amd64-xl-pvh-amd fail test-amd64-i386-rhel6hvm-amd
Re: [Xen-devel] [PATCH 4/4] tools: add total/local memory bandwith monitoring
On Tue, Jan 06, 2015 at 10:29:18AM +, Andrew Cooper wrote:
On 06/01/15 10:09, Chao Peng wrote:
On Mon, Jan 05, 2015 at 12:39:42PM +, Wei Liu wrote:
On Tue, Dec 23, 2014 at 04:54:39PM +0800, Chao Peng wrote:
[...]
+static int libxl__psr_cmt_get_mem_bandwidth(libxl__gc *gc, uint32_t
domid,
+xc_psr_cmt_type type, uint32_t socketid, uint32_t *bandwidth)
+{
+uint64_t sample1, sample2;
+uint32_t upscaling_factor;
+int rc;
+
+rc = libxl__psr_cmt_get_l3_monitoring_data(gc, domid,
+type, socketid, sample1);
+if (rc 0)
+return ERROR_FAIL;
+
+usleep(1);
+
+rc = libxl__psr_cmt_get_l3_monitoring_data(gc, domid,
+type, socketid, sample2);
+if (rc 0)
+ return ERROR_FAIL;
+
+if (sample2 sample1) {
+ LOGE(ERROR, event counter overflowed between two samplings);
+ return ERROR_FAIL;
+}
+
What's the likelihood of counter overflows? Can we handle this more
gracefully? Say, retry (with maximum retry cap) when counter overflows?
The likelihood is very small here. Hardware guarantees the counter will
not overflow in one second even under maximum platform bandwidth conditions.
And we only sleep 0.01 second here.
I'd like to adopt your suggestion to retry another time once that happens.
But only one retry and it should correct the overflow.
Thanks,
Chao
You have no possible way of guaranteeing that the actual elapsed time
between the two samples is less than 1 second. On a very heavily loaded
system, even regular task scheduling could cause an actual elapsed time
of more than one second in that snippet of code.
Yes, it's true. So the retry cap Wei suggested will be applied.
Thanks.
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
[Xen-devel] [xen-4.2-testing test] 33184: regressions - trouble: blocked/broken/fail/pass
flight 33184 xen-4.2-testing real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/33184/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl 2 hosts-allocate running [st=running!] test-amd64-amd64-pv 2 hosts-allocate running [st=running!] test-amd64-amd64-xl-qemuu-debianhvm-amd64 3 host-install(3) broken REGR. vs. 32291 test-amd64-i386-qemut-rhel6hvm-amd 3 host-install(3) broken REGR. vs. 32291 test-amd64-i386-qemuu-freebsd10-amd64 3 host-install(3) broken REGR. vs. 32291 test-amd64-i386-qemuu-freebsd10-i386 3 host-install(3) broken REGR. vs. 32291 test-amd64-i386-xend-qemut-winxpsp3 3 host-install(3) broken REGR. vs. 32291 test-i386-i386-xl-qemut-winxpsp3 3 host-install(3) broken REGR. vs. 32291 test-amd64-amd64-xl-qemut-win7-amd64 3 host-install(3) broken REGR. vs. 32291 test-amd64-i386-xend-winxpsp3 3 host-install(3)broken REGR. vs. 32291 test-amd64-amd64-xl-win7-amd64 3 host-install(3) broken REGR. vs. 32291 test-amd64-amd64-pair3 host-install/src_host(3) broken REGR. vs. 32291 test-amd64-amd64-pair4 host-install/dst_host(4) broken REGR. vs. 32291 test-amd64-i386-pair 4 host-install/dst_host(4) broken REGR. vs. 32291 test-amd64-i386-pair 3 host-install/src_host(3) broken REGR. vs. 32291 test-amd64-i386-xl 15 guest-localmigrate/x10fail REGR. vs. 32291 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-sedf-pin 3 host-install(3) broken REGR. vs. 32291 test-amd64-i386-qemut-rhel6hvm-intel 3 host-install(3) broken like 32162 Tests which did not succeed, but are not blocking: test-amd64-amd64-rumpuserxen-amd64 1 build-check(1) blocked n/a test-i386-i386-rumpuserxen-i386 1 build-check(1) blocked n/a test-amd64-i386-rumpuserxen-i386 1 build-check(1) blocked n/a build-amd64-rumpuserxen 5 rumpuserxen-buildfail never pass build-i386-rumpuserxen5 rumpuserxen-buildfail never pass test-i386-i386-libvirt9 guest-start fail never pass test-amd64-i386-xl-qemuu-ovmf-amd64 7 debian-hvm-install fail never pass test-amd64-amd64-libvirt 9 guest-start fail never pass test-amd64-amd64-xl-qemuu-ovmf-amd64 7 debian-hvm-install fail never pass test-amd64-i386-libvirt 9 guest-start fail never pass test-amd64-amd64-xl-pcipt-intel 9 guest-start 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-amd64-xl-winxpsp3 14 guest-stop fail never pass test-i386-i386-xl-qemuu-winxpsp3 14 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop fail never pass test-i386-i386-xl-winxpsp3 14 guest-stop fail never pass test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop fail never pass version targeted for testing: xen 95af3f09eeef089e0100a8518f7ca75206e33c7c baseline version: xen 353de6b221c2d0fb59edfceb1f535357e4d84825 People who touched revisions under test: Mihai DonÈu mdo...@bitdefender.com RÄzvan Cojocaru rcojoc...@bitdefender.com jobs: build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass build-amd64-rumpuserxen fail build-i386-rumpuserxen fail test-amd64-amd64-xl broken test-amd64-i386-xl fail test-i386-i386-xlpass test-amd64-i386-rhel6hvm-amd pass test-amd64-i386-qemut-rhel6hvm-amd broken test-amd64-i386-qemuu-rhel6hvm-amd pass
[Xen-devel] xl only waits 33 seconds for ballooning to complete
Hi, In a previous post (1), I mentioned issues seen while ballooning a large amount of memory. In the current code, the ballooning process only has 33 seconds to complete, or the xl operation (i.e. domain create) will fail. When a lot of ballooning is required, or the host is very slow to balloon memory, this delay is not sufficient. The code involved is tools/libxl/xl_cmdimpl.c:freemem. This function retries 3 times, and each retry includes a 10 second delay in libxl_wait_for_free_memory and a 1 second delay in libxl_wait_for_memory_target. Is there a better approach, which would account for ballooning operations that take a much longer time to complete? The easiest option is to simply increase the retry count, but that would again leave us with a fixed window of time for an operation to complete. It seems like something that monitors the balloon process, and continues to wait if it is progressing, might be a better approach. Any ideas? Thanks, Mike 1. http://lists.xen.org/archives/html/xen-devel/2014-12/msg01443.html ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] dom0 as pvh boot problem
On Mon, Jan 5, 2015 at 3:44 AM, Jan Beulich jbeul...@suse.com wrote: Elena Ufimtseva ufimts...@gmail.com 01/02/15 7:32 PM The last successful command is the reading status register of second IOMMU unit: snip from iommu_enable_translation() in ./xen/drivers/passthrough/vtd/iommu.c 746:sts = dmar_readl(iommu-reg, DMAR_GSTS_REG); 747:dmar_writel(iommu-reg, DMAR_GCMD_REG, sts | DMA_GCMD_TE); /snip After dmar_writel for second iommu the machine hangs. That's rather odd - you say it doesn't even reach the IOMMU_WAIT_OP() right after that? Thats odd, last tests I did show that it does complete the write to the control register of the second drhd, but I cannot say if it reaches IOMMU_WAIT_OP() as right after this write it hangs. I tried to enable iommu's in reverse order with the same result. That would suggest a fault or other abnormal condition raised by the translation enabling (i.e. some problem with the page tables, albeit that should then have been a problem for the first IOMMU already). I wonder if such problem can be diagnosed without interrupt. Maybe reflected in error logging event registers? Yet an eventual fault can't be delivered at that point due to interrupts being disabled. Perhaps the VT-d maintainers (now Cc-ed) have some suggestion as to what's going on or how to diagnose. I will try to figure out if machine hangs completely at this point. Also checking the PCI topology for this machine and how it gets enumerated, maybe it will shed some light. Will report back soon. Jan -- Elena ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC 2/2] x86, vdso, pvclock: Simplify and speed up the vdso pvclock reader
On Tue, Jan 6, 2015 at 10:45 AM, Marcelo Tosatti mtosa...@redhat.com wrote:
On Tue, Jan 06, 2015 at 10:26:22AM -0800, Andy Lutomirski wrote:
On Tue, Jan 6, 2015 at 10:13 AM, Marcelo Tosatti mtosa...@redhat.com wrote:
On Tue, Jan 06, 2015 at 08:56:40AM -0800, Andy Lutomirski wrote:
On Jan 6, 2015 4:01 AM, Paolo Bonzini pbonz...@redhat.com wrote:
On 06/01/2015 09:42, Paolo Bonzini wrote:
Still confused. So we can freeze all vCPUs in the host, then
update
pvti 1, then resume vCPU 1, then update pvti 0? In that case, we
have
a problem, because vCPU 1 can observe pvti 0 mid-update, and KVM
doesn't increment the version pre-update, and we can return
completely
bogus results.
Yes.
But then the getcpu test would fail (1-0). Even if you have an ABA
situation (1-0-1), it's okay because the pvti that is fetched is the
one returned by the first getcpu.
... this case of partial update of pvti, which is caught by the version
field, if of course different from the other (extremely unlikely) that
Andy pointed out. That is when the getcpus are done on the same vCPU,
but the rdtsc is another.
That one can be fixed by rdtscp, like
do {
// get a consistent (pvti, v, tsc) tuple
do {
cpu = get_cpu();
pvti = get_pvti(cpu);
v = pvti-version ~1;
// also acts as rmb();
rdtsc_barrier();
tsc = rdtscp(cpu1);
Off-topic note: rdtscp doesn't need a barrier at all. AIUI AMD
specified it that way and both AMD and Intel implement it correctly.
(rdtsc, on the other hand, definitely needs the barrier beforehand.)
// control dependency, no need for rdtsc_barrier?
} while(cpu != cpu1);
// ... compute nanoseconds from pvti and tsc ...
rmb();
} while(v != pvti-version);
Still no good. We can migrate a bunch of times so we see the same CPU
all three times and *still* don't get a consistent read, unless we
play nasty games with lots of version checks (I have a patch for that,
but I don't like it very much). The patch is here:
https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/commit/?h=x86/vdso_paranoiaid=a69754dc5ff33f5187162b5338854ad23dd7be8d
but I don't like it.
Thus far, I've been told unambiguously that a guest can't observe pvti
while it's being written, and I think you're now telling me that this
isn't true and that a guest *can* observe pvti while it's being
written while the low bit of the version field is not set. If so,
this is rather strongly incompatible with the spec in the KVM docs.
I don't suppose that you and Marcelo could agree on what the actual
semantics that KVM provides are and could write it down in a way that
people who haven't spent a long time staring at the request code
understand? And maybe you could even fix the implementation while
you're at it if the implementation is, indeed, broken. I have ugly
patches to fix it here:
https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/commit/?h=x86/vdso_paranoiaid=3b718a050cba52563d831febc2e1ca184c02bac0
but I'm not thrilled with them.
--Andy
I suppose that separating the version write from the rest of the pvclock
structure is sufficient, as that would guarantee the writes are not
reordered even with fast string REP MOVS.
Thanks for catching this Andy!
Don't you stil need:
version++;
write the rest;
version++;
with possible smp_wmb() in there to keep the compiler from messing around?
Correct. Could just as well follow the protocol and use odd/even, which
is what your patch does.
What is the point with the new flags bit though?
To try to work around the problem on old hosts. I'm not at all
convinced that this is worthwhile or that it helps, though.
Also, if you do this, can you also make setting and clearing
STABLE_BIT properly atomic across all vCPUs? Or at least do something
like setting it last and clearing it first on vPCU 0?
If the version seqlock works properly across vCPUs, why do you need
STABLE_BIT properly atomic ?
Please define what you mean by properly atomic.
I'd like to be able to rely using vCPU 0's pvti even from other vCPUs
in the vdso if the stable bit is set. That means that the host should
avoid doing things like migrating the guest, clearing the stable bit
for vCPU 1, resuming vCPU 1, and waiting long enough to clear the
stable bit for vCPU 0 that vCPU 1's vdso code could see invalid data
and return a bad timestamp.
Maybe this scenario is impossible, but getting rid of any getcpu-like
operation in the vdso has really nice benefits. It's faster and it
lets us guarantee that the vdso's pvti data fits in a single page.
The latter means that we can easily make it work like the hpet
mapping, which gets us 32-bit support and will *finally* let us turn
off user access to the fixmap if vsyscall=none.
Re: [Xen-devel] [OSSTEST PATCH 3/4] Add nested testcase of installing L2 guest VM
-Original Message-
From: Wei Liu [mailto:wei.l...@citrix.com]
Sent: Wednesday, January 07, 2015 12:52 AM
To: Pang, LongtaoX
Cc: Wei Liu; xen-devel@lists.xen.org; ian.jack...@eu.citrix.com;
ian.campb...@citrix.com; Hu, Robert; Zheng, Di
Subject: Re: [OSSTEST PATCH 3/4] Add nested testcase of installing L2 guest VM
On Tue, Jan 06, 2015 at 03:28:43AM +, Pang, LongtaoX wrote:
-Original Message-
From: Wei Liu [mailto:wei.l...@citrix.com]
Sent: Thursday, December 11, 2014 7:44 PM
To: Pang, LongtaoX
Cc: xen-devel@lists.xen.org; ian.jack...@eu.citrix.com;
ian.campb...@citrix.com; wei.l...@citrix.com; Hu, Robert; Zheng, Di
Subject: Re: [OSSTEST PATCH 3/4] Add nested testcase of installing
L2 guest VM
On Wed, Dec 10, 2014 at 04:07:39PM +0800, longtao.pang wrote:
From: longtao.pang longtaox.p...@intel.com
This patch is used for installing L2 guest VM inside L1 guest VM.
---
sg-run-job|2 +
ts-debian-install | 166
+
2 files changed, 132 insertions(+), 36 deletions(-)
diff --git a/sg-run-job b/sg-run-job index e513bd1..85f7b22 100755
--- a/sg-run-job
+++ b/sg-run-job
@@ -292,6 +292,8 @@ proc need-hosts/test-nested {} {return host}
proc run-job/test-nested {} {
run-ts . = ts-debian-hvm-install + host + nested + nested_L1
run-ts . = ts-xen-install + host + nested + nested_build
+run-ts . = ts-debian-install + host + nested + amd64 + nested_L2
+run-ts . = ts-guest-destroy + host nested
It would also be possible to run ts-debian-hvm-install as L2. That
would suite this test case better -- it's testing nested HVM.
There's no need to remove the PV test case though.
[Pang, LongtaoX]
[Pang, LongtaoX] Thanks for checking. We used ts-debian-hvm-install
for installing L1 HVM guest via ISO Image, because we will build XEN,
XEN-Tools and dom0 kernel inside it, and then we will install L2 guest inside
L1.
But, L2 guest is just a native OS, so we think use ts-debian-install is
enough
for installing L2 and will make it easy to control.
ts-debian-install installs a L2 PV guest, which should work even without
nested
HVM enabled for your L1 HVM guest. You're testing nested HVM I think it
makes more sense to install a L2 HVM guest.
[Pang, LongtaoX] Thanks Wei, I will try to re-use the script of
ts-debian-hvm-install as L2, maybe it will make
this script become complicated. If it works, there will not be necessary to
modify and use ts-debian-install anymore.
[...]
+sub start () {
+my $cfg_xend= /etc/xen/$guesthost.cfg;
+my $cmd= toolstack()-{Command}. create .$cfg_xend;
+target_cmd_root($ho, $cmd, 30);
+my $domains = target_cmd_output_root($ho,
toolstack()-{Command}. list);
+logm(guest state is\n$domains); }
I think we already have a guest start script?
This hunk is going to break easily if we're more flexible about the
toolstack (we already have a partially working libvirt test case).
[Pang, LongtaoX] Thanks for checking, I have tried to use
ts-guest-start to start guest, but it maybe not suit for here, because some
function and parameters in the script is not necessary here, If we use the
script
we will modify it again and may impact other test jobs.
So I create a function here to start L2 guest.
Then you need to keep an eye on the ongoing work from Ian Campbell to
factor out abstraction layer of toolstack and rebase accordingly.
Wei.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 1/5] vTPM: event channel bind interdomain with para/hvm virtual machine
-Original Message- From: xen-devel-boun...@lists.xen.org [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of Samuel Thibault Sent: Wednesday, January 07, 2015 12:57 AM To: Xu, Quan Cc: Daniel De Graaf; stefano.stabell...@eu.citrix.com; xen-devel@lists.xen.org Subject: Re: [Xen-devel] [PATCH v2 1/5] vTPM: event channel bind interdomain with para/hvm virtual machine Xu, Quan, le Tue 06 Jan 2015 16:46:58 +, a écrit : QEMU is running in Dom0 as usual, so the domid is 0. One can also run the HVM QEMU inside a stubdomain. A good case, thanks Samuel. Once running the HVM QEMU inside a stubdomain, the domain type is para-virtualization(T_DOMAIN_TYPE_PV) #define T_DOMAIN_TYPE_HVM 1 #define T_DOMAIN_TYPE_PV 2 Thanks Quan Samuel ___ 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] xen compile error with CONFIG_EARLY_PRINTK=seattle option
I'm sorry, it's my bad. It was because I didn't do make clean before building with CONFIG_EARLY_PRINTK=seattle. Jintack On Tue, Jan 6, 2015 at 8:49 PM, Jintack Lim jint...@cs.columbia.edu wrote: Hi, When I compiled with CONFIG_EARLY_PRINTK=seattle option, I got an compile error. /home/soccertack/dev/xen/xen/arch/arm/built_in.o: In function `early_puts': /home/soccertack/dev/xen/xen/arch/arm/early_printk.c:22: multiple definition of `early_puts' arm64/head.o:/home/soccertack/dev/xen/xen/arch/arm/arm64/head.S:727: first defined here After I commented early_puts function out in early_printk.c, I successfully compiled and I was able to see earlyprint messages. I'm using the latest commit (36174af3fbeb1b662c0eadbfa193e77f68cc955b) and I compiled with this command. make dist-xen XEN_TARGET_ARCH=arm64 debug=y CONFIG_EARLY_PRINTK=seattle CROSS_COMPILE=aarch64-linux-gnu- Jintack ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 1/5] vTPM: event channel bind interdomain with para/hvm virtual machine
-Original Message- From: xen-devel-boun...@lists.xen.org [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of Xu, Quan Sent: Wednesday, January 07, 2015 9:45 AM To: Samuel Thibault Cc: Daniel De Graaf; xen-devel@lists.xen.org; stefano.stabell...@eu.citrix.com Subject: Re: [Xen-devel] [PATCH v2 1/5] vTPM: event channel bind interdomain with para/hvm virtual machine -Original Message- From: xen-devel-boun...@lists.xen.org [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of Samuel Thibault Sent: Wednesday, January 07, 2015 12:57 AM To: Xu, Quan Cc: Daniel De Graaf; stefano.stabell...@eu.citrix.com; xen-devel@lists.xen.org Subject: Re: [Xen-devel] [PATCH v2 1/5] vTPM: event channel bind interdomain with para/hvm virtual machine Xu, Quan, le Tue 06 Jan 2015 16:46:58 +, a écrit : QEMU is running in Dom0 as usual, so the domid is 0. One can also run the HVM QEMU inside a stubdomain. A good case, thanks Samuel. Once running the HVM QEMU inside a stubdomain, the domain type is para-virtualization(T_DOMAIN_TYPE_PV) #define T_DOMAIN_TYPE_HVM 1 #define T_DOMAIN_TYPE_PV 2 I missed this case, described by Graaf. I have not tried it. ### [...] [minios or Linux tpmfront] | QEMU stub-domain | [MMIO emulation] | Any HVM guest ### Thanks Quan Thanks Quan Samuel ___ 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 mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Xen 4.5 Development Update (GA slip by a week)
Konrad Rzeszutek Wilk writes (Re: Xen 4.5 Development Update (GA slip by a week)): On Tue, Jan 06, 2015 at 02:40:31PM +, Ian Jackson wrote: There are two remaining dates left unspecified in your mail: * When do we branch for 4.5 ? I think we should do this right away so that we can set up osstest to have a working push gate for 4.5 by the time of the release. I concur. Would you be OK doing that? OK. This will work best with coordination with all committers to avoid stuff appearing on staging after staging-4.5 is created. Um, not following you. I think we want people to put patches in staging, just not 4.5 material? Yes. What I mean is that there is a point starting RIGHT NOW when committers should be pushing NOTHING TO STAGING. Because I am about to branch staging, and any committer who pushes now doen't know whether the commits they push are going to end up in 4.5 or not. * What is the last commit deadline for 4.5 ? We need time to wait for a test push, discover a possible problem, and perhaps revert. A week would be best, but maybe a bit less How long do those 'test push' take? With a following wind 24h, but that involves some luck. I would allow at least 48h and probably more for possible infrastructure problems. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH] xen-netback: fixing the propagation of the transmit shaper timeout
From: Palik, Imre im...@amazon.de
Since e9ce7cb6b107 (xen-netback: Factor queue-specific data into queue
struct),
the transimt shaper timeout is always set to 0. The value the user sets via
xenbus is never propagated to the transmit shaper.
This patch fixes the issue.
Cc: Anthony Liguori aligu...@amazon.com
Signed-off-by: Imre Palik im...@amazon.de
---
drivers/net/xen-netback/xenbus.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c
index efbaf2a..794204e 100644
--- a/drivers/net/xen-netback/xenbus.c
+++ b/drivers/net/xen-netback/xenbus.c
@@ -737,6 +737,7 @@ static void connect(struct backend_info *be)
}
queue-remaining_credit = credit_bytes;
+ queue-credit_usec = credit_usec;
err = connect_rings(be, queue);
if (err) {
--
1.7.9.5
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen-netback: fixing the propagation of the transmit shaper timeout
On Tue, 2015-01-06 at 16:44 +0100, Imre Palik wrote: From: Palik, Imre im...@amazon.de Since e9ce7cb6b107 (xen-netback: Factor queue-specific data into queue struct), the transimt shaper timeout is always set to 0. The value the user sets via xenbus is never propagated to the transmit shaper. This patch fixes the issue. Cc: Anthony Liguori aligu...@amazon.com Signed-off-by: Imre Palik im...@amazon.de 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] [PATCH v2 3/5] vTPM: add TPM TCPA and SSDT for HVM virtual machine when vTPM is added
-Original Message-
From: xen-devel-boun...@lists.xen.org
[mailto:xen-devel-boun...@lists.xen.org] On Behalf Of Wei Liu
Sent: Monday, January 05, 2015 8:57 PM
To: Xu, Quan
Cc: wei.l...@citrix.com; ian.campb...@citrix.com;
stefano.stabell...@eu.citrix.com; ian.jack...@eu.citrix.com;
xen-devel@lists.xen.org; Jan Beulich
Subject: Re: [Xen-devel] [PATCH v2 3/5] vTPM: add TPM TCPA and SSDT for
HVM virtual machine when vTPM is added
You need to CC Jan for hvmloader changes (which I've done for you).
Thanks. Will CC Jan in v3, also I will CC Jan for SeaBios Patch..
I did not get 'Jan Beulich' with scripts/get_maintainer.pl, maybe Community
should also update it.
On Tue, Dec 30, 2014 at 11:45:14PM -0500, Quan Xu wrote:
Signed-off-by: Quan Xu quan...@intel.com
---
tools/firmware/hvmloader/acpi/build.c | 5 +++--
tools/libxl/libxl_create.c| 5 -
tools/libxl/libxl_types.idl | 1 +
tools/libxl/xl_cmdimpl.c | 2 ++
4 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/tools/firmware/hvmloader/acpi/build.c
b/tools/firmware/hvmloader/acpi/build.c
index 1431296..f2aa071 100644
--- a/tools/firmware/hvmloader/acpi/build.c
+++ b/tools/firmware/hvmloader/acpi/build.c
@@ -313,9 +313,10 @@ static int construct_secondary_tables(unsigned
long *table_ptrs,
/* TPM TCPA and SSDT. */
tis_hdr = (uint16_t *)0xFED40F00;
-if ( (tis_hdr[0] == tis_signature[0])
+if ( ((tis_hdr[0] == tis_signature[0])
(tis_hdr[1] == tis_signature[1])
- (tis_hdr[2] == tis_signature[2]) )
+ (tis_hdr[2] == tis_signature[2])) ||
+ !strncmp(xenstore_read(platform/acpi_stubdom_vtpm, 1),
+ 1, 1) )
{
ssdt = mem_alloc(sizeof(ssdt_tpm), 16);
if (!ssdt) return -1;
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 0a09925..c6f68fe 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -432,7 +432,7 @@ int libxl__domain_build(libxl__gc *gc,
vments[4] = start_time;
vments[5] = libxl__sprintf(gc, %lu.%02d,
start_time.tv_sec,(int)start_time.tv_usec/1);
-localents = libxl__calloc(gc, 9, sizeof(char *));
+localents = libxl__calloc(gc, 11, sizeof(char *));
i = 0;
localents[i++] = platform/acpi;
localents[i++] = libxl_defbool_val(info-u.hvm.acpi) ? 1 :
0; @@ -440,6 +440,9 @@ int libxl__domain_build(libxl__gc *gc,
localents[i++] = libxl_defbool_val(info-u.hvm.acpi_s3) ? 1 :
0;
localents[i++] = platform/acpi_s4;
localents[i++] = libxl_defbool_val(info-u.hvm.acpi_s4) ? 1
: 0;
+localents[i++] = platform/acpi_stubdom_vtpm;
+localents[i++] = (info-num_vtpms 0) ? 1 : 0;
+
if (info-u.hvm.mmio_hole_memkb) {
uint64_t max_ram_below_4g =
(1ULL 32) - (info-u.hvm.mmio_hole_memkb
10);
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index ca3f724..b08b974 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -379,6 +379,7 @@ libxl_domain_build_info =
Struct(domain_build_info,[
# if you set device_model you must set device_model_version too
(device_model, string),
(device_model_ssidref, uint32),
+(num_vtpms, integer),
Why is this needed? Can you not use d_config-num_vtpms? I.e. this never
differs from d_config-num_vtpms in your code below...
This parameter is for HVM_PARAM_STUBDOM_VTPM hypercall, which is deleted in v2.
I should also delete it.
I will do it in v3. Thanks..
Thanks
Quan
Wei.
(device_model_ssid_label, string),
# extra parameters pass directly to qemu, NULL terminated diff
--git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c index
3c9f146..9c43e88 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -1414,6 +1414,7 @@ static void parse_config_data(const char
*config_source,
if (!xlu_cfg_get_list(config, vtpm, vtpms, 0, 0)) {
d_config-num_vtpms = 0;
+b_info-num_vtpms = 0;
d_config-vtpms = NULL;
while ((buf = xlu_cfg_get_listitem (vtpms,
d_config-num_vtpms)) != NULL) {
libxl_device_vtpm *vtpm;
@@ -1456,6 +1457,7 @@ static void parse_config_data(const char
*config_source,
}
free(buf2);
d_config-num_vtpms++;
+b_info-num_vtpms++;
}
}
--
1.8.3.2
___
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] [xen-4.4-testing test] 33186: regressions - trouble: blocked/broken/fail/pass
flight 33186 xen-4.4-testing real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/33186/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-ovmf-amd64 3 host-install(3) broken REGR. vs. 32329 test-amd64-i386-pair 3 host-install/src_host(3) broken REGR. vs. 32329 test-amd64-i386-xl-qemut-win7-amd64 7 windows-installfail REGR. vs. 32329 Regressions which are regarded as allowable (not blocking): test-amd64-i386-pair 4 host-install/dst_host(4) broken like 32329 test-armhf-armhf-xl 3 host-install(3) broken like 32329 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 build-i386-rumpuserxen6 xen-buildfail never pass build-amd64-rumpuserxen 6 xen-buildfail never pass test-amd64-i386-libvirt 9 guest-start fail never pass test-armhf-armhf-libvirt 9 guest-start fail never pass test-amd64-amd64-libvirt 9 guest-start fail never pass test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 14 guest-stop fail never pass test-amd64-amd64-xl-win7-amd64 14 guest-stop fail never pass test-amd64-amd64-xl-winxpsp3 14 guest-stop fail never pass test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-xend-winxpsp3 17 leak-check/check fail never pass test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-i386-xend-qemut-winxpsp3 17 leak-check/checkfail never pass test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop fail never pass version targeted for testing: xen 089dd62211042011e26de1b87b558394cdfe388b baseline version: xen 7bb6b2722be1e27f99948e5c68f7f42eb23f8e53 People who touched revisions under test: Mihai DonÈu mdo...@bitdefender.com RÄzvan Cojocaru rcojoc...@bitdefender.com jobs: build-amd64-xend pass build-i386-xend pass 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 fail build-i386-rumpuserxen fail test-amd64-amd64-xl pass test-armhf-armhf-xl broken test-amd64-i386-xl pass 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 broken test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-rumpuserxen-amd64 blocked test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail
Re: [Xen-devel] [RFC 2/2] x86, vdso, pvclock: Simplify and speed up the vdso pvclock reader
On 06/01/2015 17:56, Andy Lutomirski wrote: Still no good. We can migrate a bunch of times so we see the same CPU all three times There are no three times. The CPU you see here: // ... compute nanoseconds from pvti and tsc ... rmb(); } while(v != pvti-version); is the same you read here: cpu = get_cpu(); The algorithm is: 1) get a consistent (cpu, version, tsc) 1.a) get cpu 1.b) get pvti[cpu]-version, ignoring low bit 1.c) get (tsc, cpu) 1.d) if cpu from 1.a and 1.c do not match, loop 1.e) if pvti[cpu] was being updated, we'll loop later 2) compute nanoseconds from pvti[cpu] and tsc 3) if pvti[cpu] changed under our feet during (2), i.e. version doesn't match, retry. As long as the CPU is consistent between get_cpu() and rdtscp(), there is no problem with migration, because pvti is always accessed for that one CPU. If there were any problem, it would be caught by the version check. Writing it down with two nested do...whiles makes it clearer IMHO. and *still* don't get a consistent read, unless we play nasty games with lots of version checks (I have a patch for that, but I don't like it very much). The patch is here: https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/commit/?h=x86/vdso_paranoiaid=a69754dc5ff33f5187162b5338854ad23dd7be8d but I don't like it. Thus far, I've been told unambiguously that a guest can't observe pvti while it's being written, and I think you're now telling me that this isn't true and that a guest *can* observe pvti while it's being written while the low bit of the version field is not set. If so, this is rather strongly incompatible with the spec in the KVM docs. Where am I saying that? Paolo ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
