[Xen-devel] [qemu-upstream-4.5-testing test] 50402: regressions - FAIL
flight 50402 qemu-upstream-4.5-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/50402/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-pair 21 guest-migrate/src_host/dst_host fail REGR. vs. 36517 Tests which are failing intermittently (not blocking): test-amd64-i386-freebsd10-i386 14 guest-localmigrate/x10 fail in 50313 pass in 50283 test-amd64-amd64-libvirt 9 guest-startfail in 50313 pass in 50402 test-amd64-amd64-xl-win7-amd64 15 guest-localmigrate/x10 fail in 50364 pass in 50383 test-amd64-i386-freebsd10-i386 13 guest-localmigrate fail in 50364 pass in 50402 test-amd64-amd64-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail in 50364 pass in 50402 test-armhf-armhf-libvirt 11 guest-startfail in 50364 pass in 50402 test-amd64-amd64-xl-qemuu-winxpsp3 15 guest-localmigrate/x10 fail in 50383 pass in 50402 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-localmigrate.2 fail in 50383 pass in 50402 test-amd64-i386-freebsd10-i386 15 guest-localmigrate.2 fail pass in 50313 test-amd64-i386-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail pass in 50364 test-amd64-i386-freebsd10-amd64 13 guest-localmigrate fail pass in 50364 test-amd64-i386-xl-win7-amd64 15 guest-localmigrate/x10 fail pass in 50383 test-amd64-amd64-xl-win7-amd64 12 guest-localmigratefail pass in 50383 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-arndale 18 capture-logs(18) broken in 50364 blocked in 36517 test-armhf-armhf-xl-sedf 18 capture-logs(18) broken in 50364 blocked in 36517 test-armhf-armhf-xl-cubietruck 18 capture-logs(18) broken in 50364 blocked in 36517 test-armhf-armhf-xl 18 capture-logs(18) broken in 50364 blocked in 36517 test-armhf-armhf-xl-sedf-pin 18 capture-logs(18) broken in 50364 blocked in 36517 test-armhf-armhf-xl-multivcpu 18 capture-logs(18) broken in 50364 blocked in 36517 test-armhf-armhf-xl-credit2 7 capture-logs(7) broken in 50364 blocked in 36517 Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 12 capture-logs(12)broken in 50364 never pass test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop fail in 50313 never pass test-amd64-i386-xl-win7-amd64 14 guest-stop fail in 50313 never pass test-amd64-amd64-xl-win7-amd64 14 guest-stop fail in 50313 never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-sedf 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-amd64-amd64-xl-qemuu-winxpsp3 16 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass test-amd64-i386-xl-qemut-winxpsp3 16 guest-stopfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-amd64-i386-xl-qemut-winxpsp3-vcpus1 16 guest-stop fail never pass test-armhf-armhf-xl-sedf-pin 12 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-amd64-i386-xl-winxpsp3 16 guest-stop fail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-xl-qemuu-winxpsp3 16 guest-stopfail never pass test-armhf-armhf-xl-credit2 6 xen-boot fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 16 guest-stop fail never pass test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 16 guest-stop fail never pass test-amd64-amd64-xl-qemut-winxpsp3 16 guest-stop fail never pass test-amd64-amd64-xl-winxpsp3 16 guest-stop fail never pass version targeted for testing: qemuuc9ac5f816bf3a8b56f836b078711dcef6e5c90b8 baseline version: qemuu0b8fb1ec3d666d1eb8bbff56c76c5e6daa2789e4 People who touched revisions under test: Ian Campbell ian.campb...@citrix.com Jan Beulich jbeul...@suse.com jobs: build-amd64 pass build-armhf pass build-i386 pass
Re: [Xen-devel] [PATCH 2/3] xen/x86: Use real assert frames for ASSERT_INTERRUPTS_{EN, DIS}ABLED
On 09.04.15 at 22:06, andrew.coop...@citrix.com wrote: @@ -26,18 +27,24 @@ #endif #ifndef NDEBUG -#define ASSERT_INTERRUPT_STATUS(x) \ -pushf; \ -testb $X86_EFLAGS_IF8,1(%rsp);\ -j##x 1f; \ -ud2a; \ -1: addq $8,%rsp; +#define ASSERT_INTERRUPTS_ENABLED \ +pushf; \ +testb $X86_EFLAGS_IF8,1(%rsp);\ +jnz 1f; \ +ASSERT_FAILED(INTERRUPTS ENABLED);\ +1: addq $8,%rsp; + +#define ASSERT_INTERRUPTS_DISABLED \ +pushf; \ +testb $X86_EFLAGS_IF8,1(%rsp);\ +jz1f; \ +ASSERT_FAILED(INTERRUPTS DISABLED); \ +1: addq $8,%rsp; #else -#define ASSERT_INTERRUPT_STATUS(x) +#define ASSERT_INTERRUPTS_ENABLED +#define ASSERT_INTERRUPTS_DISABLED #endif -#define ASSERT_INTERRUPTS_ENABLED ASSERT_INTERRUPT_STATUS(nz) -#define ASSERT_INTERRUPTS_DISABLED ASSERT_INTERRUPT_STATUS(z) So what's the point of deleting these and duplicating most of the macro definition text above? Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 0/2] vtpm deep quote in locality 0
Changes from v1, suggested by Daniel: - flags parameter is now mandatory - updated documentation about externData calculation - constant size for externData structure, perform SHA1 on empty string if requested parameter is NULL - return error if invalid bit is set in flags - added VTPM_QUOTE_FLAGS_GROUP_PUBKEY flag Right now, deep quote functionality is enabled just when vtpm manager is started with locality=2. This requirement is enforced by the current implementation which uses PCRs that can be reset in locality 2: 20,21,22,23. Since some TPM chips do not enable access to other locality than 0 this patch enables the deep quote functionality for vtpm manager started with locality=0. The patches are based on a suggestion given by Daniel De Graaf in another thread on the list: - Add a field to the request - extraInfoFlags - Compute externData = SHA1 ( extraInfoFlags requestData [SHA1 ( [SHA1 (UUIDs if requested)] [SHA1 (vTPM measurements if requested)] [SHA1 (vTPM group update policy if requested)] [SHA1 (vTPM group public key if requested)] ) if flags !=0 ] ) - Perform deep quotes using the above externData value instead of the value provided by the vTPM. Embedding additional data in externData is equivalently secure as extending it into PCRs. This change also has the benefit of increasing the flexibility of the request. It is simple to define additional flags and add data to the hash if needed. Emil Condrea (2): vtpm: deep quote flags vtpmmgr: execute deep quote in locality 0 stubdom/Makefile| 1 + stubdom/vtpm-deepquote-anyloc.patch | 127 stubdom/vtpm/vtpm_cmd.c | 13 ++-- stubdom/vtpmmgr/marshal.h | 1 + stubdom/vtpmmgr/mgmt_authority.c| 91 +++--- stubdom/vtpmmgr/mgmt_authority.h| 2 +- stubdom/vtpmmgr/vtpm_cmd_handler.c | 7 +- stubdom/vtpmmgr/vtpm_manager.h | 27 +++- 8 files changed, 250 insertions(+), 19 deletions(-) create mode 100644 stubdom/vtpm-deepquote-anyloc.patch -- 2.1.0 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 1/2] vtpm: deep quote flags
Currently, the flags are not interpreted by vTPM. They are just
packed and sent to vtpmmgr.
Signed-off-by: Emil Condrea emilcond...@gmail.com
---
stubdom/Makefile| 1 +
stubdom/vtpm-deepquote-anyloc.patch | 127
stubdom/vtpm/vtpm_cmd.c | 13 ++--
3 files changed, 135 insertions(+), 6 deletions(-)
create mode 100644 stubdom/vtpm-deepquote-anyloc.patch
diff --git a/stubdom/Makefile b/stubdom/Makefile
index 8fb885a..c135334 100644
--- a/stubdom/Makefile
+++ b/stubdom/Makefile
@@ -211,6 +211,7 @@ tpm_emulator-$(XEN_TARGET_ARCH):
tpm_emulator-$(TPMEMU_VERSION).tar.gz
patch -d $@ -p1 vtpm-locality.patch
patch -d $@ -p1 vtpm-parent-sign-ek.patch
patch -d $@ -p1 vtpm-deepquote.patch
+ patch -d $@ -p1 vtpm-deepquote-anyloc.patch
patch -d $@ -p1 vtpm-cmake-Wextra.patch
mkdir $@/build
cd $@/build; CC=${CC} $(CMAKE) .. -DCMAKE_C_FLAGS:STRING=-std=c99
-DTPM_NO_EXTERN $(TARGET_CPPFLAGS) $(TARGET_CFLAGS)
-Wno-declaration-after-statement
diff --git a/stubdom/vtpm-deepquote-anyloc.patch
b/stubdom/vtpm-deepquote-anyloc.patch
new file mode 100644
index 000..13b00d8
--- /dev/null
+++ b/stubdom/vtpm-deepquote-anyloc.patch
@@ -0,0 +1,127 @@
+diff --git a/tpm/tpm_cmd_handler.c b/tpm/tpm_cmd_handler.c
+index 69511d1..7545d51 100644
+--- a/tpm/tpm_cmd_handler.c
b/tpm/tpm_cmd_handler.c
+@@ -3347,12 +3347,13 @@ static TPM_RESULT execute_TPM_DeepQuote(TPM_REQUEST
*req, TPM_RESPONSE *rsp)
+ {
+ TPM_NONCE nonce;
+ TPM_RESULT res;
+- UINT32 sigSize;
+- BYTE *sig;
++ UINT32 quote_blob_size;
++ BYTE *quote_blob;
+ BYTE *ptr;
+ UINT32 len;
+ TPM_PCR_SELECTION myPCR;
+ TPM_PCR_SELECTION ptPCR;
++ UINT32 extraInfoFlags = 0;
+
+ tpm_compute_in_param_digest(req);
+
+@@ -3361,17 +3362,19 @@ static TPM_RESULT execute_TPM_DeepQuote(TPM_REQUEST
*req, TPM_RESPONSE *rsp)
+ if (tpm_unmarshal_TPM_NONCE(ptr, len, nonce)
+ || tpm_unmarshal_TPM_PCR_SELECTION(ptr, len, myPCR)
+ || tpm_unmarshal_TPM_PCR_SELECTION(ptr, len, ptPCR)
++ || tpm_unmarshal_TPM_DEEP_QUOTE_INFO(ptr, len,
extraInfoFlags))
+ || len != 0) return TPM_BAD_PARAMETER;
+
+- res = TPM_DeepQuote(nonce, myPCR, ptPCR, req-auth1, sigSize,
sig);
++ res = TPM_DeepQuote(nonce, myPCR, ptPCR, req-auth1, extraInfoFlags,
++ quote_blob_size, quote_blob);
+ if (res != TPM_SUCCESS) return res;
+- rsp-paramSize = len = sigSize;
++ rsp-paramSize = len = quote_blob_size;
+ rsp-param = ptr = tpm_malloc(len);
+- if (ptr == NULL || tpm_marshal_BLOB(ptr, len, sig, sigSize)) {
++ if (ptr == NULL || tpm_marshal_BLOB(ptr, len, quote_blob,
quote_blob_size)) {
+ tpm_free(rsp-param);
+ res = TPM_FAIL;
+ }
+- tpm_free(sig);
++ tpm_free(quote_blob);
+
+ return res;
+ }
+diff --git a/tpm/tpm_commands.h b/tpm/tpm_commands.h
+index 328d1be..a56dd5f 100644
+--- a/tpm/tpm_commands.h
b/tpm/tpm_commands.h
+@@ -3077,6 +3077,7 @@ TPM_RESULT TPM_ParentSignEK(
+ * @myPCR: [in] PCR selection for the virtual TPM
+ * @ptPCR: [in] PCR selection for the hardware TPM
+ * @auth1: [in, out] Authorization protocol parameters
++ * @extraInfoFlags [in] Flags for including, kernel hash, group info, etc
+ * @sigSize: [out] The length of the returned digital signature
+ * @sig: [out] The resulting digital signature and PCR values
+ * Returns: TPM_SUCCESS on success, a TPM error code otherwise.
+@@ -3086,6 +3087,7 @@ TPM_RESULT TPM_DeepQuote(
+ TPM_PCR_SELECTION *myPCR,
+ TPM_PCR_SELECTION *ptPCR,
+ TPM_AUTH *auth1,
++ UINT32 extraInfoFlags,
+ UINT32 *sigSize,
+ BYTE **sig
+ );
+diff --git a/tpm/tpm_credentials.c b/tpm/tpm_credentials.c
+index c0d62e7..6586c22 100644
+--- a/tpm/tpm_credentials.c
b/tpm/tpm_credentials.c
+@@ -183,7 +183,8 @@ TPM_RESULT TPM_OwnerReadInternalPub(TPM_KEY_HANDLE
keyHandle, TPM_AUTH *auth1,
+
+ int endorsementKeyFresh = 0;
+
+-TPM_RESULT VTPM_GetParentQuote(TPM_DIGEST* data, TPM_PCR_SELECTION *sel,
UINT32 *sigSize, BYTE **sig);
++TPM_RESULT VTPM_GetParentQuote(TPM_NONCE *data, TPM_PCR_SELECTION *sel,
++ UINT32 extraInfoFlags, UINT32 *sigSize, BYTE
**sig);
+
+ TPM_RESULT TPM_ParentSignEK(TPM_NONCE *externalData, TPM_PCR_SELECTION *sel,
+ TPM_AUTH *auth1, UINT32 *sigSize, BYTE **sig)
+@@ -191,7 +192,7 @@ TPM_RESULT TPM_ParentSignEK(TPM_NONCE *externalData,
TPM_PCR_SELECTION *sel,
+ TPM_PUBKEY pubKey;
+ TPM_RESULT res;
+ TPM_DIGEST hres;
+-
++ UINT32 extraInfoFlags = 0;
+ info(TPM_ParentSignEK());
+
+ res = tpm_verify_auth(auth1, tpmData.permanent.data.ownerAuth,
TPM_KH_OWNER);
+@@ -206,7 +207,7 @@ TPM_RESULT TPM_ParentSignEK(TPM_NONCE *externalData,
TPM_PCR_SELECTION *sel,
+ res =
Re: [Xen-devel] tools/libxl - Async Task Cancellation Query
Hi Ian, Any thoughts on this below? Regards, Koushik Chakravarty Mobile - +91-9663396424 -Original Message- From: Koushik Chakravarty Sent: Wednesday, April 8, 2015 5:44 PM To: Ian Jackson Cc: Euan Harris; 'xen-de...@lists.xensource.com' Subject: RE: tools/libxl - Async Task Cancellation Query Thanks Ian for the answers. I have a follow - up on the below: Can I suggest adding a unique private 'id' field to the libxl_asyncop_how structure, that will be populated by AO_CREATE? This will help finding the matching corresponding libxl_ao from the ctx-aos_inprogress in libxl_ao_cancel() quicker by looking for search-id == libxl_asyncop_how-id. That would require the caller to preserve the ao_how which seems awkward to me. Also, allocating these ids presents some difficulties. I think it is better to allow the caller to identify aos. When you say - That would require the caller to preserve the ao_how which seems awkward to me - whom do you refer as the caller? From what I picked up, the libxl_ao_cancel() API is passed with the ao_how. The libxl_ao_cancel then looks into the ctx-aos_inprogress list to find the ao that matches the ao_how. So what I was suggesting was that if the ao_how was allotted an 'id' from the original libxl api call (done using a counter increment from the global libxl ctx with a lock held), and the same id was saved in the ao entry in ctx-aos_inprogress, then searching/matching them in libxl_ao_cancel() would have been a little faster. Of course, the assumption here is that the caller keeps the ao_how struct and uses that to call libxl_ao_cancel() - but I see that is already the case. Let me know if I am not being very clear. Regards, Koushik Chakravarty Mobile - +91-9663396424 -Original Message- From: Ian Jackson [mailto:ian.jack...@eu.citrix.com] Sent: Wednesday, April 8, 2015 4:52 PM To: Koushik Chakravarty Cc: Euan Harris; 'xen-de...@lists.xensource.com' Subject: Re: tools/libxl - Async Task Cancellation Query Koushik Chakravarty writes (tools/libxl - Async Task Cancellation Query): I am currently looking into the asynchronous task cancellation in libxl and have a few very specific queries, if you could answer. Sure. Thanks for what has evidently been a careful review of the code. 1.In libxl_domain_resume(),why is libxl_ao_complete called before AO_INPROGRESS? I was going to refer you to the internal API documentation, but I find that it doesn't describe this situation. I have drafted a patch to the documentation which I hope will answer this question. I'll send it as a followup to this mail. 2.In libxl_ao_cancel() - the function goes through the ctx-aos_inprogress and tries to find a suitable libxl_ao that matches the input libxl_asyncop_how. It does so, by a few 'if' checks. Regarding this - a.Where does the libxl__ao get inserted to the ctx-aos_inprogress? I could not find that somehow - sorry if I overlooked. Thank you again for your review. I think you have spotted a bug. I will send a followup patch, again as a followup to this mail. b.Can I suggest adding a unique private 'id' field to the libxl_asyncop_how structure, that will be populated by AO_CREATE? This will help finding the matching corresponding libxl_ao from the ctx-aos_inprogress in libxl_ao_cancel() quicker by looking for search-id == libxl_asyncop_how-id. That would require the caller to preserve the ao_how which seems awkward to me. Also, allocating these ids presents some difficulties. I think it is better to allow the caller to identify aos. 3.In libxl_device_vkb_add(), shouldn't the function invoke libxl__ao_abort in the error path? I think this will be answered by my documentation patch. But, to summarise, the codepaths: assert(rc); libxl__ao_complete(egc, ao, rc); return AO_INPROGRESS; and assert(rc); return AO_ABORT(rc); are equivalent. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/1] xc_domain_restore: Allow QEMU to increase memory
On 04/14/2015 05:28 PM, Andrew Cooper wrote: On 14/04/15 10:22, Hongyang Yang wrote: On 04/14/2015 04:53 PM, Andrew Cooper wrote: On 14/04/15 00:51, Don Slutz wrote: On 04/13/15 12:25, Andrew Cooper wrote: On 13/04/15 17:09, Don Slutz wrote: If QEMU has called on xc_domain_setmaxmem to add more memory for option ROMs, domain restore needs to also increase the memory. Signed-off-by: Don Slutz dsl...@verizon.com hvmloader has no interaction with xc_domain_restore(). I did not mean to imply that it did. Somehow I lost the fact that this is a bug in master: [root@dcs-xen-52 don]# xl cre -p /home/don/e1000x8.xfg Parsing config from /home/don/e1000x8.xfg got a tsc mode string: native_paravirt [root@dcs-xen-52 don]# xl save e1000x8 e1000x8.save Saving to e1000x8.save new xl format (info 0x1/0x0/3506) xc: Saving memory: iter 0 (last sent 0 skipped 0): 1044481/1044481 100% [root@dcs-xen-52 don]# xl restore e1000x8.save Loading new save file e1000x8.save (new xl fmt info 0x1/0x0/3506) Savefile contains xl domain config in JSON format Parsing config from saved xc: error: Failed to allocate memory for batch.!: Internal error libxl: error: libxl_create.c:1057:libxl__xc_domain_restore_done: restoring domain: Cannot allocate memory libxl: error: libxl_create.c:1129:domcreate_rebuild_done: cannot (re-)build domain: -3 libxl: error: libxl.c:1576:libxl__destroy_domid: non-existant domain 2 libxl: error: libxl.c:1540:domain_destroy_callback: unable to destroy guest with domid 2 libxl: error: libxl_create.c:1490:domcreate_destruction_cb: unable to destroy domain 2 following failed creation [root@dcs-xen-52 don]# The hvmloader part turns out to be a warning message that is ok to ignore. However xl save followed by xl restore is currently broken without some fix. It is xl's job to propagate the current memory as part of migration. If qemu has had to bump it up, this should be reflected in the domain config file. Not at all sure how QEMU (either in dom0 or a driver domain) is expected to change a file (the domain config file). My guess is that you are saying that xl save (before xc_domain_save) is the correct place to record (or add extra info). However it looks to me that all the data needed is in the save file, but I could be wrong. The page data is correctly saved into the save file (migration stream). However when the new domain is created, it's size is wrong. You cannot adjust any of the config info to fix the size, because the option ROM space to reserve is not an existing config option. So if I am following you correctly, libxl needs to add and process more info to handle this case. The migration path should not be hacked up to fix a higher level toolstack bug. I do not see how QEMU is part of the higher level toolstack. If you mean xl vs xc, then I can see xl save some how doing the work. This patch works for me, but I am happy to explore other ways to fix this bug. If I understand correctly, the steps are this: * 'xl create' makes a VM of size $FOO * qemu bumps the size to $FOO+$N * 'xl save' writes $FOO+$N of page data, but the xl config file at the start of the image still says $FOO * 'xl restore' creates a vm of size $FOO, then instructs xc_domain_restore() to put $FOO+$N pages into it. I would argue first, that qemu should not play in this area to start with. However, the real bug here is that the domain configuration written by xl save is inaccurate. There's a case like COLO: 1. Both Primary/Secondary VM are created first with the same config file which makes a VM of size $FOO 2. qemu bumps the size to $FOO+$N 3. 'save' writes $FOO+$N of page data 4. 'restore' put $FOO+$N pages into $FOO pages which will cause error Even if you fix the configuration, the bug still exists because the config only been transferred from Primary to Secondary once at the very beginning when you execute 'xl remus' command. The problem is how to let the secondary (restore) side knows the size change? Through a migration command(which is easier in v2 migration) or some other solution? Form this point of view, I think Don's solution is one way to solve the problem. Funny you should ask that. Migrationv2 for libxl moves the JSON config blob into the libxl stream, rather than being a singleshot action at the very start. From that point, it becomes plausible to send a new JSON blob when an update on the source side occurs. That should solve the problem, but Migrationv2 for libxl won't be in upstream for the moment, the bug still exists, is there a way to solve the problem now under v1 migration? However, I am still firmly of the opinion that is an xl/libxl bug to be fixed at that level, not hacked around in the restore code. ~Andrew . -- Thanks, Yang. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] XSA120 follows to the Linux kernel.
On 10.04.15 at 16:37, david.vra...@citrix.com wrote: On 03/04/15 15:28, Konrad Rzeszutek Wilk wrote: Hey David and Boris, Please see the two patches - the first one fixes an situation that the original XSA-120 patch hadn't considered. The second patch is more of just a cleanup. Can be 4.1 material. Applied both to devel/for-linus-4.1 since 4.0 is imminent (possibly), thanks. And considering Sander's bisection result posted yesterday (plus the - afaict - still unaddressed question raised by IanC regarding the correctness wrt to bits other than 0 and 1) I suppose you dropped them again? Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [libvirt] [libvirt test] 50401: regressions - FAIL
On Tue, Apr 14, 2015 at 10:33:45AM +0100, Ian Campbell wrote: On Tue, 2015-04-14 at 02:27 +, osstest service user wrote: flight 50401 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/50401/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf-libvirt 5 libvirt-build fail REGR. vs. 50368 [...] Per http://logs.test-lab.xenproject.org/osstest/logs/50401/build-armhf-libvirt/5.ts-libvirt-build.log this is: qemu/qemu_driver.c: In function 'qemuDomainAddCgroupForThread': qemu/qemu_driver.c:4641:34: error: declaration of 'index' shadows a global declaration [-Werror=shadow] qemu/qemu_driver.c: In function 'qemuDomainHotplugAddPin': qemu/qemu_driver.c:4674:29: error: declaration of 'index' shadows a global declaration [-Werror=shadow] qemu/qemu_driver.c: In function 'qemuDomainHotplugPinThread': qemu/qemu_driver.c:4702:32: error: declaration of 'index' shadows a global declaration [-Werror=shadow] qemu/qemu_driver.c: In function 'qemuDomainDelCgroupForThread': qemu/qemu_driver.c:4733:34: error: declaration of 'index' shadows a global declaration [-Werror=shadow] cc1: all warnings being treated as errors This seems to be a general issue unrelated to Xen. version targeted for testing: libvirt b487bb810ec95df862e7e80468c8e861ed80b0cb baseline version: libvirt 225aa80246d5e4a9e3a16ebd4c482525045da3db After a quick glance I don't see a fix post-b487bb810ec9 either in master or on the libvirt list. Looking at the range under test it looks like one or more of John's changes is adding parameters called index, shadowing index(3) from strings.h. Yeah, we've had this problem several times before - we usually just do a s/index/idx/ or similar to address it. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] VTd/dmar: Tweak how the DMAR table is clobbered
On 10.04.15 at 11:08, andrew.coop...@citrix.com wrote: On 10/04/15 02:23, Tian, Kevin wrote: From: Andrew Cooper [mailto:andrew.coop...@citrix.com] Sent: Thursday, April 09, 2015 3:45 AM Intead of clobbering DMAR - XMAR and back, clobber to RMAD instead. This means that changing the signature does not alter the checksum, which allows the clobbering/unclobbering to be peformed atomically and idempotently, which is an advantage on the kexec path which can reenter acpi_dmar_reinstate(). Signed-off-by: Andrew Cooper andrew.coop...@citrix.com CC: Yang Zhang yang.z.zh...@intel.com CC: Kevin Tian kevin.t...@intel.com Acked-by: Kevin Tian kevin.t...@intel.com and curious do you observe a real atomic issue in kexec or just catch this potential issue when reading code? :-) I have run over it once in the past, but mainly it is one small thing on a very long list of tweaks to make the crash path for reliable. As indicated in the other thread, I think the best direction moving forwards is to see about positively preventing dom0 having access, rather than simply hiding the table, but that is a job for another time. And possibly not doable, as this might crash Dom0. What made me wonder for a very long time though is why similar clobbering isn't needed for AMD. In any event, David's point of the now chosen signature perhaps posing a higher risk of colliding with a real table is an issue that shouldn't have been discarded before committing. Unless Kevin or Yang object, I'd therefore suggest reverting the change. Once we determined why VT-d needs what AMD Vi doesn't need, and once we settled on the risk of name collision (perhaps using an underscore prefixed name would further reduce this risk), we could then do this another way (zap the table from XSDT/RSDT instead?), or leave it as it was without the change. (Apart from the above I also don't really see why RMAD was chosen - this doesn't really resemble anything similar to DMAR except for using the same letters. If at least it had been the properly reversed string ...) Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RFC] xen/pvh: use a custom IO bitmap for PVH hardware domains
On 08.04.15 at 14:57, roger@citrix.com wrote:
Since a PVH hardware domain has access to the physical hardware create a
custom more permissive IO bitmap. The permissions set on the bitmap are
populated based on the contents of the ioports rangeset.
Also add the IO ports of the serial console used by Xen to the list of not
accessible IO ports.
So why is what ns16550_endboot() does not sufficient?
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -82,6 +82,10 @@ struct hvm_function_table hvm_funcs __read_mostly;
unsigned long __attribute__ ((__section__ (.bss.page_aligned)))
hvm_io_bitmap[3*PAGE_SIZE/BYTES_PER_LONG];
+/* I/O permission bitmap for HVM hardware domain */
+unsigned long __attribute__ ((__section__ (.bss.page_aligned)))
+hvm_hw_io_bitmap[3*PAGE_SIZE/BYTES_PER_LONG];
This should be allocated memory, as it's needed only in the PVH
Dom0 case.
--- a/xen/arch/x86/hvm/svm/vmcb.c
+++ b/xen/arch/x86/hvm/svm/vmcb.c
@@ -72,6 +72,7 @@ static int construct_vmcb(struct vcpu *v)
{
struct arch_svm_struct *arch_svm = v-arch.hvm_svm;
struct vmcb_struct *vmcb = arch_svm-vmcb;
+struct domain *d = v-domain;
I don't see the value of this variable.
--- a/xen/arch/x86/hvm/vmx/vmcs.c
+++ b/xen/arch/x86/hvm/vmx/vmcs.c
@@ -986,8 +986,10 @@ static int construct_vmcs(struct vcpu *v)
}
/* I/O access bitmap. */
-__vmwrite(IO_BITMAP_A, virt_to_maddr((char *)hvm_io_bitmap + 0));
-__vmwrite(IO_BITMAP_B, virt_to_maddr((char *)hvm_io_bitmap + PAGE_SIZE));
+__vmwrite(IO_BITMAP_A,
+ virt_to_maddr((char *)d-arch.hvm_domain.io_bitmap + 0));
+__vmwrite(IO_BITMAP_B,
+ virt_to_maddr((char *)d-arch.hvm_domain.io_bitmap +
PAGE_SIZE));
Please drop the bogus cast and pointless addition of zero from the
first of these. I'd prefer it to be done without cast on the second one
too.
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -3118,6 +3118,7 @@ void vmx_vmexit_handler(struct cpu_user_regs *regs)
uint16_t port = (exit_qualification 16) 0x;
int bytes = (exit_qualification 0x07) + 1;
int dir = (exit_qualification 0x08) ? IOREQ_READ : IOREQ_WRITE;
+
if ( handle_pio(port, bytes, dir) )
update_guest_eip(); /* Safe: IN, OUT */
}
This is a valid style correction, but being the only change to this file
it doesn't belong here.
--- a/xen/include/asm-x86/hvm/hvm.h
+++ b/xen/include/asm-x86/hvm/hvm.h
@@ -213,6 +213,7 @@ extern struct hvm_function_table hvm_funcs;
extern bool_t hvm_enabled;
extern bool_t cpu_has_lmsl;
extern s8 hvm_port80_allowed;
+extern unsigned long hvm_hw_io_bitmap[];
This should be declared next to hvm_io_bitmap[] (I don't mind if
you move its declaration here).
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] about xenoprof
Hi, everyone: There is no patch for OProfile above 0.9.5 in website http://xenoprof.sourceforge.net/ . why? Does it mean we don’t need the patch for OProfile user level tools if we use 0.9.5 above ? ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 0/3] xen: arm: Parse PCI DT nodes' ranges and interrupt-map
On Thu, 2015-03-12 at 17:16 +, Ian Campbell wrote:
This series adds parsing of the DT ranges and interrupt-map properties
for PCI devices, these contain the MMIOs and IRQs used by children on
the bus. This replaces the specific mapping stuff on xgene.
Somehow I managed to completely miss sending out the first patch here
(thanks Chen Baozi!)...
This should be inserted at the head of the series.
From d0a024dd49ca6f67b0ec0342fd2d819b750a52a4 Mon Sep 17 00:00:00 2001
From: Ian Campbell ian.campb...@citrix.com
Date: Fri, 6 Mar 2015 11:13:30 +
Subject: [PATCH] xen: dt: add dt_translate_address to translate a raw address
A future patch is going to want to translate an address which is not
part of the reg property so the existing dt_device_get_address is not
suitable.
This is the same function as Linux's of_translate_address but with the
names changed to fit our context and the dev parameter constified.
Signed-off-by: Ian Campbell ian.campb...@citrix.com
---
xen/common/device_tree.c |5 +
xen/include/xen/device_tree.h |2 ++
2 files changed, 7 insertions(+)
diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
index d1c716f..89491b2 100644
--- a/xen/common/device_tree.c
+++ b/xen/common/device_tree.c
@@ -682,6 +682,11 @@ bail:
return result;
}
+u64 dt_translate_address(const struct dt_device_node *dev, const __be32
*in_addr)
+{
+return __dt_translate_address(dev, in_addr, ranges);
+}
+
/* dt_device_address - Translate device tree address and return it */
int dt_device_get_address(const struct dt_device_node *dev, int index,
u64 *addr, u64 *size)
diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
index c8a0375..b7455cd 100644
--- a/xen/include/xen/device_tree.h
+++ b/xen/include/xen/device_tree.h
@@ -464,6 +464,8 @@ struct dt_device_node *dt_find_node_by_path(const char
*path);
*/
const struct dt_device_node *dt_get_parent(const struct dt_device_node *node);
+u64 dt_translate_address(const struct dt_device_node *np, const __be32 *addr);
+
/**
* dt_device_get_address - Resolve an address for a device
* @device: the device whose address is to be resolved
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 0/2] Re-factoring passthrough/pci.c and adding place-holder code for ARM/PCI
On 13.04.15 at 09:37, mja...@caviumnetworks.com wrote: Xen currently does not have PCI support for ARM builds. This patch set makes the code compilable for ARM PCI and adds places-holder code which would be replaced with PCI pass-through support patch series. Re-factor MSI Handling - There is a some x86 specific code which is found in common code: xen/drivers/passthrough/pci.c which needs to be re factored. MSI/X are configured and handled by dom0 or domU code on ARM64 and is not required to be part of common code. However there are functions which are used as part of common code and calls to these functions cannot be easily re factored like pci_cleanup_msi. I can only second Julien's reply here: Without explanation (here, not by reference to some past discussion) how you envision MSI to work securely when you leave control of it to DomU-s there's very little point in separating out MSI from PCI code. Also please make sure you Cc all involved maintainers especially on non- trivial and potentially controversial patches like these. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [libvirt test] 50401: regressions - FAIL
On Tue, 2015-04-14 at 02:27 +, osstest service user wrote: flight 50401 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/50401/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf-libvirt 5 libvirt-build fail REGR. vs. 50368 [...] Per http://logs.test-lab.xenproject.org/osstest/logs/50401/build-armhf-libvirt/5.ts-libvirt-build.log this is: qemu/qemu_driver.c: In function 'qemuDomainAddCgroupForThread': qemu/qemu_driver.c:4641:34: error: declaration of 'index' shadows a global declaration [-Werror=shadow] qemu/qemu_driver.c: In function 'qemuDomainHotplugAddPin': qemu/qemu_driver.c:4674:29: error: declaration of 'index' shadows a global declaration [-Werror=shadow] qemu/qemu_driver.c: In function 'qemuDomainHotplugPinThread': qemu/qemu_driver.c:4702:32: error: declaration of 'index' shadows a global declaration [-Werror=shadow] qemu/qemu_driver.c: In function 'qemuDomainDelCgroupForThread': qemu/qemu_driver.c:4733:34: error: declaration of 'index' shadows a global declaration [-Werror=shadow] cc1: all warnings being treated as errors This seems to be a general issue unrelated to Xen. version targeted for testing: libvirt b487bb810ec95df862e7e80468c8e861ed80b0cb baseline version: libvirt 225aa80246d5e4a9e3a16ebd4c482525045da3db After a quick glance I don't see a fix post-b487bb810ec9 either in master or on the libvirt list. Looking at the range under test it looks like one or more of John's changes is adding parameters called index, shadowing index(3) from strings.h. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Dom0 linux 4.0 + devel/for-linus-4.1 branch: p2m.c:884:d0v0 gfn_to_mfn failed! gfn=ffffffff001ed type:4
On 13/04/15 16:11, Sander Eikelenboom wrote: Monday, April 13, 2015, 2:21:21 PM, you wrote: On 13/04/15 13:14, Sander Eikelenboom wrote: Monday, April 13, 2015, 2:07:02 PM, you wrote: On 13/04/15 12:21, Sander Eikelenboom wrote: Monday, April 13, 2015, 11:50:51 AM, you wrote: On 13/04/15 10:39, Sander Eikelenboom wrote: Hi David, I seem to have spotted some trouble with a 4.0 dom0 kernel with the devel/for-linus-4.1 branch pulled on top. Does this remind you of any specific commits in the devel/for-linus-4.1 branch that could likely be involved that i could try to revert ? Yes. This will probably be 4e8c0c8c4bf3a (xen/privcmd: improve performance of MMAPBATCH_V2) which makes the kernel try harder to map all GFNs instead of failing on the first one. I think this is qemu incorrectly trying to map GFNs. David Reverted that specific one, but still get those messages. You'll have to bisect it then. Because I don't see any other relevant commits in devel/for-linus-4.1 David Ok .. hmm first candidate of the bisect also looks interessting: [628c28eefd6f2cef03b212081b466ae43fd093a3] xen: unify foreign GFN map/unmap for auto-xlated physmap guests Unless your dom0 is PVH, no. David Bisection came back with: 22d8a8938407cb1342af763e937fdf9ee8daf24a is the first bad commit commit 22d8a8938407cb1342af763e937fdf9ee8daf24a Author: Konrad Rzeszutek Wilk konrad.w...@oracle.com Date: Fri Apr 3 10:28:08 2015 -0400 xen/pciback: Don't disable PCI_COMMAND on PCI device reset. I don't really understand how this could cause the symptoms you reported. I don't have time to look into this myself so I'm going to drop these two pciback patches for now. David ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/3] xen/x86: Infrastructure to create BUG_FRAMES in asm code
On 09.04.15 at 22:06, andrew.coop...@citrix.com wrote:
@@ -66,4 +68,40 @@ struct bug_frame {
__stop_bug_frames_2[],
__stop_bug_frames_3[];
+#else /* !__ASSEMBLY__ */
+
+/*
+ * Construct a bugframe, suitable for using in assembly code. Should always
+ * match the C version above. One complication is having to stash the
strings
+ * in .rodata (TODO - figure out how to get GAS to elide duplicate
file_str's)
Use the 'M' and 'S' section flags (and perhaps the section name gcc
also uses for this purpose, .rodata.str1 or some such).
+.macro BUG_FRAME type, line, file_str, second_frame, msg
Can we please avoid spreading the bad habit of starting directives
in the first column? The only thing formally allowed to start there is
a label.
+92: ud2a
Instead of using number labels that can conflict with the context
the macro is used in, please use .L prefixed ones together with
\@ to reference the macro invocation count (as a unique number).
+.if \second_frame
+ .pushsection .rodata
+ 95: .asciz \msg
+ .popsection
+.long 0, (95b - 93b)
+.endif
+.popsection
+.endm
Please be consistent with indentation.
+#define WARN() BUG_FRAME BUGFRAME_warn, __LINE__, __FILE__, 0, 0
+#define BUG() BUG_FRAME BUGFRAME_bug, __LINE__, __FILE__, 0, 0
I don't think the parentheses are particularly well suited for
assembly code.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] VTd/dmar: Tweak how the DMAR table is clobbered
On 14/04/15 08:50, Jan Beulich wrote: On 10.04.15 at 11:08, andrew.coop...@citrix.com wrote: On 10/04/15 02:23, Tian, Kevin wrote: From: Andrew Cooper [mailto:andrew.coop...@citrix.com] Sent: Thursday, April 09, 2015 3:45 AM Intead of clobbering DMAR - XMAR and back, clobber to RMAD instead. This means that changing the signature does not alter the checksum, which allows the clobbering/unclobbering to be peformed atomically and idempotently, which is an advantage on the kexec path which can reenter acpi_dmar_reinstate(). Signed-off-by: Andrew Cooper andrew.coop...@citrix.com CC: Yang Zhang yang.z.zh...@intel.com CC: Kevin Tian kevin.t...@intel.com Acked-by: Kevin Tian kevin.t...@intel.com and curious do you observe a real atomic issue in kexec or just catch this potential issue when reading code? :-) I have run over it once in the past, but mainly it is one small thing on a very long list of tweaks to make the crash path for reliable. As indicated in the other thread, I think the best direction moving forwards is to see about positively preventing dom0 having access, rather than simply hiding the table, but that is a job for another time. And possibly not doable, as this might crash Dom0. What made me wonder for a very long time though is why similar clobbering isn't needed for AMD. Any dom0 driver will be capable of not crashing if it can't get to certain pages, or it wouldn't last for any meaningful time on a system with buggy firmware. It is the very fact that this hack is only used on Intel which leads me to suspect that it is the wrong thing to be doing overall. In any event, David's point of the now chosen signature perhaps posing a higher risk of colliding with a real table is an issue that shouldn't have been discarded before committing. I don't believe the new name is plausibly at a higher risk of colliding. Unless Kevin or Yang object, I'd therefore suggest reverting the change. Once we determined why VT-d needs what AMD Vi doesn't need, and once we settled on the risk of name collision (perhaps using an underscore prefixed name would further reduce this risk), we could then do this another way (zap the table from XSDT/RSDT instead?), or leave it as it was without the change. It is my hope that this can be resolved in the longterm without any modification to the acpi tables. Currently, it is not possible to dump the ACPI tables from dom0 without knowing how to hexedit the XMAR table back into life. This is an impediment to debugging. However, I still believe that the current change is a positive improvement over what happened previously. (Apart from the above I also don't really see why RMAD was chosen - this doesn't really resemble anything similar to DMAR except for using the same letters. If at least it had been the properly reversed string ...) A fully reversed string is RAMD which I felt was slightly more likely to collide, but I am not too fussed on exactly which string is chosen, so long as it has the same u8 checksum as DMAR. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] new functions libxl_bitmap_{or,and}
Thanks, we're getting there. If my comments confuse you please just ask
for clarification.
There is no need to change the subject line. However, it would be
useful if you have some kind of version number in you subject line. That
is
[PATCH vX] libxl: provide libxl_bimap_{and,or}
You can do this by supplying --subject-prefix= to git format-patch
git format-patch -1 --subject-prefix=[PATCH vX] ...
where X refers to your version number.
On Mon, Apr 13, 2015 at 01:47:18AM -0600, Linda Jacobson wrote:
provide logical and and or of two bitmaps
And the SoB line should be here.
---
v.1 updated comments and format
v.2 rewrote bitmap functions to manipulate bytes not bits
Signed-off-by: Linda Jacobson lin...@jma3.com
---
tools/libxl/libxl_utils.c | 74
+++
tools/libxl/libxl_utils.h | 5
2 files changed, 79 insertions(+)
diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
index 9053b27..5c7178f 100644
--- a/tools/libxl/libxl_utils.c
+++ b/tools/libxl/libxl_utils.c
@@ -691,6 +691,80 @@ void libxl_bitmap_reset(libxl_bitmap *bitmap, int bit)
bitmap-map[bit / 8] = ~(1 (bit 7));
}
+/* provide logical or and logical and of two bitmaps */
Normally we take the line before as the comment for the function that
follows it. So you don't need to mention and function here.
Actually I don't think you need a comment for such obvious function at
all.
+int libxl_bitmap_or(libxl_ctx *ctx, libxl_bitmap *or_map,
+libxl_bitmap *map1, libxl_bitmap *map2)
Actually I think you need to constify map1 and map2. I.e.
const libxl_bitmap *map1,
const libxl_bitmap *map2)
Sorry for not having mentioned these earlier. Since you're going to
resend due to other issues so you might as well just take care of these
nits.
+{
+GC_INIT(ctx);
+int rc;
+uint32_t i;
+libxl_bitmap *lgmap;
+libxl_bitmap *smap;
+
Constify these as well.
And probably use better name like large_map and small_map?
+if (map1-size map2-size) {
+lgmap = map1;
+smap = map2;
+}
+else {
Coding style. Should be
} else {
+lgmap = map2;
+smap = map1;
+}
+
+rc = libxl_bitmap_alloc(ctx, or_map, lgmap-size * 8);
+if (rc)
+goto out;
+
+/*
+ * if bitmaps aren't the same size, their union (logical or) will
If
+ * be size of larger bit map. Any bit past the end of the
+ * smaller bit map, will match the larger one.
+ */
+for (i = 0; i smap-size; i++)
+or_map-map[i] = (smap-map[i] | lgmap-map[i]);
+
+for (i = smap-size; i lgmap-size; i++)
+or_map-map[i] = lgmap-map[i];
+
+out:
+GC_FREE;
+return rc;
+}
+
+int libxl_bitmap_and(libxl_ctx *ctx, libxl_bitmap *and_map,
+ libxl_bitmap *map1, libxl_bitmap *map2)
Constify map1 and map2.
+{
+GC_INIT(ctx);
+int rc;
+uint32_t i;
+libxl_bitmap *lgmap, *smap;
Constify lgmap and smap.
+
+if (map1-size map2-size) {
+lgmap = map1;
+smap = map2;
+}
+else {
Coding style.
+lgmap = map2;
+smap = map1;
+}
+
+
+rc = libxl_bitmap_alloc(ctx, and_map, smap-size * 8);
+if (rc)
+goto out;
+
+/*
+ * if bitmaps aren't same size, their 'and' will be size of
If
+ * smaller bit map
+ */
+for (i = 0; i and_map-size; i++)
+and_map-map[i] = (lgmap-map[i] smap-map[i]);
+
+out:
+GC_FREE;
+return rc;
+
+}
+
int libxl_bitmap_count_set(const libxl_bitmap *bitmap)
{
int i, nr_set_bits = 0;
diff --git a/tools/libxl/libxl_utils.h b/tools/libxl/libxl_utils.h
index acacdd9..1c0086b 100644
--- a/tools/libxl/libxl_utils.h
+++ b/tools/libxl/libxl_utils.h
@@ -90,6 +90,11 @@ int libxl_bitmap_test(const libxl_bitmap *bitmap, int bit);
void libxl_bitmap_set(libxl_bitmap *bitmap, int bit);
void libxl_bitmap_reset(libxl_bitmap *bitmap, int bit);
int libxl_bitmap_count_set(const libxl_bitmap *cpumap);
+/* or and and functions for two bitmaps */
Or
+int libxl_bitmap_or(libxl_ctx *ctx, libxl_bitmap *or_map,
+libxl_bitmap *map1, libxl_bitmap *map2);
+int libxl_bitmap_and(libxl_ctx *ctx, libxl_bitmap *and_map,
+ libxl_bitmap *map1, libxl_bitmap *map2);
Constify map1 and map2.
Wei.
char *libxl_bitmap_to_hex_string(libxl_ctx *ctx, const libxl_bitmap *cpumap);
static inline void libxl_bitmap_set_any(libxl_bitmap *bitmap)
{
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/1] xc_domain_restore: Allow QEMU to increase memory
On 04/14/2015 04:53 PM, Andrew Cooper wrote: On 14/04/15 00:51, Don Slutz wrote: On 04/13/15 12:25, Andrew Cooper wrote: On 13/04/15 17:09, Don Slutz wrote: If QEMU has called on xc_domain_setmaxmem to add more memory for option ROMs, domain restore needs to also increase the memory. Signed-off-by: Don Slutz dsl...@verizon.com hvmloader has no interaction with xc_domain_restore(). I did not mean to imply that it did. Somehow I lost the fact that this is a bug in master: [root@dcs-xen-52 don]# xl cre -p /home/don/e1000x8.xfg Parsing config from /home/don/e1000x8.xfg got a tsc mode string: native_paravirt [root@dcs-xen-52 don]# xl save e1000x8 e1000x8.save Saving to e1000x8.save new xl format (info 0x1/0x0/3506) xc: Saving memory: iter 0 (last sent 0 skipped 0): 1044481/1044481 100% [root@dcs-xen-52 don]# xl restore e1000x8.save Loading new save file e1000x8.save (new xl fmt info 0x1/0x0/3506) Savefile contains xl domain config in JSON format Parsing config from saved xc: error: Failed to allocate memory for batch.!: Internal error libxl: error: libxl_create.c:1057:libxl__xc_domain_restore_done: restoring domain: Cannot allocate memory libxl: error: libxl_create.c:1129:domcreate_rebuild_done: cannot (re-)build domain: -3 libxl: error: libxl.c:1576:libxl__destroy_domid: non-existant domain 2 libxl: error: libxl.c:1540:domain_destroy_callback: unable to destroy guest with domid 2 libxl: error: libxl_create.c:1490:domcreate_destruction_cb: unable to destroy domain 2 following failed creation [root@dcs-xen-52 don]# The hvmloader part turns out to be a warning message that is ok to ignore. However xl save followed by xl restore is currently broken without some fix. It is xl's job to propagate the current memory as part of migration. If qemu has had to bump it up, this should be reflected in the domain config file. Not at all sure how QEMU (either in dom0 or a driver domain) is expected to change a file (the domain config file). My guess is that you are saying that xl save (before xc_domain_save) is the correct place to record (or add extra info). However it looks to me that all the data needed is in the save file, but I could be wrong. The page data is correctly saved into the save file (migration stream). However when the new domain is created, it's size is wrong. You cannot adjust any of the config info to fix the size, because the option ROM space to reserve is not an existing config option. So if I am following you correctly, libxl needs to add and process more info to handle this case. The migration path should not be hacked up to fix a higher level toolstack bug. I do not see how QEMU is part of the higher level toolstack. If you mean xl vs xc, then I can see xl save some how doing the work. This patch works for me, but I am happy to explore other ways to fix this bug. If I understand correctly, the steps are this: * 'xl create' makes a VM of size $FOO * qemu bumps the size to $FOO+$N * 'xl save' writes $FOO+$N of page data, but the xl config file at the start of the image still says $FOO * 'xl restore' creates a vm of size $FOO, then instructs xc_domain_restore() to put $FOO+$N pages into it. I would argue first, that qemu should not play in this area to start with. However, the real bug here is that the domain configuration written by xl save is inaccurate. There's a case like COLO: 1. Both Primary/Secondary VM are created first with the same config file which makes a VM of size $FOO 2. qemu bumps the size to $FOO+$N 3. 'save' writes $FOO+$N of page data 4. 'restore' put $FOO+$N pages into $FOO pages which will cause error Even if you fix the configuration, the bug still exists because the config only been transferred from Primary to Secondary once at the very beginning when you execute 'xl remus' command. The problem is how to let the secondary (restore) side knows the size change? Through a migration command(which is easier in v2 migration) or some other solution? Form this point of view, I think Don's solution is one way to solve the problem. ~Andrew . -- Thanks, Yang. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/1] xc_domain_restore: Allow QEMU to increase memory
On 14/04/15 10:22, Hongyang Yang wrote: On 04/14/2015 04:53 PM, Andrew Cooper wrote: On 14/04/15 00:51, Don Slutz wrote: On 04/13/15 12:25, Andrew Cooper wrote: On 13/04/15 17:09, Don Slutz wrote: If QEMU has called on xc_domain_setmaxmem to add more memory for option ROMs, domain restore needs to also increase the memory. Signed-off-by: Don Slutz dsl...@verizon.com hvmloader has no interaction with xc_domain_restore(). I did not mean to imply that it did. Somehow I lost the fact that this is a bug in master: [root@dcs-xen-52 don]# xl cre -p /home/don/e1000x8.xfg Parsing config from /home/don/e1000x8.xfg got a tsc mode string: native_paravirt [root@dcs-xen-52 don]# xl save e1000x8 e1000x8.save Saving to e1000x8.save new xl format (info 0x1/0x0/3506) xc: Saving memory: iter 0 (last sent 0 skipped 0): 1044481/1044481 100% [root@dcs-xen-52 don]# xl restore e1000x8.save Loading new save file e1000x8.save (new xl fmt info 0x1/0x0/3506) Savefile contains xl domain config in JSON format Parsing config from saved xc: error: Failed to allocate memory for batch.!: Internal error libxl: error: libxl_create.c:1057:libxl__xc_domain_restore_done: restoring domain: Cannot allocate memory libxl: error: libxl_create.c:1129:domcreate_rebuild_done: cannot (re-)build domain: -3 libxl: error: libxl.c:1576:libxl__destroy_domid: non-existant domain 2 libxl: error: libxl.c:1540:domain_destroy_callback: unable to destroy guest with domid 2 libxl: error: libxl_create.c:1490:domcreate_destruction_cb: unable to destroy domain 2 following failed creation [root@dcs-xen-52 don]# The hvmloader part turns out to be a warning message that is ok to ignore. However xl save followed by xl restore is currently broken without some fix. It is xl's job to propagate the current memory as part of migration. If qemu has had to bump it up, this should be reflected in the domain config file. Not at all sure how QEMU (either in dom0 or a driver domain) is expected to change a file (the domain config file). My guess is that you are saying that xl save (before xc_domain_save) is the correct place to record (or add extra info). However it looks to me that all the data needed is in the save file, but I could be wrong. The page data is correctly saved into the save file (migration stream). However when the new domain is created, it's size is wrong. You cannot adjust any of the config info to fix the size, because the option ROM space to reserve is not an existing config option. So if I am following you correctly, libxl needs to add and process more info to handle this case. The migration path should not be hacked up to fix a higher level toolstack bug. I do not see how QEMU is part of the higher level toolstack. If you mean xl vs xc, then I can see xl save some how doing the work. This patch works for me, but I am happy to explore other ways to fix this bug. If I understand correctly, the steps are this: * 'xl create' makes a VM of size $FOO * qemu bumps the size to $FOO+$N * 'xl save' writes $FOO+$N of page data, but the xl config file at the start of the image still says $FOO * 'xl restore' creates a vm of size $FOO, then instructs xc_domain_restore() to put $FOO+$N pages into it. I would argue first, that qemu should not play in this area to start with. However, the real bug here is that the domain configuration written by xl save is inaccurate. There's a case like COLO: 1. Both Primary/Secondary VM are created first with the same config file which makes a VM of size $FOO 2. qemu bumps the size to $FOO+$N 3. 'save' writes $FOO+$N of page data 4. 'restore' put $FOO+$N pages into $FOO pages which will cause error Even if you fix the configuration, the bug still exists because the config only been transferred from Primary to Secondary once at the very beginning when you execute 'xl remus' command. The problem is how to let the secondary (restore) side knows the size change? Through a migration command(which is easier in v2 migration) or some other solution? Form this point of view, I think Don's solution is one way to solve the problem. Funny you should ask that. Migrationv2 for libxl moves the JSON config blob into the libxl stream, rather than being a singleshot action at the very start. From that point, it becomes plausible to send a new JSON blob when an update on the source side occurs. However, I am still firmly of the opinion that is an xl/libxl bug to be fixed at that level, not hacked around in the restore code. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 2/2] xen/arm: Make HAS_PCI compilable on ARM by adding place-holder code
On Tue, 14 Apr 2015, Jaggi, Manish wrote:
diff --git a/xen/include/asm-arm/pci.h b/xen/include/asm-arm/pci.h
index de13359..b8ec882 100644
--- a/xen/include/asm-arm/pci.h
+++ b/xen/include/asm-arm/pci.h
@@ -1,7 +1,8 @@
-#ifndef __X86_PCI_H__
-#define __X86_PCI_H__
+#ifndef __ARM_PCI_H__
+#define __ARM_PCI_H__
struct arch_pci_dev {
+void *dev;
void * is error-prone. Why can't you use the use the real structure?
[manish]Will change it. I believe dev_archdata structure has also a void *
(in asm-arm/device.h). So all void * are error prone in xen ?
As you know void* works around the type system, so it prevents the
compiler from making many type safety checks. We should try to avoid
them if we can.
I think that you are right, the void *iommu in dev_archdata should
actually be struct arm_smmu_xen_device *iommu.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/1] xc_domain_restore: Allow QEMU to increase memory
On Tue, Apr 14, 2015 at 05:22:31PM +0800, Hongyang Yang wrote: [...] If I understand correctly, the steps are this: * 'xl create' makes a VM of size $FOO * qemu bumps the size to $FOO+$N * 'xl save' writes $FOO+$N of page data, but the xl config file at the start of the image still says $FOO * 'xl restore' creates a vm of size $FOO, then instructs xc_domain_restore() to put $FOO+$N pages into it. I would argue first, that qemu should not play in this area to start with. However, the real bug here is that the domain configuration written by xl save is inaccurate. There's a case like COLO: 1. Both Primary/Secondary VM are created first with the same config file which makes a VM of size $FOO 2. qemu bumps the size to $FOO+$N 3. 'save' writes $FOO+$N of page data 4. 'restore' put $FOO+$N pages into $FOO pages which will cause error Even if you fix the configuration, the bug still exists because the config only been transferred from Primary to Secondary once at the very beginning when you execute 'xl remus' command. The problem is how to let the secondary (restore) side knows the size change? Through a migration command(which is easier in v2 migration) or some other solution? As I said in my reply to Don, the extra memory can be saved during domain creation. That would solve this problem. Wei. Form this point of view, I think Don's solution is one way to solve the problem. ~Andrew . -- Thanks, Yang. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 0/2] Re-factoring passthrough/pci.c and adding place-holder code for ARM/PCI
On Tue, 14 Apr 2015, Jaggi, Manish wrote: Hi Julien, From: Julien Grall julien.grall@gmail.com Sent: Monday, April 13, 2015 3:49 PM To: Jaggi, Manish; xen Devel; Stefano Stabellini; Julien Grall; Ian Campbell; Kumar, Vijaya; prasun.kap...@cavium.com Subject: Re: [Xen-devel] [PATCH 0/2] Re-factoring passthrough/pci.c and adding place-holder code for ARM/PCI Hi Manish, On 13/04/15 08:37, Manish Jaggi wrote: Xen currently does not have PCI support for ARM builds. This patch set makes the code compilable for ARM PCI and adds places-holder code which would be replaced with PCI pass-through support patch series. May I ask why you did send directly all the code to support PCI on ARM? Without the rest it's hard to tell whether these patches make sense or not. [Manish] As I have mentioned these two patches are only for refactoring msi specific functions to x86 files and providing the constructs that make PCI ARM code compilable. The code for PCI ARM is very basic in the patch and PCI passthrough code patches will follow in next series. Please let me know which code does not makes sense and I will modify it. On the face if it, it makes sense, and I understand that you are doing this to just build Xen on ARM with HAS_PCI. However it is hard to understand the full picture, how all the pieces fit together, without the rest. I think it would make sense to place these two patches at the beginning of your longer series. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] x86/Dom0: Don't allow dom0_max_vcpus to be zero
On 09.04.15 at 22:59, andrew.coop...@citrix.com wrote: On 09/04/2015 21:38, Boris Ostrovsky wrote: In case dom0_max_vcpus is incorrectly specified on boot line make sure we will still boot. Signed-off-by: Boris Ostrovsky boris.ostrov...@oracle.com Good catch - lets not do that. Reviewed-by: Andrew Cooper andrew.coop...@citrix.com I see it got committed already, and I don't really mind the change, but - are we really in need of this? I.e. are we really rejecting bad or insane command line option values everywhere else? I very much doubt that, and it very much looks like a then don't do this thing to me... Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RFC] xen/pvh: use a custom IO bitmap for PVH hardware domains
On 10.04.15 at 03:43, kevin.t...@intel.com wrote: From: Roger Pau Monne [mailto:roger@citrix.com] Sent: Wednesday, April 08, 2015 8:57 PM @@ -1484,6 +1489,12 @@ int hvm_domain_initialise(struct domain *d) goto fail1; d-arch.hvm_domain.io_handler-num_slot = 0; +/* Set the default IO Bitmap */ +if ( is_hardware_domain(d) ) +d-arch.hvm_domain.io_bitmap = hvm_hw_io_bitmap; +else +d-arch.hvm_domain.io_bitmap = hvm_io_bitmap; + if we want to support multiple PVH hardware domains w/ different permissions, using global array is not correct here. There's no such thing like multiple hardware domains. There can only ever (theoretically that is) be multiple control domains. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RFC] xen/pvh: use a custom IO bitmap for PVH hardware domains
On 09.04.15 at 12:55, andrew.coop...@citrix.com wrote: On 08/04/15 13:57, Roger Pau Monne wrote: Since a PVH hardware domain has access to the physical hardware create a custom more permissive IO bitmap. The permissions set on the bitmap are populated based on the contents of the ioports rangeset. Also add the IO ports of the serial console used by Xen to the list of not accessible IO ports. Thankyou for looking into this. I think it is the correct general direction, but I do have some questions/thoughts about this area. I know that the current implementation is that dom0 is whitelisted and can play with everything, but is this actually the best API? Conceptually, a better approach would be for dom0 to start with no permissions, and explicitly request access (After all, PV and PVH domains are expected to know exactly what they are doing under Xen). I don't think this would work too well with the AML interpreter. And it certainly doesn't make sense to have Dom0 request access blindly for every port an IN or OUT is done against, as that would effectively be no different from Dom0 being granted access to everything minus a black list as we do now. @@ -1618,6 +1624,10 @@ int __init construct_dom0( pvh_map_all_iomem(d, nr_pages); pvh_setup_e820(d, nr_pages); + +for ( i = 0; i 0x1; i++ ) +if ( ioports_access_permitted(d, i, i) ) +__clear_bit(i, hvm_hw_io_bitmap); (There is surely a more efficient way of doing this? If there isn't, there probably should be) There is also a boundary issue between VT-x and SVM. For VT-x, the IO bitmap is 2 pages. For SVM, it is 2 pages and 3 bits. I suspect the difference is to do with the handling of a 4byte write to port 0x. I think you might need to check i 0x10003 instead. I don't think we should ever grant access to ports 0x1...0x10003, i.e. not clearing those bits seems quite fine to me. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/1] xc_domain_restore: Allow QEMU to increase memory
On Tue, Apr 14, 2015 at 11:46:55AM +0800, Hongyang Yang wrote: This patch also fix a triple fault when guests running under COLO mode. (XEN) d0v1 Over-allocation for domain 1: 524545 524544 (XEN) memory.c:155:d0v1 Could not allocate order=0 extent: id=1 memflags=0 (181 of 235) (XEN) d1v1 Triple fault - invoking HVM shutdown action 1 Presumably this is due to accounting error or some other latent bug. This patch bumps the limit of max memory, which covers the real cause of your issue. This is prone to breakage in the future. Wei. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/1] xc_domain_restore: Allow QEMU to increase memory
On 14/04/15 00:51, Don Slutz wrote: On 04/13/15 12:25, Andrew Cooper wrote: On 13/04/15 17:09, Don Slutz wrote: If QEMU has called on xc_domain_setmaxmem to add more memory for option ROMs, domain restore needs to also increase the memory. Signed-off-by: Don Slutz dsl...@verizon.com hvmloader has no interaction with xc_domain_restore(). I did not mean to imply that it did. Somehow I lost the fact that this is a bug in master: [root@dcs-xen-52 don]# xl cre -p /home/don/e1000x8.xfg Parsing config from /home/don/e1000x8.xfg got a tsc mode string: native_paravirt [root@dcs-xen-52 don]# xl save e1000x8 e1000x8.save Saving to e1000x8.save new xl format (info 0x1/0x0/3506) xc: Saving memory: iter 0 (last sent 0 skipped 0): 1044481/1044481 100% [root@dcs-xen-52 don]# xl restore e1000x8.save Loading new save file e1000x8.save (new xl fmt info 0x1/0x0/3506) Savefile contains xl domain config in JSON format Parsing config from saved xc: error: Failed to allocate memory for batch.!: Internal error libxl: error: libxl_create.c:1057:libxl__xc_domain_restore_done: restoring domain: Cannot allocate memory libxl: error: libxl_create.c:1129:domcreate_rebuild_done: cannot (re-)build domain: -3 libxl: error: libxl.c:1576:libxl__destroy_domid: non-existant domain 2 libxl: error: libxl.c:1540:domain_destroy_callback: unable to destroy guest with domid 2 libxl: error: libxl_create.c:1490:domcreate_destruction_cb: unable to destroy domain 2 following failed creation [root@dcs-xen-52 don]# The hvmloader part turns out to be a warning message that is ok to ignore. However xl save followed by xl restore is currently broken without some fix. It is xl's job to propagate the current memory as part of migration. If qemu has had to bump it up, this should be reflected in the domain config file. Not at all sure how QEMU (either in dom0 or a driver domain) is expected to change a file (the domain config file). My guess is that you are saying that xl save (before xc_domain_save) is the correct place to record (or add extra info). However it looks to me that all the data needed is in the save file, but I could be wrong. The page data is correctly saved into the save file (migration stream). However when the new domain is created, it's size is wrong. You cannot adjust any of the config info to fix the size, because the option ROM space to reserve is not an existing config option. So if I am following you correctly, libxl needs to add and process more info to handle this case. The migration path should not be hacked up to fix a higher level toolstack bug. I do not see how QEMU is part of the higher level toolstack. If you mean xl vs xc, then I can see xl save some how doing the work. This patch works for me, but I am happy to explore other ways to fix this bug. If I understand correctly, the steps are this: * 'xl create' makes a VM of size $FOO * qemu bumps the size to $FOO+$N * 'xl save' writes $FOO+$N of page data, but the xl config file at the start of the image still says $FOO * 'xl restore' creates a vm of size $FOO, then instructs xc_domain_restore() to put $FOO+$N pages into it. I would argue first, that qemu should not play in this area to start with. However, the real bug here is that the domain configuration written by xl save is inaccurate. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/1] xc_domain_restore: Allow QEMU to increase memory
On Mon, Apr 13, 2015 at 07:51:31PM -0400, Don Slutz wrote: On 04/13/15 12:25, Andrew Cooper wrote: On 13/04/15 17:09, Don Slutz wrote: If QEMU has called on xc_domain_setmaxmem to add more memory for option ROMs, domain restore needs to also increase the memory. Signed-off-by: Don Slutz dsl...@verizon.com hvmloader has no interaction with xc_domain_restore(). I did not mean to imply that it did. Somehow I lost the fact that this is a bug in master: [root@dcs-xen-52 don]# xl cre -p /home/don/e1000x8.xfg Parsing config from /home/don/e1000x8.xfg got a tsc mode string: native_paravirt [root@dcs-xen-52 don]# xl save e1000x8 e1000x8.save Saving to e1000x8.save new xl format (info 0x1/0x0/3506) xc: Saving memory: iter 0 (last sent 0 skipped 0): 1044481/1044481 100% [root@dcs-xen-52 don]# xl restore e1000x8.save Loading new save file e1000x8.save (new xl fmt info 0x1/0x0/3506) Savefile contains xl domain config in JSON format Parsing config from saved xc: error: Failed to allocate memory for batch.!: Internal error libxl: error: libxl_create.c:1057:libxl__xc_domain_restore_done: restoring domain: Cannot allocate memory libxl: error: libxl_create.c:1129:domcreate_rebuild_done: cannot (re-)build domain: -3 libxl: error: libxl.c:1576:libxl__destroy_domid: non-existant domain 2 libxl: error: libxl.c:1540:domain_destroy_callback: unable to destroy guest with domid 2 libxl: error: libxl_create.c:1490:domcreate_destruction_cb: unable to destroy domain 2 following failed creation [root@dcs-xen-52 don]# The hvmloader part turns out to be a warning message that is ok to ignore. However xl save followed by xl restore is currently broken without some fix. It is xl's job to propagate the current memory as part of migration. If qemu has had to bump it up, this should be reflected in the domain config file. Not at all sure how QEMU (either in dom0 or a driver domain) is expected to change a file (the domain config file). My guess is that you are saying that xl save (before xc_domain_save) is the correct place to record (or add extra info). However it looks to me that all the data needed is in the save file, but I could be wrong. The page data is correctly saved into the save file (migration stream). However when the new domain is created, it's size is wrong. You cannot adjust any of the config info to fix the size, because the option ROM space to reserve is not an existing config option. So if I am following you correctly, libxl needs to add and process more info to handle this case. Thanks for the analysis. I think what you need to do is to adjust the memory size during domain creation in libxl, then the relevant data is saved at creation time. It should not be modified during restore. There is already various adjustments to memory related values in libxl. Grep video_memkb and mex_memkb in libxl. Is there a way to know how much more memory each option rom needs? If so, you can correctly account for the extra memory you need. This would be an ideal fix to this problem. Wei. The migration path should not be hacked up to fix a higher level toolstack bug. I do not see how QEMU is part of the higher level toolstack. If you mean xl vs xc, then I can see xl save some how doing the work. This patch works for me, but I am happy to explore other ways to fix this bug. -Don Slutz ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/2] xen/x86: Patch re-factors MSI/X config code from, drivers/passthrough/pci.c to x86 specific
On 13.04.15 at 12:34, mja...@caviumnetworks.com wrote:
On Monday 13 April 2015 03:45 PM, Stefano Stabellini wrote:
On Mon, 13 Apr 2015, Manish Jaggi wrote:
@@ -282,22 +266,10 @@ static struct pci_dev *alloc_pdev(struct pci_seg
*pseg,
u8 bus, u8 devfn)
*((u8*) pdev-bus) = bus;
*((u8*) pdev-devfn) = devfn;
pdev-domain = NULL;
-INIT_LIST_HEAD(pdev-msi_list);
-
-if ( pci_find_cap_offset(pseg-nr, bus, PCI_SLOT(devfn),
PCI_FUNC(devfn),
- PCI_CAP_ID_MSIX) )
+if (!pci_alloc_msix (pdev, pseg, bus, devfn))
{
-struct arch_msix *msix = xzalloc(struct arch_msix);
-
-if ( !msix )
-{
-xfree(pdev);
-return NULL;
-}
-spin_lock_init(msix-table_lock);
-pdev-msix = msix;
+return NULL;
}
-
From the look of it, this code doesn't seem x86 specific
MSIX is only used for x86, dom0/U handles MSI/X in ARM. I think If ARM
is not using MSI/X then code has to be in x86 specific file.
No, you need to take a more general perspective here: MSI and
MSI-X are integral parts of PCI, and hence if ARM _really_ chooses
to hand control of it to DomU-s, the code here shouldn't become
x86-specific, but non-ARM-specific.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/1] xc_domain_restore: Allow QEMU to increase memory
On 04/14/2015 05:29 PM, Wei Liu wrote: On Tue, Apr 14, 2015 at 05:22:31PM +0800, Hongyang Yang wrote: [...] If I understand correctly, the steps are this: * 'xl create' makes a VM of size $FOO * qemu bumps the size to $FOO+$N * 'xl save' writes $FOO+$N of page data, but the xl config file at the start of the image still says $FOO * 'xl restore' creates a vm of size $FOO, then instructs xc_domain_restore() to put $FOO+$N pages into it. I would argue first, that qemu should not play in this area to start with. However, the real bug here is that the domain configuration written by xl save is inaccurate. There's a case like COLO: 1. Both Primary/Secondary VM are created first with the same config file which makes a VM of size $FOO 2. qemu bumps the size to $FOO+$N 3. 'save' writes $FOO+$N of page data 4. 'restore' put $FOO+$N pages into $FOO pages which will cause error Even if you fix the configuration, the bug still exists because the config only been transferred from Primary to Secondary once at the very beginning when you execute 'xl remus' command. The problem is how to let the secondary (restore) side knows the size change? Through a migration command(which is easier in v2 migration) or some other solution? As I said in my reply to Don, the extra memory can be saved during domain creation. That would solve this problem. After migration we'll enter COLO mode, which will continously send migration stream to Secondary. Domain creation only happens before doing live migration. Wei. Form this point of view, I think Don's solution is one way to solve the problem. ~Andrew . -- Thanks, Yang. . -- Thanks, Yang. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 0/3] xen: arm: Parse PCI DT nodes' ranges and interrupt-map
On Tue, Apr 14, 2015 at 09:43:07AM +0100, Ian Campbell wrote:
On Thu, 2015-03-12 at 17:16 +, Ian Campbell wrote:
This series adds parsing of the DT ranges and interrupt-map properties
for PCI devices, these contain the MMIOs and IRQs used by children on
the bus. This replaces the specific mapping stuff on xgene.
Somehow I managed to completely miss sending out the first patch here
(thanks Chen Baozi!)...
This should be inserted at the head of the series.
From d0a024dd49ca6f67b0ec0342fd2d819b750a52a4 Mon Sep 17 00:00:00 2001
From: Ian Campbell ian.campb...@citrix.com
Date: Fri, 6 Mar 2015 11:13:30 +
Subject: [PATCH] xen: dt: add dt_translate_address to translate a raw address
A future patch is going to want to translate an address which is not
part of the reg property so the existing dt_device_get_address is not
suitable.
This is the same function as Linux's of_translate_address but with the
names changed to fit our context and the dev parameter constified.
Signed-off-by: Ian Campbell ian.campb...@citrix.com
These 4 patches works for me.
Tested-by: Chen Baozi baoz...@gmail.com
---
xen/common/device_tree.c |5 +
xen/include/xen/device_tree.h |2 ++
2 files changed, 7 insertions(+)
diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
index d1c716f..89491b2 100644
--- a/xen/common/device_tree.c
+++ b/xen/common/device_tree.c
@@ -682,6 +682,11 @@ bail:
return result;
}
+u64 dt_translate_address(const struct dt_device_node *dev, const __be32
*in_addr)
+{
+return __dt_translate_address(dev, in_addr, ranges);
+}
+
/* dt_device_address - Translate device tree address and return it */
int dt_device_get_address(const struct dt_device_node *dev, int index,
u64 *addr, u64 *size)
diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
index c8a0375..b7455cd 100644
--- a/xen/include/xen/device_tree.h
+++ b/xen/include/xen/device_tree.h
@@ -464,6 +464,8 @@ struct dt_device_node *dt_find_node_by_path(const char
*path);
*/
const struct dt_device_node *dt_get_parent(const struct dt_device_node
*node);
+u64 dt_translate_address(const struct dt_device_node *np, const __be32
*addr);
+
/**
* dt_device_get_address - Resolve an address for a device
* @device: the device whose address is to be resolved
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 1/3] xen/pvh: enable mmu_update hypercall
On 10.04.15 at 19:29, roger@citrix.com wrote: This is needed for performing save/restore of PV guests. Signed-off-by: Roger Pau Monné roger@citrix.com Cc: Tim Deegan t...@xen.org Cc: Jan Beulich jbeul...@suse.com Cc: Andrew Cooper andrew.coop...@citrix.com --- Once migration v2 has been merged this patch can be reverted, since it removes the need to use the MMU_MACHPHYS_UPDATE hypercall. Didn't earlier discussion end with the request to limit PVH access to just this one sub-op? Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 1/3] xen/pvh: enable mmu_update hypercall
El 14/04/15 a les 13.55, Jan Beulich ha escrit: On 10.04.15 at 19:29, roger@citrix.com wrote: This is needed for performing save/restore of PV guests. Signed-off-by: Roger Pau Monné roger@citrix.com Cc: Tim Deegan t...@xen.org Cc: Jan Beulich jbeul...@suse.com Cc: Andrew Cooper andrew.coop...@citrix.com --- Once migration v2 has been merged this patch can be reverted, since it removes the need to use the MMU_MACHPHYS_UPDATE hypercall. Didn't earlier discussion end with the request to limit PVH access to just this one sub-op? My bad, from the last conversation I got the feeling that the other sub-ops already had the needed checks so it was fine to enable them. I know the checks are there, and using the other sub-ops from a PVH guest should be fine, but I guess it's better to just enable what we really need. Roger. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 2/3] xen/shadow: fix shadow_track_dirty_vram to work on hvm guests
On 10.04.15 at 19:29, roger@citrix.com wrote: Modify shadow_track_dirty_vram to use a local buffer and then flush to the guest without the paging_lock held. This is modeled after hap_track_dirty_vram. And hence introduces the same issue: The HVMOP_track_dirty_vram handler explicitly allows for up to 1Gb of VRAM, yet here you effectively limit things to 128Mb (one page worth of bits each taking care of one guest page) considering heavily fragmented memory. Apart from that the patch would need cleaning up for coding style. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] More force pushes (xen-4.5-testing, xen-unstable, qemu-mainline)
On 13.04.15 at 16:14, ian.jack...@eu.citrix.com wrote: Here are some more which I propose to force push. In each case I show all the blocking tests mentioned in the osstest test report. osstest service user writes ([xen-4.5-testing test] 50373: regressions - FAIL): flight 50373 xen-4.5-testing real [real] ... test-amd64-i386-freebsd10-amd64 14 guest-localmigrate/x10 fail in 50317 REGR. vs. 50268 ... version targeted for testing: xen 0b754fb3ed6b7b6d0f2e1f7c1877d3c0a7da2168 osstest service user writes ([xen-unstable test] 50390: regressions - FAIL): flight 50390 xen-unstable real [real] test-amd64-i386-freebsd10-i386 13 guest-localmigrate fail REGR. vs. 36514 test-amd64-i386-freebsd10-amd64 15 guest-localmigrate.2 fail REGR. vs. 36514 ... version targeted for testing: xen 123c7793797502b222300eb710cd3873dcca41ee osstest service user writes ([qemu-mainline test] 50391: regressions - FAIL): flight 50391 qemu-mainline real [real] ... test-amd64-i386-freebsd10-i386 13 guest-localmigrate fail REGR. vs. 36709 test-amd64-i386-freebsd10-amd64 15 guest-localmigrate.2 fail REGR. vs. 36709 version targeted for testing: qemuu58c24a4775ef7ccf16cfcd695753dfdf149fe29d Ack for all three of them. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] Ping: [PATCH 0/2] x86/vMSI-X: table read/write emulation adjustments
On 20.03.15 at 16:52, jbeul...@suse.com wrote: This has been pending for almost 4 weeks now... Jan Due to the (late) point in time when qemu requests the hypervisor to set up MSI-X interrupts (which is where the MMIO intercept gets put in place), the hypervisor doesn't see all guest writes, and hence shouldn't make assumptions on the state the virtual MSI-X resources are in. 1: honor all mask requests 2: add valid bits for read acceleration Signed-off-by: Jan Beulich jbeul...@suse.com ___ 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] Reminder: CfP for Xen Project Development Summit is closing on May 1st
The CfP is at http://events.linuxfoundation.org/events/xen-project-developer-summit/program/cfp http://events.linuxfoundation.org/events/xen-project-developer-summit/program/cfp Regards Lars___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 3/3] DO NOT APPLY - test code for this series
---
xen/arch/x86/traps.c| 66 +++
xen/arch/x86/x86_64/entry.S | 26 +
2 files changed, 92 insertions(+)
diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index 22cdfc4..c562842 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -3981,6 +3981,72 @@ void asm_domain_crash_synchronous(unsigned long addr)
__domain_crash_synchronous();
}
+#include xen/keyhandler.h
+
+void asm_test_warnframe(void);
+void asm_test_bugframe(void);
+void asm_test_assertframe(void);
+void asm_test_assert_enabled(void);
+void asm_test_assert_disabled(void);
+
+static void do_extreme_debug(unsigned char key, struct cpu_user_regs *regs)
+{
+printk('%c' pressed - Extreme debugging in progress...\n, key);
+
+switch ( key )
+{
+case '1':
+printk(WARN frame:\n);
+asm_test_warnframe();
+printk(Done\n);
+break;
+
+case '2':
+printk(BUG frame:\n);
+asm_test_bugframe();
+printk(Done\n);
+break;
+
+case '3':
+printk(ASSERT frame:\n);
+asm_test_assertframe();
+printk(Done\n);
+break;
+
+case '4':
+printk(Trip ASSERT_IRQ_ENABLED:\n);
+asm_test_assert_enabled();
+printk(Done\n);
+break;
+
+case '5':
+printk(Trip ASSERT_IRQ_DISABLED:\n);
+asm_test_assert_disabled();
+printk(Done\n);
+break;
+
+default:
+printk(Nothing\n);
+}
+}
+
+static struct keyhandler extreme_debug_keyhandler = {
+.irq_callback = 1,
+.u.irq_fn = do_extreme_debug,
+.desc = Extreme debugging
+};
+
+static int __init extreme_debug_keyhandler_init(void)
+{
+register_keyhandler('1', extreme_debug_keyhandler);
+register_keyhandler('2', extreme_debug_keyhandler);
+register_keyhandler('3', extreme_debug_keyhandler);
+register_keyhandler('4', extreme_debug_keyhandler);
+register_keyhandler('5', extreme_debug_keyhandler);
+return 0;
+}
+__initcall(extreme_debug_keyhandler_init);
+
/*
* Local variables:
* mode: C
diff --git a/xen/arch/x86/x86_64/entry.S b/xen/arch/x86/x86_64/entry.S
index 2d25d57..08a2eb8 100644
--- a/xen/arch/x86/x86_64/entry.S
+++ b/xen/arch/x86/x86_64/entry.S
@@ -13,6 +13,32 @@
#include public/xen.h
#include irq_vectors.h
+ENTRY(asm_test_warnframe)
+WARN
+ret
+
+ENTRY(asm_test_bugframe)
+BUG
+ret
+
+ENTRY(asm_test_assertframe)
+ ASSERT_FAILED(asm assert frame)
+ ret
+
+ENTRY(asm_test_assert_enabled)
+pushfq
+cli
+ ASSERT_INTERRUPTS_ENABLED
+popfq
+ ret
+
+ENTRY(asm_test_assert_disabled)
+pushfq
+sti
+ ASSERT_INTERRUPTS_DISABLED
+popfq
+ ret
+
ALIGN
/* %rbx: struct vcpu */
switch_to_kernel:
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH] osstest: fix FreeBSD guest disk size
New 10.1 images are larger than the previous 10.0 images, so change the size of the LVM volume to accommodate them. Signed-off-by: Roger Pau Monné roger@citrix.com Cc: Ian Jackson ian.jack...@eu.citrix.com --- ts-freebsd-install | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ts-freebsd-install b/ts-freebsd-install index 6c6abbe..555fa43 100755 --- a/ts-freebsd-install +++ b/ts-freebsd-install @@ -29,7 +29,7 @@ $gn ||= 'freebsd'; our $ho= selecthost($whhost); our $ram_mb= 1024; -our $disk_mb= 20480; +our $disk_mb= 21505; our $guesthost= $gn.guest.osstest; our $gho; -- 1.9.5 (Apple Git-50.3) ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 28/33] tools/libxl: Check if fdt_{first, next}_subnode are present in libfdt
On Thu, 2015-04-09 at 13:16 +0100, Ian Jackson wrote: I would say something like this: WFM, in particular the final two paragraphs which I think clarify everything which needs clarifying, thanks. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RFC] xen/pvh: use a custom IO bitmap for PVH hardware domains
On 14.04.15 at 12:45, roger@citrix.com wrote:
Hello,
El 14/04/15 a les 12.31, Jan Beulich ha escrit:
On 14.04.15 at 12:01, roger@citrix.com wrote:
I have one question about the current IO port handling for PVH guests
(DomU and Dom0). There's some code right now in vmx_vmexit_handler
(EXIT_REASON_IO_INSTRUCTION) that's kind PVH specific:
if ( exit_qualification 0x10 )
{
/* INS, OUTS */
if ( unlikely(is_pvh_vcpu(v)) /* PVH fixme */ ||
!handle_mmio() )
hvm_inject_hw_exception(TRAP_gp_fault, 0);
}
else
{
/* IN, OUT */
uint16_t port = (exit_qualification 16) 0x;
int bytes = (exit_qualification 0x07) + 1;
int dir = (exit_qualification 0x08) ? IOREQ_READ : IOREQ_WRITE;
if ( handle_pio(port, bytes, dir) )
update_guest_eip(); /* Safe: IN, OUT */
}
Is there any need for DomUs to access the IO ports? I know that FreeBSD
will poke at some of them during boot to scan for devices, but I'm not
sure if we could just make them noops in the PVH case and simply return
garbage.
The PVH special case quoted above is there only to prevent
reaching handle_mmio().
Injecting a GP seems like a little bit too much for trapped INS/OUTS, I
would rather just drop/ignore them if possible.
Dropping them means (silent) data corruption, whereas #GP is a
clear sign that something went wrong. In the end the case will
need to be properly handled anyway, and learning about this
becoming an immediate need will be better through a plainly
crashed domain than through one that (perhaps quite a long
period of time later) died in some obscure way.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/1] x86/hvm: prevent hvm_free_ioreq_gmfn() clobber of arbitrary memory
On 13.04.15 at 18:01, dsl...@verizon.com wrote:
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -536,8 +536,9 @@ static int hvm_alloc_ioreq_gmfn(struct domain *d,
unsigned long *gmfn)
static void hvm_free_ioreq_gmfn(struct domain *d, unsigned long gmfn)
{
-unsigned int i = gmfn - d-arch.hvm_domain.ioreq_gmfn.base;
+unsigned long i = gmfn - d-arch.hvm_domain.ioreq_gmfn.base;
+BUG_ON(i = sizeof(d-arch.hvm_domain.ioreq_gmfn.mask) * 8);
clear_bit(i, d-arch.hvm_domain.ioreq_gmfn.mask);
}
I'd be happier with an ASSERT() - Andrew?
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] new functions libxl_bitmap_{or,and}
On 4/14/2015 3:19 AM, Wei Liu wrote:
Thanks, we're getting there. If my comments confuse you please just ask
for clarification.
There is no need to change the subject line. However, it would be
useful if you have some kind of version number in you subject line. That
is
[PATCH vX] libxl: provide libxl_bimap_{and,or}
You can do this by supplying --subject-prefix= to git format-patch
git format-patch -1 --subject-prefix=[PATCH vX] ...
What version do you want me to use at this point? I've sort of lost
count, since many changes have been style changes.
I am assuming you usually reserve new versions for substantive changes?
where X refers to your version number.
On Mon, Apr 13, 2015 at 01:47:18AM -0600, Linda Jacobson wrote:
provide logical and and or of two bitmaps
And the SoB line should be here.
What does SoB stand for in this context?
---
v.1 updated comments and format
v.2 rewrote bitmap functions to manipulate bytes not bits
Signed-off-by: Linda Jacobson lin...@jma3.com
---
tools/libxl/libxl_utils.c | 74 +++
tools/libxl/libxl_utils.h | 5
2 files changed, 79 insertions(+)
diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
index 9053b27..5c7178f 100644
--- a/tools/libxl/libxl_utils.c
+++ b/tools/libxl/libxl_utils.c
@@ -691,6 +691,80 @@ void libxl_bitmap_reset(libxl_bitmap *bitmap, int bit)
bitmap-map[bit / 8] = ~(1 (bit 7));
}
+/* provide logical or and logical and of two bitmaps */
Normally we take the line before as the comment for the function that
follows it. So you don't need to mention and function here.
Actually I don't think you need a comment for such obvious function at
all.
I'll take it out.
+int libxl_bitmap_or(libxl_ctx *ctx, libxl_bitmap *or_map,
+libxl_bitmap *map1, libxl_bitmap *map2)
Actually I think you need to constify map1 and map2. I.e.
const libxl_bitmap *map1,
const libxl_bitmap *map2)
How come? Out of curiosity.
Sorry for not having mentioned these earlier. Since you're going to
resend due to other issues so you might as well just take care of these
nits.
+{
+GC_INIT(ctx);
+int rc;
+uint32_t i;
+libxl_bitmap *lgmap;
+libxl_bitmap *smap;
+
Constify these as well.
And probably use better name like large_map and small_map?
OK. Happy to. Earlier someone complained about my names being too
verbose.
Linda
+if (map1-size map2-size) {
+lgmap = map1;
+smap = map2;
+}
+else {
Coding style. Should be
} else {
+lgmap = map2;
+smap = map1;
+}
+
+rc = libxl_bitmap_alloc(ctx, or_map, lgmap-size * 8);
+if (rc)
+goto out;
+
+/*
+ * if bitmaps aren't the same size, their union (logical or) will
If
+ * be size of larger bit map. Any bit past the end of the
+ * smaller bit map, will match the larger one.
+ */
+for (i = 0; i smap-size; i++)
+or_map-map[i] = (smap-map[i] | lgmap-map[i]);
+
+for (i = smap-size; i lgmap-size; i++)
+or_map-map[i] = lgmap-map[i];
+
+out:
+GC_FREE;
+return rc;
+}
+
+int libxl_bitmap_and(libxl_ctx *ctx, libxl_bitmap *and_map,
+ libxl_bitmap *map1, libxl_bitmap *map2)
Constify map1 and map2.
+{
+GC_INIT(ctx);
+int rc;
+uint32_t i;
+libxl_bitmap *lgmap, *smap;
Constify lgmap and smap.
+
+if (map1-size map2-size) {
+lgmap = map1;
+smap = map2;
+}
+else {
Coding style.
+lgmap = map2;
+smap = map1;
+}
+
+
+rc = libxl_bitmap_alloc(ctx, and_map, smap-size * 8);
+if (rc)
+goto out;
+
+/*
+ * if bitmaps aren't same size, their 'and' will be size of
If
+ * smaller bit map
+ */
+for (i = 0; i and_map-size; i++)
+and_map-map[i] = (lgmap-map[i] smap-map[i]);
+
+out:
+GC_FREE;
+return rc;
+
+}
+
int libxl_bitmap_count_set(const libxl_bitmap *bitmap)
{
int i, nr_set_bits = 0;
diff --git a/tools/libxl/libxl_utils.h b/tools/libxl/libxl_utils.h
index acacdd9..1c0086b 100644
--- a/tools/libxl/libxl_utils.h
+++ b/tools/libxl/libxl_utils.h
@@ -90,6 +90,11 @@ int libxl_bitmap_test(const libxl_bitmap *bitmap, int bit);
void libxl_bitmap_set(libxl_bitmap *bitmap, int bit);
void libxl_bitmap_reset(libxl_bitmap *bitmap, int bit);
int libxl_bitmap_count_set(const libxl_bitmap *cpumap);
+/* or and and functions for two bitmaps */
Or
+int libxl_bitmap_or(libxl_ctx *ctx, libxl_bitmap *or_map,
+libxl_bitmap *map1, libxl_bitmap *map2);
+int libxl_bitmap_and(libxl_ctx *ctx, libxl_bitmap *and_map,
+ libxl_bitmap *map1, libxl_bitmap *map2);
Constify map1 and map2.
Wei.
char *libxl_bitmap_to_hex_string(libxl_ctx *ctx, const libxl_bitmap *cpumap);
static inline void
Re: [Xen-devel] [PATCH v3 3/3] xen: rework paging_log_dirty_op to work with hvm guests
On 10.04.15 at 19:29, roger@citrix.com wrote:
--- a/xen/arch/x86/mm/paging.c
+++ b/xen/arch/x86/mm/paging.c
@@ -397,6 +397,53 @@ int paging_mfn_is_dirty(struct domain *d, mfn_t gmfn)
return rv;
}
+static inline void *map_dirty_bitmap(XEN_GUEST_HANDLE_64(uint8) dirty_bitmap,
+ unsigned long pages,
+ struct page_info **page,
+ unsigned long *mapped_page)
+{
+p2m_type_t p2mt;
+uint32_t pfec;
+unsigned long gfn;
+
+gfn = paging_gva_to_gfn(current,
+(paddr_t)(((char *)dirty_bitmap.p) + (pages
3)),
I'd suggest dropping the parentheses around the inner cast - they
make this more difficult to read, and I think any C programmer
should know that unary ops have precedence over binary ones.
+pfec);
+if ( gfn == INVALID_GFN )
+return NULL;
+
+*page = get_page_from_gfn(current-domain, gfn, p2mt, P2M_UNSHARE);
+
+if ( !p2m_is_ram(p2mt) )
+{
+put_page(*page);
+return NULL;
+}
+if ( p2m_is_paging(p2mt) )
+{
+put_page(*page);
+p2m_mem_paging_populate(current-domain, gfn);
+return NULL;
+}
+if ( p2m_is_shared(p2mt) || p2m_is_discard_write(p2mt) )
+{
+put_page(*page);
+return NULL;
+}
+
+*mapped_page = pages;
You only ever store the passed in value of pages into
*mapped_pages - what's the point of this? If the caller needs
to track the value it passes here, it should simple make a copy
itself if so needed.
Apart from that both parameter names don't really seem to
express their purpose.
@@ -409,9 +456,23 @@ static int paging_log_dirty_op(struct domain *d,
mfn_t *l4 = NULL, *l3 = NULL, *l2 = NULL;
unsigned long *l1 = NULL;
int i4, i3, i2;
+uint8_t *dirty_bitmap = NULL;
Pointless initializer.
+struct page_info *page;
+unsigned long index_mapped = 0;
if ( !resuming )
domain_pause(d);
+
+dirty_bitmap = map_dirty_bitmap(sc-dirty_bitmap,
+resuming ?
+
d-arch.paging.preempt.log_dirty.done :
+0,
+page, index_mapped);
+if ( dirty_bitmap == NULL )
+{
+domain_unpause(d);
+return -EFAULT;
+}
paging_lock(d);
Blank line above that one please.
@@ -471,15 +534,29 @@ static int paging_log_dirty_op(struct domain *d,
bytes = (unsigned int)((sc-pages - pages + 7) 3);
if ( likely(peek) )
{
-if ( (l1 ? copy_to_guest_offset(sc-dirty_bitmap,
-pages 3, (uint8_t
*)l1,
-bytes)
- : clear_guest_offset(sc-dirty_bitmap,
- pages 3, bytes)) != 0 )
+if ( pages (3 + PAGE_SHIFT) !=
+ index_mapped (3 + PAGE_SHIFT) )
{
-rv = -EFAULT;
-goto out;
+/* We need to map next page */
+paging_unlock(d);
+unmap_dirty_bitmap(dirty_bitmap, page);
+dirty_bitmap = map_dirty_bitmap(sc-dirty_bitmap,
pages,
+page,
index_mapped);
+paging_lock(d);
+if ( dirty_bitmap == NULL )
+{
+rv = -EFAULT;
+goto out;
+}
+goto again;
This won't work: The paging lock protects all of
d-arch.paging.preempt.log_dirty, of which you hold cached values
in local variables.
+BUG_ON(((pages 3) % PAGE_SIZE) + bytes PAGE_SIZE);
I don't seem to be able to spot the original for this one. If there
was none, please make this an ASSERT() instead.
+if ( l1 )
+memcpy(dirty_bitmap + ((pages 3) % PAGE_SIZE),
+ (uint8_t *)l1, bytes);
Pointless cast.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v1 3/3] xen/arm: smmu: Renaming struct iommu_domain *domain to, struct iommu_domain *iommu_domain
Hi Julien/Ian, From: Julien Grall julien.grall@gmail.com Sent: Tuesday, April 14, 2015 5:16 PM To: Ian Campbell; Julien Grall Cc: prasun.kap...@cavium.com; Stefano Stabellini; Jaggi, Manish; Julien Grall; Xen Devel; Kumar, Vijaya Subject: Re: [Xen-devel] [PATCH v1 3/3] xen/arm: smmu: Renaming struct iommu_domain *domain to, struct iommu_domain *iommu_domain Hi Ian, On 14/04/15 12:15, Ian Campbell wrote: On Mon, 2015-04-06 at 16:15 +0200, Julien Grall wrote: Hi Ian, On 01/04/2015 10:30, Ian Campbell wrote: On Tue, 2015-03-31 at 17:48 +0100, Stefano Stabellini wrote: If it helps we could add a couple of comments on top of the structs in smmu.c to explain the meaning of the fields, like: /* iommu_domain, not to be confused with a Xen domain */ I was going to suggest something similar but more expansive, i.e. a table of them all in one place (i.e. at the top of the file) for ease of referencing: Struct NameWhat Wherefrom Normally found in - iommu_domain IOMMU ContextLinux d-arch.blah arch_smmu_xen_device Device specific Xen device-arch.blurg The actual name of the structure is arm_smmu_xen_device not arch_smmu_xen_device. Did you suggest to rename the name? No, I was just suggesting someone should create such a table with actual current information, instead of made up filler, in it. (you'll notice that there is, hopefully, no field blah in d-arch either nor device-arch.blurg in the tree either and please don't rename the field to match those ;-)). Thanks for the clarification. I wanted a confirmation because on another thread [1], Manish said you were suggested a new name. I think a table describing the different structure would be nice. [manish] Table is indeed a good option, but I think changing the name of arm_smmu_xen_device to something like arch_smmu_device make more sense as arm_smmu_xen_device and arm_smmu_device are not differentiable just by name. Regards, [1] http://lists.xenproject.org/archives/html/xen-devel/2015-04/msg00473.html -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Xen 4.6 Development Update (three months reminder)
From: xen-devel-boun...@lists.xen.org xen-devel-boun...@lists.xen.org on behalf of wei.l...@citrix.com wei.l...@citrix.com Sent: Tuesday, April 14, 2015 3:57 PM To: xen-de...@lists.xenproject.org; edmund.h.wh...@intel.com; xumengpa...@gmail.com; dgol...@seas.upenn.edu; jtwea...@hawaii.edu; oleksandr.dmytrys...@globallogic.com; cheg...@amazon.de; daniel.ki...@oracle.com; george.dun...@eu.citrix.com; rcojoc...@bitdefender.com; chao.p.p...@linux.intel.com; feng...@intel.com; dario.faggi...@citrix.com; ross.lagerw...@citrix.com; malcolm.cross...@citrix.com; kai.hu...@linux.intel.com; tiejun.c...@intel.com; boris.ostrov...@oracle.com; elena.ufimts...@oracle.com; tamas.leng...@zentific.com; Kumar, Vijaya; parth.di...@linaro.org; ian.campb...@citrix.com; andrii.tseglyts...@globallogic.com; suravee.suthikulpa...@amd.com; julien.gr...@linaro.org; manishjaggi@gmail.com; vijay.kil...@gmail.com; vkuzn...@redhat.com; fabio.fant...@m2r.biz; ian.jack...@eu.citrix.com; dsl...@verizon.com; cy...@suse.com; jgr...@suse.com; o...@aepfle.de; we...@cn.fujitsu.com; guijianf...@cn.fujitsu.com; andrew.coop...@citrix.com; david.vra...@citrix.com; bob@oracle.com; yan...@cn.fujitsu.com; roger@citrix.com; konrad.w...@oracle.com; eshel...@pobox.com; wei.l...@citrix.com; eddie.d...@intel.com; julien.gr...@citrix.com; anthony.per...@citrix.com; tal...@gmail.com; artem.myga...@globallogic.com; robert...@intel.com; wei.l...@citrix.com; edgar.igles...@gmail.com; frediano.zig...@huawei.com; ard.biesheu...@linaro.org; quan...@intel.com; oleksandr.tyshche...@globallogic.com Subject: [Xen-devel] Xen 4.6 Development Update (three months reminder) Hi all We are now three months into 4.6 development window. This is an email to keep track of all the patch series I gathered. It is by no means complete and / or acurate. Feel free to reply this email with new projects or correct my misunderstanding. = Timeline = We are planning on a 9-month release cycle, but we could also release a bit earlier if everything goes well (no blocker, no critical bug). * Development start: 6 Jan 2015 === We are here === * Feature Freeze: 10 Jul 2015 * RCs: TBD * Release Date: 9 Oct 2015 (could release earlier) The RCs and release will of course depend on stability and bugs, and will therefore be fairly unpredictable. Bug-fixes, if Acked-by by maintainer, can go anytime before the First RC. Later on we will need to figure out the risk of regression/reward to eliminate the possiblity of a bug introducing another bug. = Prognosis = The states are: none - fair - ok - good - done none - nothing yet fair - still working on it, patches are prototypes or RFC ok - patches posted, acting on review good - some last minute pieces done - all done, might have bugs = Bug Fixes = Bug fixes can be checked in without a freeze exception throughout the freeze, unless the maintainer thinks they are particularly high risk. In later RC's, we may even begin rejecting bug fixes if the broken functionality is small and the risk to other functionality is high. Document changes can go in anytime if the maintainer is OK with it. These are guidelines and principles to give you an idea where we're coming from; if you think there's a good reason why making an exception for you will help us make Xen better than not doing so, feel free to make your case. == Hypervisor == * Alternate p2m: support multiple copies of host p2m (ok) - Ed White * Improve RTDS scheduler (none) - Dagaen Golomb, Meng Xu * Credit2: introduce per-vcpu hard and soft affinity (good) - Justin T. Weaver * sndif: add API for para-virtual sound (fair) v7 posted - Oleksandr Dmytryshyn * gnttab: improve scalability (good) v5 posted - Christoph Egger * Display IO topology when PXM data is available (good) v3 posted - Boris Ostrovsky * Xen multiboot2-EFI support (fair) See http://lists.xen.org/archives/html/xen-devel/2013-05/msg02281.html RFC posted - Daniel Kiper * Credit2 production ready (none) cpu pinning, numa affinity and cpu reservation - George Dunlap * VM event patches (none) Add support for XSETBV vm_events, Support hybernating guests Support for VMCALL-based vm_events - Razvan Cojocaru === Hypervisor X86 === * Intel Cache Allocation Technology (good) - Chao Peng * VT-d Posted-interrupt (PI) (none) - Wu, Feng * HT enabled with credit has 7.9 per perf drop. (none) kernbench demonstrated it http://www.gossamer-threads.com/lists/xen/devel/339409 This has existed since credit1 introduction. - Dario Faggioli * Support controlling the max C-state sub-state (fair) v3 posted Hadn't see the patch reposted. - Ross Lagerwall * IOMMU ABI for guests to map their DMA regions (fair) - Malcolm Crossley * Intel PML (Page Modification Logging) for Xen (none) design doc posted - Kai Huang * RMRR fix (fair) RFC posted - Tiejun Chen * VPMU
Re: [Xen-devel] [PATCH] new functions libxl_bitmap_{or,and}
Hi Linda,
Hi Linda,
On 14/04/15 13:14, Linda wrote:
On 4/14/2015 3:19 AM, Wei Liu wrote:
Thanks, we're getting there. If my comments confuse you please just ask
for clarification.
There is no need to change the subject line. However, it would be
useful if you have some kind of version number in you subject line. That
is
[PATCH vX] libxl: provide libxl_bimap_{and,or}
You can do this by supplying --subject-prefix= to git format-patch
git format-patch -1 --subject-prefix=[PATCH vX] ...
What version do you want me to use at this point? I've sort of lost
count, since many changes have been style changes.
IIRC, this is the v3, so the next will be v4.
I am assuming you usually reserve new versions for substantive changes?
The version number should be incremented every time you send a new
version of the patch to the mailing list.
where X refers to your version number.
On Mon, Apr 13, 2015 at 01:47:18AM -0600, Linda Jacobson wrote:
provide logical and and or of two bitmaps
And the SoB line should be here.
What does SoB stand for in this context?
Signed-off-by.
As said on a previous mail, everything after --- will be dropped when
the committer will apply your patch to the tree. So your SoB will
disappear too.
You have to move it before the ---
---
v.1 updated comments and format
v.2 rewrote bitmap functions to manipulate bytes not bits
Signed-off-by: Linda Jacobson lin...@jma3.com
[..]
+int libxl_bitmap_or(libxl_ctx *ctx, libxl_bitmap *or_map,
+libxl_bitmap *map1, libxl_bitmap *map2)
Actually I think you need to constify map1 and map2. I.e.
const libxl_bitmap *map1,
const libxl_bitmap *map2)
How come? Out of curiosity.
You know that the 2 bitmaps won't be modified within function.
Constifying them will allow the compiler to catch any attempt to modify
the content of the bitmap.
Regards,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/1] xc_domain_restore: Allow QEMU to increase memory
On Tue, Apr 14, 2015 at 05:40:24PM +0800, Hongyang Yang wrote: On 04/14/2015 05:29 PM, Wei Liu wrote: On Tue, Apr 14, 2015 at 05:22:31PM +0800, Hongyang Yang wrote: [...] If I understand correctly, the steps are this: * 'xl create' makes a VM of size $FOO * qemu bumps the size to $FOO+$N * 'xl save' writes $FOO+$N of page data, but the xl config file at the start of the image still says $FOO * 'xl restore' creates a vm of size $FOO, then instructs xc_domain_restore() to put $FOO+$N pages into it. I would argue first, that qemu should not play in this area to start with. However, the real bug here is that the domain configuration written by xl save is inaccurate. There's a case like COLO: 1. Both Primary/Secondary VM are created first with the same config file which makes a VM of size $FOO 2. qemu bumps the size to $FOO+$N 3. 'save' writes $FOO+$N of page data 4. 'restore' put $FOO+$N pages into $FOO pages which will cause error Even if you fix the configuration, the bug still exists because the config only been transferred from Primary to Secondary once at the very beginning when you execute 'xl remus' command. The problem is how to let the secondary (restore) side knows the size change? Through a migration command(which is easier in v2 migration) or some other solution? As I said in my reply to Don, the extra memory can be saved during domain creation. That would solve this problem. After migration we'll enter COLO mode, which will continously send migration stream to Secondary. Domain creation only happens before doing live migration. Because now the correct value is recorded during domain creation, it will always be sent to the other end, so there is no need for this kind of hack. Wei. Wei. Form this point of view, I think Don's solution is one way to solve the problem. ~Andrew . -- Thanks, Yang. . -- Thanks, Yang. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Size of irq field
On Fri, 2015-04-03 at 15:31 +0200, Julien Grall wrote: Also, as we plan to use passtrough, we there are such places: In tools/libxc/include/xenctrl.h: int xc_domain_bind_pt_irq(xc_interface *xch, uint32_t domid, *uint8_t* machine_irq, uint8_t irq_type, uint8_t bus, uint8_t device, uint8_t intx, uint8_t isa_irq); int xc_domain_unbind_pt_irq(xc_interface *xch, uint32_t domid, *uint8_t* machine_irq, uint8_t irq_type, uint8_t bus, uint8_t device, uint8_t intx, uint8_t isa_irq); int xc_domain_bind_pt_pci_irq(xc_interface *xch, uint32_t domid, *uint8_t* machine_irq, uint8_t bus, uint8_t device, uint8_t intx); int xc_domain_bind_pt_isa_irq(xc_interface *xch, uint32_t domid, *uint8_t* machine_irq); And theirs implementation in tools/libxc/xc_domain.c Whoops. I didn't spot those one thanks. libxc is not ABI stable, we can make these bigger if necessary, or introduce new interface etc as required depending on how things pan out at the hypercall layer. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 2/2] xen/arm: Make HAS_PCI compilable on ARM by adding place-holder code
On 14/04/15 10:28, Stefano Stabellini wrote:
On Tue, 14 Apr 2015, Jaggi, Manish wrote:
diff --git a/xen/include/asm-arm/pci.h b/xen/include/asm-arm/pci.h
index de13359..b8ec882 100644
--- a/xen/include/asm-arm/pci.h
+++ b/xen/include/asm-arm/pci.h
@@ -1,7 +1,8 @@
-#ifndef __X86_PCI_H__
-#define __X86_PCI_H__
+#ifndef __ARM_PCI_H__
+#define __ARM_PCI_H__
struct arch_pci_dev {
+void *dev;
void * is error-prone. Why can't you use the use the real structure?
[manish]Will change it. I believe dev_archdata structure has also a void *
(in asm-arm/device.h). So all void * are error prone in xen ?
As you know void* works around the type system, so it prevents the
compiler from making many type safety checks. We should try to avoid
them if we can.
In this case, the pointer add more management (allocation...).
As for the device tree solution, the field should be a struct device.
I think that you are right, the void *iommu in dev_archdata should
actually be struct arm_smmu_xen_device *iommu.
I agree that void* should be void in most of the case when we know the
underlaying type. Although there is some place where the number of type
of unknown because it could be used to store driver specific case.
This is actually the case of this field. It contains private data for
IOMMU driver. When a new driver will be implemented, it will likely use
a different structure.
Furthermore, the SMMU drivers is self contained in a file, using struct
arm_smmu_xen_device* would require to export/define some part of the
driver in an header.
So, I don't think this is the right things to do.
Regards,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v1 3/3] xen/arm: smmu: Renaming struct iommu_domain *domain to, struct iommu_domain *iommu_domain
On Mon, 2015-04-06 at 16:15 +0200, Julien Grall wrote: Hi Ian, On 01/04/2015 10:30, Ian Campbell wrote: On Tue, 2015-03-31 at 17:48 +0100, Stefano Stabellini wrote: If it helps we could add a couple of comments on top of the structs in smmu.c to explain the meaning of the fields, like: /* iommu_domain, not to be confused with a Xen domain */ I was going to suggest something similar but more expansive, i.e. a table of them all in one place (i.e. at the top of the file) for ease of referencing: Struct NameWhat Wherefrom Normally found in - iommu_domain IOMMU ContextLinux d-arch.blah arch_smmu_xen_device Device specific Xen device-arch.blurg The actual name of the structure is arm_smmu_xen_device not arch_smmu_xen_device. Did you suggest to rename the name? No, I was just suggesting someone should create such a table with actual current information, instead of made up filler, in it. (you'll notice that there is, hopefully, no field blah in d-arch either nor device-arch.blurg in the tree either and please don't rename the field to match those ;-)). Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] tools/libxl - Async Task Cancellation Query [and 1 more messages]
Koushik Chakravarty writes (RE: tools/libxl - Async Task Cancellation Query): When you say - That would require the caller to preserve the ao_how which seems awkward to me - whom do you refer as the caller? By the caller I mean the program outside libxl which is calling libxl. From what I picked up, the libxl_ao_cancel() API is passed with the ao_how. The libxl_ao_cancel then looks into the ctx-aos_inprogress list to find the ao that matches the ao_how. Yes. So what I was suggesting was that if the ao_how was allotted an 'id' from the original libxl api call (done using a counter increment from the global libxl ctx with a lock held), and the same id was saved in the ao entry in ctx-aos_inprogress, then searching/matching them in libxl_ao_cancel() would have been a little faster. Sorry, I had misunderstood. I thought you were proposing some kind of arrangement where libxl would be able to look up the relevant ao in O(1). That would require either the lifetime of these ids to be controlled. But now I understand that you're just proposing a pure id which still requires a search. I don't think the performance benefit is really worthwhile for the extra complexity. This is particularly true given that currently the ao_how is const. So the caller might have defined it as `static const' and put it in the text segment. Changing the API to make this parameter non-const sometimes, in a backward compatible way, would be a bit complicated. But thanks anyway for your suggestion. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RFC] xen/pvh: use a custom IO bitmap for PVH hardware domains
On 14/04/15 11:01, Roger Pau Monné wrote:
El 08/04/15 a les 14.57, Roger Pau Monne ha escrit:
Since a PVH hardware domain has access to the physical hardware create a
custom more permissive IO bitmap. The permissions set on the bitmap are
populated based on the contents of the ioports rangeset.
Also add the IO ports of the serial console used by Xen to the list of not
accessible IO ports.
I have one question about the current IO port handling for PVH guests
(DomU and Dom0). There's some code right now in vmx_vmexit_handler
(EXIT_REASON_IO_INSTRUCTION) that's kind PVH specific:
if ( exit_qualification 0x10 )
{
/* INS, OUTS */
if ( unlikely(is_pvh_vcpu(v)) /* PVH fixme */ ||
!handle_mmio() )
hvm_inject_hw_exception(TRAP_gp_fault, 0);
}
else
{
/* IN, OUT */
uint16_t port = (exit_qualification 16) 0x;
int bytes = (exit_qualification 0x07) + 1;
int dir = (exit_qualification 0x08) ? IOREQ_READ : IOREQ_WRITE;
if ( handle_pio(port, bytes, dir) )
update_guest_eip(); /* Safe: IN, OUT */
}
Is there any need for DomUs to access the IO ports?
In the case of PCI passthrough, the guest may need to use a devices IO BARs.
However, PCI passthrough and PVH is still a very open question, so
making a change here isn't really breaking anything.
I know that FreeBSD
will poke at some of them during boot to scan for devices, but I'm not
sure if we could just make them noops in the PVH case and simply return
garbage.
If anything, ~0 is what should be returned to match real hardware.
~Andrew
Also, once this is set the PVH Specification document should be updated
to reflect what can guests expect when poking at IO ports.
Roger.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] Xen 4.6 Development Update (three months reminder)
Hi all We are now three months into 4.6 development window. This is an email to keep track of all the patch series I gathered. It is by no means complete and / or acurate. Feel free to reply this email with new projects or correct my misunderstanding. = Timeline = We are planning on a 9-month release cycle, but we could also release a bit earlier if everything goes well (no blocker, no critical bug). * Development start: 6 Jan 2015 === We are here === * Feature Freeze: 10 Jul 2015 * RCs: TBD * Release Date: 9 Oct 2015 (could release earlier) The RCs and release will of course depend on stability and bugs, and will therefore be fairly unpredictable. Bug-fixes, if Acked-by by maintainer, can go anytime before the First RC. Later on we will need to figure out the risk of regression/reward to eliminate the possiblity of a bug introducing another bug. = Prognosis = The states are: none - fair - ok - good - done none - nothing yet fair - still working on it, patches are prototypes or RFC ok - patches posted, acting on review good - some last minute pieces done - all done, might have bugs = Bug Fixes = Bug fixes can be checked in without a freeze exception throughout the freeze, unless the maintainer thinks they are particularly high risk. In later RC's, we may even begin rejecting bug fixes if the broken functionality is small and the risk to other functionality is high. Document changes can go in anytime if the maintainer is OK with it. These are guidelines and principles to give you an idea where we're coming from; if you think there's a good reason why making an exception for you will help us make Xen better than not doing so, feel free to make your case. == Hypervisor == * Alternate p2m: support multiple copies of host p2m (ok) - Ed White * Improve RTDS scheduler (none) - Dagaen Golomb, Meng Xu * Credit2: introduce per-vcpu hard and soft affinity (good) - Justin T. Weaver * sndif: add API for para-virtual sound (fair) v7 posted - Oleksandr Dmytryshyn * gnttab: improve scalability (good) v5 posted - Christoph Egger * Display IO topology when PXM data is available (good) v3 posted - Boris Ostrovsky * Xen multiboot2-EFI support (fair) See http://lists.xen.org/archives/html/xen-devel/2013-05/msg02281.html RFC posted - Daniel Kiper * Credit2 production ready (none) cpu pinning, numa affinity and cpu reservation - George Dunlap * VM event patches (none) Add support for XSETBV vm_events, Support hybernating guests Support for VMCALL-based vm_events - Razvan Cojocaru === Hypervisor X86 === * Intel Cache Allocation Technology (good) - Chao Peng * VT-d Posted-interrupt (PI) (none) - Wu, Feng * HT enabled with credit has 7.9 per perf drop. (none) kernbench demonstrated it http://www.gossamer-threads.com/lists/xen/devel/339409 This has existed since credit1 introduction. - Dario Faggioli * Support controlling the max C-state sub-state (fair) v3 posted Hadn't see the patch reposted. - Ross Lagerwall * IOMMU ABI for guests to map their DMA regions (fair) - Malcolm Crossley * Intel PML (Page Modification Logging) for Xen (none) design doc posted - Kai Huang * RMRR fix (fair) RFC posted - Tiejun Chen * VPMU - 'perf' support in Xen (good) v14 posted Need reviews/final ack. - Boris Ostrovsky * PVH - AMD hardware support. (fair) RFC posted - Elena Ufimtseva * PVH dom0 (fair) RFC posted - Elena Ufimtseva === Hypervisor ARM === * Mem_access for ARM (good) v13 posted - Tamas K Lengyel * ITS support (fair ) - Vijaya Kumar K * Add ACPI support for arm64 on Xen (fair) RFC posted - Parth Dixit * ARM: reenable support 32-bit userspace running in 64-bit guest (good) v2 posted - Ian Campbell * ARM remote processor iommu module (GPUs + IPUs) (fair) v3 posted - Andrii Tseglytskyi * ARM VM save/restore/live migration (none) Need to rebased against migrationv2 - no code posted. - None * ARM GICv2m support (none) - Suravee Suthikulanit * ARM - passthrough of non-PCI (ok) - Julien Grall * ARM PCI passthrough (none) - Manish Jaggi - Vijay Kilari == Xen toolstack == * toolstack-based approach to pvhvm guest kexec (fair) also contains hypervisor side change - Vitaly Kuznetsov * libxl: add qxl vga interface support for upstream qemu (fair) - Fabio Fantoni * Toolstack-based approach to pvhvm guest kexec (ok) v4 posted - Vitaly Kuznetsov * libxl: cancelling asynchronous operations (fair) RFC posted - Ian Jackson * VMware tools support (fair) - Don Slutz * PV USB support in libxl (fair) - Chunyan Liu * HVM USB support in libxl (fair) - George Dunlap * Blktap2 support (fair) - George Dunlap * pvscsi in libxl (fair) - Juergen Gross and Olaf * COarse-grain LOck-stepping Virtual Machines in Xen (fair) RFC v5 posted - Wen Congyang - Gui Jianfeng - Yang
Re: [Xen-devel] Size of irq field
On 14/04/15 11:33, Ian Campbell wrote: Whoops. I didn't spot those one thanks. libxc is not ABI stable, we can make these bigger if necessary, or introduce new interface etc as required depending on how things pan out at the hypercall layer. FIY, a patch has been sent on the ML see [PATCH v3] increase size of irq from uint8_t to uint32_t in order to fix it. Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v1 1/2] arm: Add ability to relocate Xen in over 4GB space
On Fri, 2015-04-10 at 15:25 +0100, Julien Grall wrote: On 10/04/15 14:58, Iurii Konovalenko wrote: Hi, Julien! Hi Iurii, On Wed, Apr 8, 2015 at 7:05 PM, Julien Grall julien.gr...@citrix.com wrote: The virtualization extension requires LPAE. Any reason to make this optional? I agree with you - there is no real reason to make it optional. I will rework patch to include functionality without any flags by default. Before doing a such change, I'd like the point of view of Stefano or Ian on this patch. Such things shouldn't be compile time optional. I don't think there's any reason why it can't be done for every arm32 platform. Normally I'd ask for a command line option which can overrides (i.e. disable) this behaviour -- just in case. But I suspect that the relevant code runs too early? (I'll read the rest of this thread as I catch up with my email backlog). Ian ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] More force pushes (xen-4.5-testing, xen-unstable, qemu-mainline)
Jan Beulich writes (Re: More force pushes (xen-4.5-testing, xen-unstable, qemu-mainline)): flight 50373 xen-4.5-testing real [real] xen 0b754fb3ed6b7b6d0f2e1f7c1877d3c0a7da2168 flight 50390 xen-unstable real [real] xen 123c7793797502b222300eb710cd3873dcca41ee flight 50391 qemu-mainline real [real] qemuu58c24a4775ef7ccf16cfcd695753dfdf149fe29d Ack for all three of them. Now pushed. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [ovmf test] 50403: regressions - FAIL
flight 50403 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/50403/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-freebsd10-i386 10 guest-start fail REGR. vs. 36764 test-amd64-i386-freebsd10-amd64 13 guest-localmigrate fail REGR. vs. 36764 Regressions which are regarded as allowable (not blocking): test-amd64-i386-pair21 guest-migrate/src_host/dst_host fail like 36764 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 9 debian-hvm-install fail never pass test-amd64-i386-xl-xsm 11 guest-start fail never pass test-amd64-i386-libvirt-xsm 11 guest-start fail never pass test-amd64-amd64-libvirt-xsm 11 guest-start fail never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail never pass test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 9 debian-hvm-install fail never pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-amd64-xl-xsm 11 guest-start fail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail never pass test-amd64-amd64-xl-winxpsp3 16 guest-stop fail never pass test-amd64-i386-xl-qemut-winxpsp3-vcpus1 16 guest-stop fail never pass test-amd64-amd64-xl-win7-amd64 16 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass test-amd64-amd64-xl-qemut-winxpsp3 16 guest-stop fail never pass test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 16 guest-stop fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 16 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 16 guest-stop fail never pass test-amd64-i386-xl-qemuu-winxpsp3 16 guest-stopfail never pass test-amd64-i386-xl-winxpsp3-vcpus1 16 guest-stop fail never pass test-amd64-i386-xl-qemut-winxpsp3 16 guest-stopfail never pass test-amd64-i386-xl-winxpsp3 16 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail never pass version targeted for testing: ovmf 494820d8c8348d9b3d93b8cc18fb813633c434f7 baseline version: ovmf 785d183b4eae6ac2749d1ffdc1b67facf92610e6 People who touched revisions under test: Bob Feng bob.c.f...@intel.com Chen, Hesheng hesheng.c...@intel.com Ard Biesheuvel ard.biesheu...@linaro.org Bob Feng bob.c.f...@intel.com Chen, Hesheng hesheng.c...@intel.com David Woodhouse david.woodho...@intel.com Elvin Li elvin...@intel.com Felix Polyudov fel...@ami.com Feng Tian feng.t...@intel.com Fu Siyuan siyuan...@intel.com Gabriel Somlo so...@cmu.edu Hao Wu hao.a...@intel.com Jeff Fan jeff@intel.com Jordan Justen jordan.l.jus...@intel.com Laszlo Ersek ler...@redhat.com laurie0131 laurie.jarlst...@intel.com lhauch larry.ha...@intel.com Liming Gao liming@intel.com Maurice Ma maurice...@intel.com Olivier Martin olivier.mar...@arm.com Prince Agyeman prince.agye...@intel.com Qiu Shumin shumin@intel.com Ronald Cron ronald.c...@arm.com Scott Duplichan sc...@notabs.org Shifei Lu shifeix.a...@intel.com Star Zeng star.z...@intel.com Tapan Shah tapands...@hp.com jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-amd64-amd64-xl-qemut-debianhvm-amd64-xsmfail test-amd64-i386-xl-qemut-debianhvm-amd64-xsm fail test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmfail test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm fail
Re: [Xen-devel] [PATCH RFC] xen/pvh: use a custom IO bitmap for PVH hardware domains
El 08/04/15 a les 14.57, Roger Pau Monne ha escrit:
Since a PVH hardware domain has access to the physical hardware create a
custom more permissive IO bitmap. The permissions set on the bitmap are
populated based on the contents of the ioports rangeset.
Also add the IO ports of the serial console used by Xen to the list of not
accessible IO ports.
I have one question about the current IO port handling for PVH guests
(DomU and Dom0). There's some code right now in vmx_vmexit_handler
(EXIT_REASON_IO_INSTRUCTION) that's kind PVH specific:
if ( exit_qualification 0x10 )
{
/* INS, OUTS */
if ( unlikely(is_pvh_vcpu(v)) /* PVH fixme */ ||
!handle_mmio() )
hvm_inject_hw_exception(TRAP_gp_fault, 0);
}
else
{
/* IN, OUT */
uint16_t port = (exit_qualification 16) 0x;
int bytes = (exit_qualification 0x07) + 1;
int dir = (exit_qualification 0x08) ? IOREQ_READ : IOREQ_WRITE;
if ( handle_pio(port, bytes, dir) )
update_guest_eip(); /* Safe: IN, OUT */
}
Is there any need for DomUs to access the IO ports? I know that FreeBSD
will poke at some of them during boot to scan for devices, but I'm not
sure if we could just make them noops in the PVH case and simply return
garbage.
Also, once this is set the PVH Specification document should be updated
to reflect what can guests expect when poking at IO ports.
Roger.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RFC] xen/pvh: use a custom IO bitmap for PVH hardware domains
On 14.04.15 at 12:01, roger@citrix.com wrote:
I have one question about the current IO port handling for PVH guests
(DomU and Dom0). There's some code right now in vmx_vmexit_handler
(EXIT_REASON_IO_INSTRUCTION) that's kind PVH specific:
if ( exit_qualification 0x10 )
{
/* INS, OUTS */
if ( unlikely(is_pvh_vcpu(v)) /* PVH fixme */ ||
!handle_mmio() )
hvm_inject_hw_exception(TRAP_gp_fault, 0);
}
else
{
/* IN, OUT */
uint16_t port = (exit_qualification 16) 0x;
int bytes = (exit_qualification 0x07) + 1;
int dir = (exit_qualification 0x08) ? IOREQ_READ : IOREQ_WRITE;
if ( handle_pio(port, bytes, dir) )
update_guest_eip(); /* Safe: IN, OUT */
}
Is there any need for DomUs to access the IO ports? I know that FreeBSD
will poke at some of them during boot to scan for devices, but I'm not
sure if we could just make them noops in the PVH case and simply return
garbage.
The PVH special case quoted above is there only to prevent
reaching handle_mmio(). The non-string else path was enabled
solely on the basis that it was possible to be made work without
much extra effort. And while (without pass-through) it shouldn't
be needed for PVH DomU-s, it also should do no harm.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RFC] xen/pvh: use a custom IO bitmap for PVH hardware domains
Hello,
El 14/04/15 a les 12.31, Jan Beulich ha escrit:
On 14.04.15 at 12:01, roger@citrix.com wrote:
I have one question about the current IO port handling for PVH guests
(DomU and Dom0). There's some code right now in vmx_vmexit_handler
(EXIT_REASON_IO_INSTRUCTION) that's kind PVH specific:
if ( exit_qualification 0x10 )
{
/* INS, OUTS */
if ( unlikely(is_pvh_vcpu(v)) /* PVH fixme */ ||
!handle_mmio() )
hvm_inject_hw_exception(TRAP_gp_fault, 0);
}
else
{
/* IN, OUT */
uint16_t port = (exit_qualification 16) 0x;
int bytes = (exit_qualification 0x07) + 1;
int dir = (exit_qualification 0x08) ? IOREQ_READ : IOREQ_WRITE;
if ( handle_pio(port, bytes, dir) )
update_guest_eip(); /* Safe: IN, OUT */
}
Is there any need for DomUs to access the IO ports? I know that FreeBSD
will poke at some of them during boot to scan for devices, but I'm not
sure if we could just make them noops in the PVH case and simply return
garbage.
The PVH special case quoted above is there only to prevent
reaching handle_mmio().
Injecting a GP seems like a little bit too much for trapped INS/OUTS, I
would rather just drop/ignore them if possible.
The non-string else path was enabled
solely on the basis that it was possible to be made work without
much extra effort. And while (without pass-through) it shouldn't
be needed for PVH DomU-s, it also should do no harm.
Ack.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 2/3] xen/x86: Use real assert frames for ASSERT_INTERRUPTS_{EN, DIS}ABLED
Signed-off-by: Andrew Cooper andrew.coop...@citrix.com CC: Keir Fraser k...@xen.org CC: Jan Beulich jbeul...@suse.com --- v2: Pass msg as a second parameter rather than duplicating ASSERT_INTERRUPT_STATUS --- xen/include/asm-x86/asm_defns.h | 13 - 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/xen/include/asm-x86/asm_defns.h b/xen/include/asm-x86/asm_defns.h index 1674c7c..7c8c2c0 100644 --- a/xen/include/asm-x86/asm_defns.h +++ b/xen/include/asm-x86/asm_defns.h @@ -6,6 +6,7 @@ /* NB. Auto-generated from arch/.../asm-offsets.c */ #include asm/asm-offsets.h #endif +#include asm/bug.h #include asm/processor.h #include asm/percpu.h #include xen/stringify.h @@ -26,18 +27,20 @@ #endif #ifndef NDEBUG -#define ASSERT_INTERRUPT_STATUS(x) \ +#define ASSERT_INTERRUPT_STATUS(x, msg) \ pushf; \ testb $X86_EFLAGS_IF8,1(%rsp);\ j##x 1f; \ -ud2a; \ +ASSERT_FAILED(msg); \ 1: addq $8,%rsp; #else -#define ASSERT_INTERRUPT_STATUS(x) +#define ASSERT_INTERRUPT_STATUS(x, msg) #endif -#define ASSERT_INTERRUPTS_ENABLED ASSERT_INTERRUPT_STATUS(nz) -#define ASSERT_INTERRUPTS_DISABLED ASSERT_INTERRUPT_STATUS(z) +#define ASSERT_INTERRUPTS_ENABLED \ +ASSERT_INTERRUPT_STATUS(nz, INTERRUPTS ENABLED) +#define ASSERT_INTERRUPTS_DISABLED \ +ASSERT_INTERRUPT_STATUS(z, INTERRUPTS DISABLED) /* * This flag is set in an exception frame when registers R12-R15 did not get -- 1.7.10.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V8 00/12] xen: Clean-up of mem_event subsystem
On Thu, 2015-04-09 at 12:30 +0100, Tim Deegan wrote: What's the policy on reusing DOMCTL numbers? I see XEN_DOMCTL_arm_configure_domain has been retired in the conflicting patch. Should I just reuse it's number for monitor_op? For the most part domctl numbers seem to be continuous but there are holes (30-32) so I'm not sure. I'm not sure either. I'd be inlclined to leave a hole here, to avoid any accidental confusion with the recently-removed op, but other maintainers may disagree. :) I also think we should leave a hole. And perhaps we should have left a previous used as type comment when removing arm_configure_domain, sorry for not thinking of that at the time... Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 2/2] xen/arm: Make HAS_PCI compilable on ARM by adding place-holder code
On 14/04/15 11:33, Julien Grall wrote:
On 14/04/15 10:28, Stefano Stabellini wrote:
On Tue, 14 Apr 2015, Jaggi, Manish wrote:
diff --git a/xen/include/asm-arm/pci.h b/xen/include/asm-arm/pci.h
index de13359..b8ec882 100644
--- a/xen/include/asm-arm/pci.h
+++ b/xen/include/asm-arm/pci.h
@@ -1,7 +1,8 @@
-#ifndef __X86_PCI_H__
-#define __X86_PCI_H__
+#ifndef __ARM_PCI_H__
+#define __ARM_PCI_H__
struct arch_pci_dev {
+void *dev;
void * is error-prone. Why can't you use the use the real structure?
[manish]Will change it. I believe dev_archdata structure has also a void *
(in asm-arm/device.h). So all void * are error prone in xen ?
As you know void* works around the type system, so it prevents the
compiler from making many type safety checks. We should try to avoid
them if we can.
In this case, the pointer add more management (allocation...).
As for the device tree solution, the field should be a struct device.
I think that you are right, the void *iommu in dev_archdata should
actually be struct arm_smmu_xen_device *iommu.
I agree that void* should be void in most of the case when we know the
underlaying type. Although there is some place where the number of type
of unknown because it could be used to store driver specific case.
This is actually the case of this field. It contains private data for
IOMMU driver. When a new driver will be implemented, it will likely use
a different structure.
Furthermore, the SMMU drivers is self contained in a file, using struct
arm_smmu_xen_device* would require to export/define some part of the
driver in an header.
A similar example would be the scheduler coder (see sched_data in
include/xen/sched-if.h). We don't want to expose the underlying
structure out of the file.
Regards,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] Xen 4.6 Development Update (three months reminder)
On 04/14/2015 11:27 AM, wei.l...@citrix.com wrote: == Hypervisor == * Alternate p2m: support multiple copies of host p2m (ok) - Ed White * Improve RTDS scheduler (none) - Dagaen Golomb, Meng Xu This is a little vague... exactly what kinds of improvements are envisioned here? * Credit2: introduce per-vcpu hard and soft affinity (good) - Justin T. Weaver Still good (Probably in part awaiting my further review -- should get to that this week) * Credit2 production ready (none) cpu pinning, numa affinity and cpu reservation - George Dunlap The first two are identical to Justin Weaver's patch; you might want to note that. No work on CPU reservation yet. * PV USB support in libxl (fair) - Chunyan Liu * HVM USB support in libxl (fair) - George Dunlap Haven't heard anything on the first one in a while; the second one is basically blocked on the first. * Blktap2 support (fair) - George Dunlap Working on integrating this with raisin; still fair by the definitions above. -George ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Xen 4.6 Development Update (three months reminder)
On Tue, Apr 14, 2015 at 12:27 PM, wei.l...@citrix.com wrote: Hi all We are now three months into 4.6 development window. This is an email to keep track of all the patch series I gathered. It is by no means complete and / or acurate. Feel free to reply this email with new projects or correct my misunderstanding. = Timeline = We are planning on a 9-month release cycle, but we could also release a bit earlier if everything goes well (no blocker, no critical bug). * Development start: 6 Jan 2015 === We are here === * Feature Freeze: 10 Jul 2015 * RCs: TBD * Release Date: 9 Oct 2015 (could release earlier) The RCs and release will of course depend on stability and bugs, and will therefore be fairly unpredictable. Bug-fixes, if Acked-by by maintainer, can go anytime before the First RC. Later on we will need to figure out the risk of regression/reward to eliminate the possiblity of a bug introducing another bug. = Prognosis = The states are: none - fair - ok - good - done none - nothing yet fair - still working on it, patches are prototypes or RFC ok - patches posted, acting on review good - some last minute pieces done - all done, might have bugs = Bug Fixes = Bug fixes can be checked in without a freeze exception throughout the freeze, unless the maintainer thinks they are particularly high risk. In later RC's, we may even begin rejecting bug fixes if the broken functionality is small and the risk to other functionality is high. Document changes can go in anytime if the maintainer is OK with it. These are guidelines and principles to give you an idea where we're coming from; if you think there's a good reason why making an exception for you will help us make Xen better than not doing so, feel free to make your case. == Hypervisor == * Alternate p2m: support multiple copies of host p2m (ok) - Ed White * Improve RTDS scheduler (none) - Dagaen Golomb, Meng Xu * Credit2: introduce per-vcpu hard and soft affinity (good) - Justin T. Weaver * sndif: add API for para-virtual sound (fair) v7 posted - Oleksandr Dmytryshyn * gnttab: improve scalability (good) v5 posted - Christoph Egger * Display IO topology when PXM data is available (good) v3 posted - Boris Ostrovsky * Xen multiboot2-EFI support (fair) See http://lists.xen.org/archives/html/xen-devel/2013-05/msg02281.html RFC posted - Daniel Kiper * Credit2 production ready (none) cpu pinning, numa affinity and cpu reservation - George Dunlap * VM event patches (none) Add support for XSETBV vm_events, Support hybernating guests Support for VMCALL-based vm_events - Razvan Cojocaru === Hypervisor X86 === * Intel Cache Allocation Technology (good) - Chao Peng * VT-d Posted-interrupt (PI) (none) - Wu, Feng * HT enabled with credit has 7.9 per perf drop. (none) kernbench demonstrated it http://www.gossamer-threads.com/lists/xen/devel/339409 This has existed since credit1 introduction. - Dario Faggioli * Support controlling the max C-state sub-state (fair) v3 posted Hadn't see the patch reposted. - Ross Lagerwall * IOMMU ABI for guests to map their DMA regions (fair) - Malcolm Crossley * Intel PML (Page Modification Logging) for Xen (none) design doc posted - Kai Huang * RMRR fix (fair) RFC posted - Tiejun Chen * VPMU - 'perf' support in Xen (good) v14 posted Need reviews/final ack. - Boris Ostrovsky * PVH - AMD hardware support. (fair) RFC posted - Elena Ufimtseva * PVH dom0 (fair) RFC posted - Elena Ufimtseva === Hypervisor ARM === * Mem_access for ARM (good) v13 posted - Tamas K Lengyel v14 has been posted as well, v15 will be sent this week. * ITS support (fair ) - Vijaya Kumar K * Add ACPI support for arm64 on Xen (fair) RFC posted - Parth Dixit * ARM: reenable support 32-bit userspace running in 64-bit guest (good) v2 posted - Ian Campbell * ARM remote processor iommu module (GPUs + IPUs) (fair) v3 posted - Andrii Tseglytskyi * ARM VM save/restore/live migration (none) Need to rebased against migrationv2 - no code posted. - None * ARM GICv2m support (none) - Suravee Suthikulanit * ARM - passthrough of non-PCI (ok) - Julien Grall * ARM PCI passthrough (none) - Manish Jaggi - Vijay Kilari == Xen toolstack == * toolstack-based approach to pvhvm guest kexec (fair) also contains hypervisor side change - Vitaly Kuznetsov * libxl: add qxl vga interface support for upstream qemu (fair) - Fabio Fantoni * Toolstack-based approach to pvhvm guest kexec (ok) v4 posted - Vitaly Kuznetsov * libxl: cancelling asynchronous operations (fair) RFC posted - Ian Jackson * VMware tools support (fair) - Don Slutz * PV USB support in libxl (fair) - Chunyan Liu * HVM USB
Re: [Xen-devel] Xen 4.6 Development Update (three months reminder)
On 14/04/15 11:27, wei.l...@citrix.com wrote: === Hypervisor X86 === * VT-d Posted-interrupt (PI) (none) - Wu, Feng V1 posted * Intel PML (Page Modification Logging) for Xen (none) design doc posted - Kai Huang V1 posted (good) * PVH - AMD hardware support. (fair) RFC posted - Elena Ufimtseva I am not aware of any patches along these lines? == Xen toolstack == * New Migration (v2). (good) v9 (libxc) git://xenbits.xen.org/people/andrewcoop/xen.git Seems that it might need to slip or we run v1 alongside v2. - Andrew Cooper David Vrabel Hopefully no need to slip, but there are very good reasons to run v1 alongside v2. * PVH - Migration of guests from a PVH dom0 (none) Depends on migration2 code - Roger Pau Monné v1 posted. == Deferred == * ucode=scan also scan compressed initramfs (none) - Konrad Rzeszutek Wilk * adjust log buffer based on memmap size (none) - Konrad Rzeszutek Wilk * Further tmem cleanups/fixes (fair) - Bob Liu * 1TB slow destruction (ok) - Bob Liu * cpuid leveling (none) http://xenbits.xen.org/people/andrewcoop/feature-levelling/feature-levelling-D.pdf - Andrew Cooper Now starting active work on this, but I can't say yet whether it is even plausible to be done in the 4.6 timeframe. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCHv2 3/6] xen: generic xadd() for ticket locks
On 14/04/15 14:17, Ian Campbell wrote: On Fri, 2015-04-10 at 15:19 +0100, David Vrabel wrote: This is only temporary until arm/arm64 provides an xadd() implementation. I'll assume that you aren't planning on doing this and add it to my own TODO list. Although, I'm more than willing to be preempted by another ARM dev... Thanks. I'd hoped I could lift something from Linux but there's nothing directly suited. David ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [[PATCH v4]] new functions libxl_bitmap_{or,and}
Urgh... I think I made a mistake in the rune I gave you, sorry. The
--subject-prefix= doesn't need to include [].
And you forgot to change the subject line to
libxl: provide libxl_bitmap_{and,or}
I'm a picky about the subject line because this is what shows up when
you look at git commit log.
On Tue, Apr 14, 2015 at 08:07:59AM -0600, Linda Jacobson wrote:
provide logical and and or of two bitmaps
Provide logical and and or of two bitmaps.
This should be a proper sentence.
Other than these minor nits the code logic looks OK.
Signed-off-by: Linda Jacobson lin...@jma3.com
---
[...]
+int libxl_bitmap_and(libxl_ctx *ctx, libxl_bitmap *and_map,
+ const libxl_bitmap *map1, const libxl_bitmap *map2)
+{
+GC_INIT(ctx);
+int rc;
+uint32_t i;
+const libxl_bitmap *large_map;
+const libxl_bitmap *small_map;
+
+if (map1-size map2-size) {
+large_map = map1;
+small_map = map2;
+} else {
+large_map = map2;
+small_map = map1;
+}
+
+
We only need one blank line here.
+rc = libxl_bitmap_alloc(ctx, and_map, small_map-size * 8);
+if (rc)
+goto out;
+
+/*
+ * If bitmaps aren't same size, their 'and' will be size of
+ * smaller bit map
+ */
+for (i = 0; i and_map-size; i++)
+and_map-map[i] = (large_map-map[i] small_map-map[i]);
+
+out:
+GC_FREE;
+return rc;
+
No need to have blank lines after return rc;
Wei.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH OSSTEST v4 08/25] make-flight: Handle $BUILD_LVEXTEND_MAX in mfi-common:create_build_jobs()
Ian Campbell writes ([PATCH OSSTEST v4 08/25] make-flight: Handle $BUILD_LVEXTEND_MAX in mfi-common:create_build_jobs()): Signed-off-by: Ian Campbell ian.campb...@citrix.com Acked-by: Ian Jackson ian.jack...@eu.citrix.com ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] wating for backend changes (was Re: [PATCH v3 4/4] libxl: add support for vscsi)
On Fri, Apr 10, Olaf Hering wrote: How is new code supposed to wait for backend changes? Right now there are two APIs for that: - libxl__wait_for_backend loops for a while until it returns an error. - libxl__ev_devstate_wait registers a watch and a timer. In case of pvscsi there are three variants: - new, can use libxl__wait_device_connection - reconfigure, can use both of the above - remove, may use DEFINE_DEVICE_REMOVE and its libxl__initiate_device_remove The reconfigure case has to wait for various states, depending on the state before the reconfiguration. For the time being I used also polling via libxl__wait_for_backend. Doing event driven reconfigure can be implemented, but only with quite some effort. Olaf ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] osstest: fix FreeBSD guest disk size
Roger Pau Monne writes ([PATCH] osstest: fix FreeBSD guest disk size): New 10.1 images are larger than the previous 10.0 images, so change the size of the LVM volume to accommodate them. Thanks, after discussion this now looks like the patch below and I'm going to push it to osstest pretest (along with some other stuff) shortly. Ian. From bae4a5464df47e036c9dfb3cd967d4bf9bb9d29e Mon Sep 17 00:00:00 2001 From: Roger Pau Monne roger@citrix.com Date: Tue, 14 Apr 2015 12:53:21 +0200 Subject: [OSSTEST PATCH 2/6] FreeBSD: Increase guest disk size MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit New 10.1 images are larger than the previous 10.0 images, so change the size of the LVM volume to accommodate them, in preparation. Increase the size to 24000 in case of future increases upstream. Signed-off-by: Roger Pau Monné roger@citrix.com Signed-off-by: Ian Jackson ian.jack...@eu.citrix.com --- ts-freebsd-install |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ts-freebsd-install b/ts-freebsd-install index 61d2f83..0f982d1 100755 --- a/ts-freebsd-install +++ b/ts-freebsd-install @@ -29,7 +29,7 @@ $gn ||= 'freebsd'; our $ho= selecthost($whhost); our $ram_mb= 1024; -our $disk_mb= 20480; +our $disk_mb= 24000; our $guesthost= $gn.guest.osstest; our $gho; -- 1.7.10.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] README: Reference some more comprehensive docs from the Quick-start
On Tue, 2015-04-14 at 16:40 +0100, Jan Beulich wrote: On 14.04.15 at 17:25, ian.campb...@citrix.com wrote: The quick-start is not terribly comprehensive for beginners. Signed-off-by: Ian Campbell ian.campb...@citrix.com --- README |7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/README b/README index 07c4797..2013699 100644 --- a/README +++ b/README @@ -26,7 +26,12 @@ http://wiki.xen.org/ Quick-Start Guide = -First, there are a number of prerequisites for building a Xen source +First, this is just a quick-start guide. For more comprehensive +information see the INSTALL file and the Xen wiki at +http://wiki.xenproject.org and in particular +http://wiki.xen.org/wiki/Getting_Started. Doesn't it look it little odd if you use xenproject.org and xen.org once each? Other than that - ack. Oops, I typed the first one by hand and copied the other from my browser history without reading it, the second should be changed and I'll do so upon commit unless there are other objections to the patch. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [[PATCH v4]] new functions libxl_bitmap_{or,and}
I'll fix it when I get home. It'll be late where you are. L
Sent from my iPhone
On Apr 14, 2015, at 10:33 AM, Wei Liu wei.l...@citrix.com wrote:
Urgh... I think I made a mistake in the rune I gave you, sorry. The
--subject-prefix= doesn't need to include [].
And you forgot to change the subject line to
libxl: provide libxl_bitmap_{and,or}
I'm a picky about the subject line because this is what shows up when
you look at git commit log.
On Tue, Apr 14, 2015 at 08:07:59AM -0600, Linda Jacobson wrote:
provide logical and and or of two bitmaps
Provide logical and and or of two bitmaps.
This should be a proper sentence.
Other than these minor nits the code logic looks OK.
Signed-off-by: Linda Jacobson lin...@jma3.com
---
[...]
+int libxl_bitmap_and(libxl_ctx *ctx, libxl_bitmap *and_map,
+ const libxl_bitmap *map1, const libxl_bitmap *map2)
+{
+GC_INIT(ctx);
+int rc;
+uint32_t i;
+const libxl_bitmap *large_map;
+const libxl_bitmap *small_map;
+
+if (map1-size map2-size) {
+large_map = map1;
+small_map = map2;
+} else {
+large_map = map2;
+small_map = map1;
+}
+
+
We only need one blank line here.
+rc = libxl_bitmap_alloc(ctx, and_map, small_map-size * 8);
+if (rc)
+goto out;
+
+/*
+ * If bitmaps aren't same size, their 'and' will be size of
+ * smaller bit map
+ */
+for (i = 0; i and_map-size; i++)
+and_map-map[i] = (large_map-map[i] small_map-map[i]);
+
+out:
+GC_FREE;
+return rc;
+
No need to have blank lines after return rc;
Wei.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 0/2] Re: libvirtd live-locking on CTX_LOCK when doing 'virsh domid save /tmp/blah' with guest corrupting memory (on purpose).
Konrad Rzeszutek Wilk writes (libvirtd live-locking on CTX_LOCK when doing 'virsh domid save /tmp/blah' with guest corrupting memory (on purpose).): It looks like thread #10 is blocking in libxl_read_exactly waiting for 'libxl-save-helper'. Said application (see below) has dispatched an message through helper_getreply and is blocking on __read_nocancel. This is not supposed to block. helper_stdout_readable assumes that the fd is actually readable. However, for complicated reasons it can happen in a multithreaded program that the fd was _reviously_ readable and is now no longer. This was not clearly documented in the internal API documentation. I have produced what I think are two patches that will fix this. I have compiled them but I haven't tested them. Konrad, are you able to check whether they fix your bug ? If they do they are candidates for backporting. Thanks, Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 1/2] libxl: fd events: Document spurious callbacks, break out libxl__ev_fd_recheck
No functional change, other than to debug and error message output.
Signed-off-by: Ian Jackson ian.jack...@eu.citrix.com
---
tools/libxl/libxl_event.c| 39 +++
tools/libxl/libxl_internal.h |8
2 files changed, 31 insertions(+), 16 deletions(-)
diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index 595da2b..9ede135 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -236,6 +236,25 @@ void libxl__ev_fd_deregister(libxl__gc *gc, libxl__ev_fd
*ev)
CTX_UNLOCK;
}
+short libxl__ev_fd_recheck(libxl__egc *egc, libxl__ev_fd *ev) {
+struct pollfd recheck;
+int r;
+
+recheck.fd = ev-fd;
+recheck.events = ev-events;
+recheck.revents = 0;
+r = poll(recheck, 1, 0);
+DBG(ev_fd=%p recheck fd=%d r=%d revents=%#x, ev, ev-fd,
+r, recheck.revents);
+if (r 0) {
+LIBXL__EVENT_DISASTER(egc, unexpected failure rechecking fd,
+ errno, 0);
+return 0;
+}
+assert(!!r == !!recheck.revents);
+return recheck.revents;
+}
+
/*
* timeouts
*/
@@ -661,9 +680,8 @@ static void evtchn_fd_callback(libxl__egc *egc,
libxl__ev_fd *ev,
{
EGC_GC;
libxl__ev_evtchn *evev;
-int r, rc;
+int rc;
evtchn_port_or_error_t port;
-struct pollfd recheck;
rc = evtchn_revents_check(egc, revents);
if (rc) return;
@@ -674,21 +692,10 @@ static void evtchn_fd_callback(libxl__egc *egc,
libxl__ev_fd *ev,
* held continuously since someone noticed the fd. Normally
* this wouldn't be a problem but evtchn devices don't always
* honour O_NONBLOCK (see xenctrl.h). */
-
-recheck.fd = fd;
-recheck.events = POLLIN;
-recheck.revents = 0;
-r = poll(recheck, 1, 0);
-DBG(ev_evtchn recheck r=%d revents=%#x, r, recheck.revents);
-if (r 0) {
-LIBXL__EVENT_DISASTER(egc,
- unexpected failure polling event channel fd for recheck,
- errno, 0);
-return;
-}
-if (r == 0)
+revents = libxl__ev_fd_recheck(egc,ev);
+if (!revents)
break;
-rc = evtchn_revents_check(egc, recheck.revents);
+rc = evtchn_revents_check(egc, revents);
if (rc) return;
/* OK, that's that workaround done. We can actually check for
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 9c22309..d3a5fba 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -175,6 +175,9 @@ typedef void libxl__ev_fd_callback(libxl__egc *egc,
libxl__ev_fd *ev,
* even if only POLLIN was set in events. (POLLNVAL is a fatal
* error and will cause libxl event machinery to fail an assertion.)
*
+ * Note that spurious callbacks are possible. If this is a problem,
+ * use libxl__ev_fd_recheck;
+ *
* It is not permitted to listen for the same or overlapping events
* on the same fd using multiple different libxl__ev_fd's.
*/
@@ -788,6 +791,11 @@ static inline void libxl__ev_fd_init(libxl__ev_fd *efd)
static inline int libxl__ev_fd_isregistered(const libxl__ev_fd *efd)
{ return efd-fd = 0; }
+/* Calls poll() again - useful to check whether this was a spurious
+ * wakeup. Cannot fail. Returns currently-true revents. */
+short libxl__ev_fd_recheck(libxl__egc *egc, libxl__ev_fd *ev);
+
+
_hidden int libxl__ev_time_register_rel(libxl__gc*, libxl__ev_time *ev_out,
libxl__ev_time_callback*,
int milliseconds /* as for poll(2) */);
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] Xen 4.6 Development Update (three months reminder)
* Regression in PCI passthrough of INTx legacy devices can trigger list corruption (good) Sander reported it. Two different types of patches available. - Konrad Rzeszutek Wilk Done. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/1] xc_domain_restore: Allow QEMU to increase memory
On 04/14/15 05:52, Wei Liu wrote: On Tue, Apr 14, 2015 at 05:40:24PM +0800, Hongyang Yang wrote: On 04/14/2015 05:29 PM, Wei Liu wrote: On Tue, Apr 14, 2015 at 05:22:31PM +0800, Hongyang Yang wrote: [...] If I understand correctly, the steps are this: * 'xl create' makes a VM of size $FOO * qemu bumps the size to $FOO+$N * 'xl save' writes $FOO+$N of page data, but the xl config file at the start of the image still says $FOO * 'xl restore' creates a vm of size $FOO, then instructs xc_domain_restore() to put $FOO+$N pages into it. I would argue first, that qemu should not play in this area to start with. With the size of the ROMs unknown outside of QEMU, I do not know how to correctly compute this in libxl. However, the real bug here is that the domain configuration written by xl save is inaccurate. I do not 100% agree. Since xc_domain_setmaxmem() could have been done, this should be part of the full domain configuration. However right now there is no way to include this value in any of the domain configuration structures. There's a case like COLO: 1. Both Primary/Secondary VM are created first with the same config file which makes a VM of size $FOO 2. qemu bumps the size to $FOO+$N This happens very early. I do see it reflected in PoD (xc_domain_get_pod_target()) data. 3. 'save' writes $FOO+$N of page data 4. 'restore' put $FOO+$N pages into $FOO pages which will cause error Even if you fix the configuration, the bug still exists because the config only been transferred from Primary to Secondary once at the very beginning when you execute 'xl remus' command. I am hopeful that QEMU has already done it's adjusting before you can do this command. Not having used it, I do not know for sure. The problem is how to let the secondary (restore) side knows the size change? Through a migration command(which is easier in v2 migration) or some other solution? As I said in my reply to Don, the extra memory can be saved during domain creation. That would solve this problem. The memory does get saved, the extra info is missing. After migration we'll enter COLO mode, which will continously send migration stream to Secondary. Domain creation only happens before doing live migration. Because now the correct value is recorded during domain creation, it will always be sent to the other end, so there is no need for this kind of hack. I will be looking into how to add this info (max_memkb (xc_domain_getinfo) or max_pages ()xc_domain_getinfolist) to the v1 migration in a compatible way with a usage in restore. -Don Slutz Wei. Wei. Form this point of view, I think Don's solution is one way to solve the problem. ~Andrew . -- Thanks, Yang. . -- Thanks, Yang. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/1] xc_domain_restore: Allow QEMU to increase memory
On 04/14/15 04:53, Wei Liu wrote: On Mon, Apr 13, 2015 at 07:51:31PM -0400, Don Slutz wrote: On 04/13/15 12:25, Andrew Cooper wrote: On 13/04/15 17:09, Don Slutz wrote: If QEMU has called on xc_domain_setmaxmem to add more memory for option ROMs, domain restore needs to also increase the memory. Signed-off-by: Don Slutz dsl...@verizon.com hvmloader has no interaction with xc_domain_restore(). I did not mean to imply that it did. Somehow I lost the fact that this is a bug in master: [root@dcs-xen-52 don]# xl cre -p /home/don/e1000x8.xfg The page data is correctly saved into the save file (migration stream). However when the new domain is created, it's size is wrong. You cannot adjust any of the config info to fix the size, because the option ROM space to reserve is not an existing config option. So if I am following you correctly, libxl needs to add and process more info to handle this case. Thanks for the analysis. I think what you need to do is to adjust the memory size during domain creation in libxl, then the relevant data is saved at creation time. It should not be modified during restore. There is already various adjustments to memory related values in libxl. Grep video_memkb and mex_memkb in libxl. I am assuming you mean max_memkb (since I cannot find mex_memkb). And it has the hack adjustment of max_memkb + LIBXL_MAXMEM_CONSTANT. Is there a way to know how much more memory each option rom needs? If so, you can correctly account for the extra memory you need. This would be an ideal fix to this problem. I do not know of a way to get this info. It can change based on the QEMU version. The static define: tools/libxl/libxl_internal.h:#define LIBXL_MAXMEM_CONSTANT 1024 Is the the old xl hack that allows Xen 4.5 (and before) to support up to 4 e1000 nics. -Don Slutz Wei. The migration path should not be hacked up to fix a higher level toolstack bug. I do not see how QEMU is part of the higher level toolstack. If you mean xl vs xc, then I can see xl save some how doing the work. This patch works for me, but I am happy to explore other ways to fix this bug. -Don Slutz ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/1] xc_domain_restore: Allow QEMU to increase memory
On Tue, Apr 14, 2015 at 01:34:43PM -0400, Don Slutz wrote: On 04/14/15 04:53, Wei Liu wrote: On Mon, Apr 13, 2015 at 07:51:31PM -0400, Don Slutz wrote: On 04/13/15 12:25, Andrew Cooper wrote: On 13/04/15 17:09, Don Slutz wrote: If QEMU has called on xc_domain_setmaxmem to add more memory for option ROMs, domain restore needs to also increase the memory. Signed-off-by: Don Slutz dsl...@verizon.com hvmloader has no interaction with xc_domain_restore(). I did not mean to imply that it did. Somehow I lost the fact that this is a bug in master: [root@dcs-xen-52 don]# xl cre -p /home/don/e1000x8.xfg The page data is correctly saved into the save file (migration stream). However when the new domain is created, it's size is wrong. You cannot adjust any of the config info to fix the size, because the option ROM space to reserve is not an existing config option. So if I am following you correctly, libxl needs to add and process more info to handle this case. Thanks for the analysis. I think what you need to do is to adjust the memory size during domain creation in libxl, then the relevant data is saved at creation time. It should not be modified during restore. There is already various adjustments to memory related values in libxl. Grep video_memkb and mex_memkb in libxl. I am assuming you mean max_memkb (since I cannot find mex_memkb). And it has the hack adjustment of max_memkb + LIBXL_MAXMEM_CONSTANT. No, I mean proper accounting. Is there a way to know how much more memory each option rom needs? If so, you can correctly account for the extra memory you need. This would be an ideal fix to this problem. I do not know of a way to get this info. It can change based on the QEMU version. Hmm... We need to figure out another way. The static define: tools/libxl/libxl_internal.h:#define LIBXL_MAXMEM_CONSTANT 1024 Is the the old xl hack that allows Xen 4.5 (and before) to support up to 4 e1000 nics. Let's not add more similar hacks again. Removing an old hack doesn't justify adding a more complex one. Wei. -Don Slutz Wei. The migration path should not be hacked up to fix a higher level toolstack bug. I do not see how QEMU is part of the higher level toolstack. If you mean xl vs xc, then I can see xl save some how doing the work. This patch works for me, but I am happy to explore other ways to fix this bug. -Don Slutz ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 2/2] libxl: save helper: Recheck fd events
The save helper message reader does operates with the fd in blocking
mode. So spurious wakeups could cause it to block, unless it takes
precautions.
Reported-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com
Signed-off-by: Ian Jackson ian.jack...@eu.citrix.com
---
tools/libxl/libxl_save_callout.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/tools/libxl/libxl_save_callout.c b/tools/libxl/libxl_save_callout.c
index 40b25e4..0f392ef 100644
--- a/tools/libxl/libxl_save_callout.c
+++ b/tools/libxl/libxl_save_callout.c
@@ -265,6 +265,8 @@ static void helper_stdout_readable(libxl__egc *egc,
libxl__ev_fd *ev,
STATE_AO_GC(shs-ao);
int rc, errnoval;
+revents = libxl__ev_fd_recheck(egc, ev);
+
if (revents (POLLERR|POLLPRI)) {
LOG(ERROR, %s signaled POLLERR|POLLPRI (%#x),
shs-stdout_what, revents);
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/1] xc_domain_restore: Allow QEMU to increase memory
On Tue, Apr 14, 2015 at 01:43:38PM -0400, Don Slutz wrote: On 04/14/15 05:52, Wei Liu wrote: On Tue, Apr 14, 2015 at 05:40:24PM +0800, Hongyang Yang wrote: On 04/14/2015 05:29 PM, Wei Liu wrote: On Tue, Apr 14, 2015 at 05:22:31PM +0800, Hongyang Yang wrote: [...] If I understand correctly, the steps are this: * 'xl create' makes a VM of size $FOO * qemu bumps the size to $FOO+$N * 'xl save' writes $FOO+$N of page data, but the xl config file at the start of the image still says $FOO * 'xl restore' creates a vm of size $FOO, then instructs xc_domain_restore() to put $FOO+$N pages into it. I would argue first, that qemu should not play in this area to start with. With the size of the ROMs unknown outside of QEMU, I do not know how to correctly compute this in libxl. However, the real bug here is that the domain configuration written by xl save is inaccurate. I do not 100% agree. Since xc_domain_setmaxmem() could have been done, this should be part of the full domain configuration. However right now there is no way to include this value in any of the domain configuration structures. There's a case like COLO: 1. Both Primary/Secondary VM are created first with the same config file which makes a VM of size $FOO 2. qemu bumps the size to $FOO+$N This happens very early. I do see it reflected in PoD (xc_domain_get_pod_target()) data. 3. 'save' writes $FOO+$N of page data 4. 'restore' put $FOO+$N pages into $FOO pages which will cause error Even if you fix the configuration, the bug still exists because the config only been transferred from Primary to Secondary once at the very beginning when you execute 'xl remus' command. I am hopeful that QEMU has already done it's adjusting before you can do this command. Not having used it, I do not know for sure. The problem is how to let the secondary (restore) side knows the size change? Through a migration command(which is easier in v2 migration) or some other solution? As I said in my reply to Don, the extra memory can be saved during domain creation. That would solve this problem. The memory does get saved, the extra info is missing. After migration we'll enter COLO mode, which will continously send migration stream to Secondary. Domain creation only happens before doing live migration. Because now the correct value is recorded during domain creation, it will always be sent to the other end, so there is no need for this kind of hack. I will be looking into how to add this info (max_memkb (xc_domain_getinfo) or max_pages ()xc_domain_getinfolist) to the v1 migration in a compatible way with a usage in restore. Let's see if we can record this in xc image format. I haven't looked, but George mentioned that it might be possible to do so. There are certainly other options than the one you propose. I think we need to agree on a fix before proceeding... Wei. -Don Slutz Wei. Wei. Form this point of view, I think Don's solution is one way to solve the problem. ~Andrew . -- Thanks, Yang. . -- Thanks, Yang. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/2] x86/vMSI-X: honor all mask requests
On 20/03/15 16:27, Jan Beulich wrote:
Commit 74fd0036de (x86: properly handle MSI-X unmask operation from
guests) didn't go far enough: it fixed an issue with unmasking, but
left an issue with masking in place: Due to the (late) point in time
when qemu requests the hypervisor to set up MSI-X interrupts (which is
where the MMIO intercept gets put in place), the hypervisor doesn't
see all guest writes, and hence shouldn't make assumptions on the state
the virtual MSI-X resources are in. Bypassing the rest of the logic on
a guest mask operation leads to
[00:04.0] pci_msix_write: Error: Can't update msix entry 1 since MSI-X is
already enabled.
which surprisingly enough doesn't lead to the device not working
anymore (I didn't dig in deep enough to figure out why that is). But it
does prevent the IRQ to be migrated inside the guest, i.e. all
interrupts will always arrive in vCPU 0.
Signed-off-by: Jan Beulich jbeul...@suse.com
Reviewed-by: Andrew Cooper andrew.coop...@citrix.com
--- a/xen/arch/x86/hvm/vmsi.c
+++ b/xen/arch/x86/hvm/vmsi.c
@@ -286,11 +286,11 @@ static int msixtbl_write(struct vcpu *v,
goto out;
}
-/* exit to device model if address/data has been modified */
-if ( test_and_clear_bit(nr_entry, entry-table_flags) )
+/* Exit to device model when unmasking and address/data got modified. */
+if ( !(val PCI_MSIX_VECTOR_BITMASK)
+ test_and_clear_bit(nr_entry, entry-table_flags) )
{
-if ( !(val PCI_MSIX_VECTOR_BITMASK) )
-v-arch.hvm_vcpu.hvm_io.msix_unmask_address = address;
+v-arch.hvm_vcpu.hvm_io.msix_unmask_address = address;
goto out;
}
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v1 3/3] xen/arm: smmu: Renaming struct iommu_domain *domain to, struct iommu_domain *iommu_domain
On Tue, 2015-04-14 at 12:24 +, Jaggi, Manish wrote: Hi Julien/Ian, Please will you configure your mail client to do the chevron () style of quotation favour in open source communities, picking out your replies from the mail you are replying to is a massive chore, especially after a couple of rounds of back and forth. I think a table describing the different structure would be nice. [manish] Table is indeed a good option, but I think changing the name of arm_smmu_xen_device to something like arch_smmu_device make more sense as arm_smmu_xen_device and arm_smmu_device are not differentiable just by name. Once we have a table describing the status quo then we can consider separately whether a rename would be useful or if the documentation in the table itself suffices. I intend to use this table as a reference when evaluating any request to change the names, hence I won't be considering such things until the table exists. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [OSSTEST PATCH 2/3] ts-tcpdump-start: New test step script
Sets up a tcpdump on a dom0. (We do not log traffic to other test
boxes in the job because that might include large amounts of migration
or test data.)
Also arrange that:
- We stop the tcpdump when doing log capture
- We capture the tcpdump record (by adding a big pattern to the log list)
- We do not treat the tcpdump as a leaked process
With this, a new step can be added to existing jobs as needed.
(The killall tcpdump ||: is duplicated in ts-tcpdump-start and
ts-logs-capture because the error handling ought to be different, so
that a refactoring to make it common would add more complexity than it
saves.)
Signed-off-by: Ian Jackson ian.jack...@eu.citrix.com
fixup! ts-tcpdump-start: New test step script
---
ts-leak-check|4
ts-logs-capture | 13
ts-tcpdump-start | 60 ++
3 files changed, 77 insertions(+)
create mode 100755 ts-tcpdump-start
diff --git a/ts-leak-check b/ts-leak-check
index ec40435..e6c1647 100755
--- a/ts-leak-check
+++ b/ts-leak-check
@@ -80,6 +80,10 @@ sub start_check () {
push @suppress, $;
}
+if ($r{$ho-{Ident}_tcpdump}) {
+ push @suppress, '^process .* tcpdump$';
+}
+
my $leaf= leak-current-$ho-{Name};
$statefh= open_unique_stashfile(\$leaf);
}
diff --git a/ts-logs-capture b/ts-logs-capture
index 453b03d..1b171cb 100755
--- a/ts-logs-capture
+++ b/ts-logs-capture
@@ -33,6 +33,16 @@ our ($whhost) = @ARGV;
$whhost ||= 'host';
our $ho= selecthost($whhost);
+sub stop_traces ($) {
+my ($lho) = @_;
+if ($r{$lho-{Ident}_tcpdump}) {
+ eval {
+ target_cmd_root($lho, killall tcpdump ||:);
+ };
+ warn $@ if length $@;
+};
+}
+
sub try_fetch_logs ($$) {
my ($lho, $logfilepats) = @_;
my $ok= 0;
@@ -136,6 +146,8 @@ sub fetch_logs_host_guests () {
/home/osstest/osstest-confirm-booted.log
+ /var/log/osstest-*
+
)];
if (!try_fetch_logs($ho, $logs)) {
logm(log fetching failed, trying hard host reboot...);
@@ -220,6 +232,7 @@ sub fetch_logs_guest ($) {
}
}
+stop_traces($ho);
serial_fetch_logs($ho);
fetch_logs_host_guests();
logm(logs captured to $stash);
diff --git a/ts-tcpdump-start b/ts-tcpdump-start
new file mode 100755
index 000..60e499d
--- /dev/null
+++ b/ts-tcpdump-start
@@ -0,0 +1,60 @@
+#!/usr/bin/perl -w
+# This is part of osstest, an automated testing framework for Xen.
+# Copyright (C) 2009-2013 Citrix Inc.
+#
+# This program is free software: you can redistribute it and/or modify
+# it under the terms of the GNU Affero General Public License as published by
+# the Free Software Foundation, either version 3 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU Affero General Public License for more details.
+#
+# You should have received a copy of the GNU Affero General Public License
+# along with this program. If not, see http://www.gnu.org/licenses/.
+
+use strict qw(vars);
+use Osstest;
+use Osstest::TestSupport;
+
+tsreadconfig();
+
+@ARGV==1 or die;
+our ($whhost) = @ARGV;
+our $ho = selecthost($whhost);
+
+my $ether = $r{$ho-{Ident}_physnic} // 'eth0';
+
+my $dump = '/var/log/osstest-tcpdump';
+
+use Data::Dumper;
+
+sub start () {
+my $runningk = $ho-{Ident}_tcpdump;
+if ($r{$runningk}) {
+ target_cmd_root($ho, killall tcpdump ||:);
+}
+
+my @excludeips;
+foreach my $k (sort keys %r) {
+next unless $k =~ m/^(?:\w+_)?host$/;
+ next if $k eq $ho-{Ident};
+ logm(checking whether to exclude traffic to other test host $k);
+ eval {
+ my $otherho = selecthost $k;
+ push @excludeips, $otherho-{Ip};
+ };
+ warn $@ if length $@;
+}
+
+my $cmd= tcpdump -p -w$dump -i$ether;
+$cmd .= join and , map { not ip host $_ } @excludeips;
+
+store_runvar($runningk, 1);
+
+target_cmd_root($ho, $cmd /dev/null $dump.log 21 sleep 1);
+}
+
+start();
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] Xen 4.6 Development Update (three months reminder)
On Tue, 2015-04-14 at 13:34 +0100, Julien Grall wrote: Hi Manish, On 14/04/15 13:25, Jaggi, Manish wrote: * ARM PCI passthrough (none) - Manish Jaggi - Vijay Kilari [manish] I have started pushing the patches Finding the [manish] in the mail was like finding a needle in a haystack. And I knew that you were using this tag... Please only quote the relevant part of the mail. I would also advice you to configure your email client correctly in order to avoid the tag. +2 (thousand). ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 4/4] hvmloader: add knob for fixed VGABIOS date string
On Mon, 2015-04-13 at 09:51 +0100, Jan Beulich wrote: On 02.04.15 at 11:45, ian.campb...@citrix.com wrote: On Wed, 2015-04-01 at 13:28 +, Olaf Hering wrote: To allow reproducible builds of hvmloader introduce a make variable VGABIOS_REL_DATE=dd Mon to provide a fixed date string. Without this change the hvmloader binary changes with every rebuild. 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 It's not clear if vgabios should be maintained by us tools folks or if it should have been taken under the hvmloader umbrella and maintained by the hypervisor folks. I'm not sure either - hvmloader is really code we grew and hence maintaining it together with its hypervisor side makes sense. For the various firmware blobs, otoh, I think they match more closely with the qemu/tools pattern. OK, I think that makes sense. We have specific maintainers for OVMF and SeaBIOS, I think the other stuff (rombios and vgabios) is frozen/inactive enough (and specific to qemu-trad) that we can muddle through via the tools/* umbrella maintainership. I think ipxe is only used with trad too, but I'm not sure if it is quite so inactive or if someone ought to be keeping an eye on e.g. new upstream versions. I think we can just continue as we have been there too. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] README: Reference some more comprehensive docs from the Quick-start
On 14.04.15 at 17:25, ian.campb...@citrix.com wrote: The quick-start is not terribly comprehensive for beginners. Signed-off-by: Ian Campbell ian.campb...@citrix.com --- README |7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/README b/README index 07c4797..2013699 100644 --- a/README +++ b/README @@ -26,7 +26,12 @@ http://wiki.xen.org/ Quick-Start Guide = -First, there are a number of prerequisites for building a Xen source +First, this is just a quick-start guide. For more comprehensive +information see the INSTALL file and the Xen wiki at +http://wiki.xenproject.org and in particular +http://wiki.xen.org/wiki/Getting_Started. Doesn't it look it little odd if you use xenproject.org and xen.org once each? Other than that - ack. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [OSSTEST PATCH 3/3] ts-tcpdump-start: Start a tcpdump before migration
Provisionally add this before the migration tests to see (a) how much
extra disk space etc. it uses (b) whether it helps us debug our
migration problems.
Signed-off-by: Ian Jackson ian.jack...@eu.citrix.com
---
sg-run-job |2 ++
1 file changed, 2 insertions(+)
diff --git a/sg-run-job b/sg-run-job
index eae159d..11e33a6 100755
--- a/sg-run-job
+++ b/sg-run-job
@@ -290,6 +290,7 @@ proc run-job/test-pair {} {
run-ts . = ts-guests-nbd-mirror + dst_host src_host + debian
per-host-ts . =(*) {ts-leak-check basis}
run-ts . = ts-guest-start + src_host + debian
+per-host-ts . =(*) ts-tcpdump-start
run-ts . = ts-guest-migrate src_host dst_host + debian
run-ts . = ts-guest-migrate dst_host src_host + debian
run-ts . = ts-guest-stop src_host + debian
@@ -302,6 +303,7 @@ proc run-job/test-pair {} {
proc test-guest-migr {g} {
if {[catch { run-ts . = ts-migrate-support-check + host $g }]} return
+run-ts . =(*) ts-tcpdump-start
foreach iteration {{} .2} {
run-ts . =$iteration ts-guest-saverestore + host $g
run-ts . =$iteration ts-guest-localmigrate + host $g
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [OSSTEST PATCH 1/3] ts-xen-install: Store HOST_physnic runvar
Signed-off-by: Ian Jackson ian.jack...@eu.citrix.com
---
ts-xen-install |1 +
1 file changed, 1 insertion(+)
diff --git a/ts-xen-install b/ts-xen-install
index b3f4387..7dbeab0 100755
--- a/ts-xen-install
+++ b/ts-xen-install
@@ -309,6 +309,7 @@ END
print EO or die $!
unless $suppress;
}
+ store_runvar($ho-{Ident}_physnic, $physif);
});
}
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] Xen 4.6 Development Update (three months reminder)
On 04/14/2015 06:27 AM, wei.l...@citrix.com wrote: * Display IO topology when PXM data is available (good) v3 posted - Boris Ostrovsky I should have v7 in the next day or so. * VPMU - 'perf' support in Xen (good) v14 posted Need reviews/final ack. - Boris Ostrovsky New version posted a week or so ago, there were very few changes. -boris ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH] README: Reference some more comprehensive docs from the Quick-start
The quick-start is not terribly comprehensive for beginners. Signed-off-by: Ian Campbell ian.campb...@citrix.com --- README |7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/README b/README index 07c4797..2013699 100644 --- a/README +++ b/README @@ -26,7 +26,12 @@ http://wiki.xen.org/ Quick-Start Guide = -First, there are a number of prerequisites for building a Xen source +First, this is just a quick-start guide. For more comprehensive +information see the INSTALL file and the Xen wiki at +http://wiki.xenproject.org and in particular +http://wiki.xen.org/wiki/Getting_Started. + +Second, there are a number of prerequisites for building a Xen source release. Make sure you have all the following installed, either by visiting the project webpage or installing a pre-built package provided by your OS distributor: -- 1.7.10.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [xen-4.4-testing test] 50407: FAIL
flight 50407 xen-4.4-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/50407/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf 3 host-install(3) broken in 50333 REGR. vs. 50266 Tests which are failing intermittently (not blocking): test-amd64-i386-freebsd10-amd64 16 guest-localmigrate/x10 fail in 50392 pass in 50333 test-amd64-amd64-xl-winxpsp3 15 guest-localmigrate/x10 fail in 50392 pass in 50407 test-armhf-armhf-xl-multivcpu 14 guest-start.2 fail pass in 50392 test-amd64-i386-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail pass in 50392 test-amd64-i386-freebsd10-amd64 13 guest-localmigrate fail pass in 50392 Regressions which are regarded as allowable (not blocking): test-amd64-i386-freebsd10-i386 14 guest-localmigrate/x10 fail in 50333 like 50266 test-amd64-i386-pair21 guest-migrate/src_host/dst_host fail like 36776 Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 1 build-check(1)blocked in 50333 n/a test-armhf-armhf-xl-credit2 1 build-check(1)blocked in 50333 n/a test-armhf-armhf-xl-arndale 1 build-check(1)blocked in 50333 n/a test-armhf-armhf-xl-multivcpu 1 build-check(1) blocked in 50333 n/a test-armhf-armhf-xl 1 build-check(1)blocked in 50333 n/a test-armhf-armhf-xl-sedf-pin 1 build-check(1)blocked in 50333 n/a test-armhf-armhf-xl-sedf 1 build-check(1)blocked in 50333 n/a test-armhf-armhf-xl-cubietruck 1 build-check(1) blocked in 50333 n/a build-armhf-libvirt 1 build-check(1)blocked in 50333 n/a test-amd64-amd64-rumpuserxen-amd64 1 build-check(1) blocked n/a test-amd64-i386-rumpuserxen-i386 1 build-check(1) blocked n/a test-armhf-armhf-xl-multivcpu 15 guest-start/debian.repeat fail in 50392 never pass test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail in 50392 never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt 11 guest-start fail never pass test-armhf-armhf-xl-credit2 6 xen-boot fail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass test-amd64-amd64-xl-win7-amd64 16 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 16 guest-stop fail never pass test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 16 guest-stop fail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass test-armhf-armhf-xl-sedf-pin 12 migrate-support-checkfail never pass test-armhf-armhf-xl-sedf 12 migrate-support-checkfail never pass test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail never pass test-amd64-i386-xend-winxpsp3 20 leak-check/check fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 16 guest-stop fail never pass build-amd64-rumpuserxen 6 xen-buildfail never pass build-i386-rumpuserxen6 xen-buildfail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-amd64-i386-xl-winxpsp3-vcpus1 16 guest-stop fail never pass test-amd64-i386-xl-qemut-winxpsp3-vcpus1 16 guest-stop fail never pass test-amd64-amd64-xl-winxpsp3 16 guest-stop fail never pass test-amd64-amd64-xl-qemut-winxpsp3 16 guest-stop fail never pass test-amd64-i386-xend-qemut-winxpsp3 20 leak-check/checkfail never pass version targeted for testing: xen 6b09a29ced2e7fc449a39f513e1d8c2b10d2af6d baseline version: xen fc6fe18f1511d4b393057c60a2e6b05ccd963e90 People who touched revisions under test: Andrew Cooper andrew.coop...@citrix.com Ian Campbell ian.campb...@citrix.com Ian Jackson ian.jack...@eu.citrix.com Jan Beulich jbeul...@suse.com Konrad Rzeszutek Wilk konrad.w...@oracle.com jobs: build-amd64-xend pass build-i386-xend pass build-amd64 pass build-armhf pass build-i386 pass
Re: [Xen-devel] [PATCH] libxl: Disallow save or migrate when host devices are assigned to a guest.
Konrad Rzeszutek Wilk wrote:
It is unhealthy. If the device is not doing any DMA operations
it would work - but if you are saving and there are DMA operations
happening the chance of corruption (outstanding DMAs) increase.
As such re-use the check migration used.
s/used// ?
Signed-off-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com
---
src/libxl/libxl_domain.c| 19 +++
src/libxl/libxl_domain.h| 3 +++
src/libxl/libxl_driver.c| 6 ++
src/libxl/libxl_migration.c | 15 +--
4 files changed, 29 insertions(+), 14 deletions(-)
diff --git a/src/libxl/libxl_domain.c b/src/libxl/libxl_domain.c
index 5e0ab56..c038989 100644
--- a/src/libxl/libxl_domain.c
+++ b/src/libxl/libxl_domain.c
@@ -178,6 +178,25 @@ libxlDomainObjEndJob(libxlDriverPrivatePtr driver
ATTRIBUTE_UNUSED,
return virObjectUnref(obj);
}
+/*
+ * Checks whether the domain has host devices (PCIe) to disallow
+ * migration or saving of guest - unless they are detached.
+ *
+ * Returns true if the domain has host devices, otherwise false.
+ */
+bool
+libxlDomainHasHostDevices(virDomainDefPtr def)
+{
+/* Migration is not allowed if definition contains any hostdevs */
+if (def-nhostdevs 0) {
+virReportError(VIR_ERR_OPERATION_INVALID, %s,
+ _(domain has assigned host devices));
+return true;
+}
+
+return false;
+}
+
static void *
libxlDomainObjPrivateAlloc(void)
{
diff --git a/src/libxl/libxl_domain.h b/src/libxl/libxl_domain.h
index aa647b8..76c0c8d 100644
--- a/src/libxl/libxl_domain.h
+++ b/src/libxl/libxl_domain.h
@@ -95,6 +95,9 @@ char *
libxlDomainManagedSavePath(libxlDriverPrivatePtr driver,
virDomainObjPtr vm);
+bool
+libxlDomainHasHostDevices(virDomainDefPtr def);
+
int
libxlDomainSaveImageOpen(libxlDriverPrivatePtr driver,
libxlDriverConfigPtr cfg,
diff --git a/src/libxl/libxl_driver.c b/src/libxl/libxl_driver.c
index 9eb071e..b9faba8 100644
--- a/src/libxl/libxl_driver.c
+++ b/src/libxl/libxl_driver.c
@@ -1650,6 +1650,9 @@ libxlDomainSaveFlags(virDomainPtr dom, const char *to,
const char *dxml,
goto endjob;
}
+if (libxlDomainHasHostDevices(vm-def))
+goto endjob;
+
if (libxlDoDomainSave(driver, vm, to) 0)
goto endjob;
@@ -1876,6 +1879,9 @@ libxlDomainManagedSave(virDomainPtr dom, unsigned int
flags)
goto endjob;
}
+if (libxlDomainHasHostDevices(vm-def))
+goto endjob;
+
name = libxlDomainManagedSavePath(driver, vm);
if (name == NULL)
goto endjob;
diff --git a/src/libxl/libxl_migration.c b/src/libxl/libxl_migration.c
index 4010506..aaed448c 100644
--- a/src/libxl/libxl_migration.c
+++ b/src/libxl/libxl_migration.c
@@ -209,19 +209,6 @@ libxlDoMigrateSend(libxlDriverPrivatePtr driver,
return ret;
}
-static bool
-libxlDomainMigrationIsAllowed(virDomainDefPtr def)
-{
-/* Migration is not allowed if definition contains any hostdevs */
-if (def-nhostdevs 0) {
-virReportError(VIR_ERR_OPERATION_INVALID, %s,
- _(domain has assigned host devices));
-return false;
-}
-
-return true;
-}
-
This function was created with the intention of adding more checks, e.g.
is the cpu and numa configuration migratable? Are there pending
snapshot or block jobs (once those are supported)? ...
I'd like to keep libxlDomainMigrationIsAllowed even though it currently
only checks for assigned hostdevs. I think it improves readability of
the migration code. For the time it could simply call
libxlDomainHasHostDevices.
Regards,
Jim
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] Xen 4.6 Development Update (three months reminder)
On 4/14/2015 at 09:33 PM, in message 552d1718.8060...@eu.citrix.com, George Dunlap george.dun...@eu.citrix.com wrote: On 04/14/2015 11:27 AM, wei.l...@citrix.com wrote: == Hypervisor == * Alternate p2m: support multiple copies of host p2m (ok) - Ed White * Improve RTDS scheduler (none) - Dagaen Golomb, Meng Xu This is a little vague... exactly what kinds of improvements are envisioned here? * Credit2: introduce per-vcpu hard and soft affinity (good) - Justin T. Weaver Still good (Probably in part awaiting my further review -- should get to that this week) * Credit2 production ready (none) cpu pinning, numa affinity and cpu reservation - George Dunlap The first two are identical to Justin Weaver's patch; you might want to note that. No work on CPU reservation yet. * PV USB support in libxl (fair) - Chunyan Liu * HVM USB support in libxl (fair) - George Dunlap Haven't heard anything on the first one in a while; the second one is basically blocked on the first. New version should be posted this week, addressing all comments of last version. * Blktap2 support (fair) - George Dunlap Working on integrating this with raisin; still fair by the definitions above. -George ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] linux-next: build failure after merge of the xen-tip tree
Hi all, On Mon, 13 Apr 2015 16:36:58 +0800 Bob Liu bob@oracle.com wrote: On 04/13/2015 04:09 PM, Stephen Rothwell wrote: After merging the xen-tip tree, today's linux-next build (x86_64 allmodconfig) failed like this: drivers/char/tpm/xen-tpmfront.c: In function 'setup_ring': drivers/char/tpm/xen-tpmfront.c:203:7: warning: passing argument 2 of 'xenbus_grant_ring' makes pointer from integer without a cast rv = xenbus_grant_ring(dev, virt_to_mfn(priv-shr)); ^ In file included from drivers/char/tpm/xen-tpmfront.c:17:0: include/xen/xenbus.h:206:5: note: expected 'void *' but argument is of type 'long unsigned int' int xenbus_grant_ring(struct xenbus_device *dev, void *vaddr, ^ drivers/char/tpm/xen-tpmfront.c:203:7: error: too few arguments to function 'xenbus_grant_ring' rv = xenbus_grant_ring(dev, virt_to_mfn(priv-shr)); ^ In file included from drivers/char/tpm/xen-tpmfront.c:17:0: include/xen/xenbus.h:206:5: note: declared here int xenbus_grant_ring(struct xenbus_device *dev, void *vaddr, ^ Caused by commit 1b1586eeeb8c (xenbus_client: Extend interface to support multi-page ring). I have used the xen-tip tree from next-20150410 for today. Sorry for this issue, I missed the xentpm-front.c file in that patch. (Original patch from Wei Liu already included the right modification which didn't exist in Paul's.) Attached patch should fix this build failure. I am still getting this failure :-( -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpkq_Npdqr3f.pgp Description: OpenPGP digital signature ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [xen-4.5-testing test] 50408: regressions - FAIL
flight 50408 xen-4.5-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/50408/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-freebsd10-amd64 14 guest-localmigrate/x10 fail in 50317 REGR. vs. 50268 Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-winxpsp3 10 guest-localmigrate fail in 50317 pass in 50408 test-amd64-i386-freebsd10-amd64 11 guest-localmigrate fail in 50334 pass in 50408 test-amd64-i386-xl-win7-amd64 13 guest-localmigrate/x10 fail in 50334 pass in 50408 test-armhf-armhf-libvirt 9 guest-startfail in 50334 pass in 50408 test-amd64-i386-xl-winxpsp3 13 guest-localmigrate/x10 fail in 50334 pass in 50408 test-amd64-i386-freebsd10-amd64 15 guest-localmigrate.2 fail pass in 50317 test-amd64-i386-freebsd10-i386 13 guest-localmigratefail pass in 50334 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-multivcpu 4 host-ping-check-native fail blocked in 50268 test-amd64-i386-freebsd10-i386 14 guest-localmigrate/x10 fail in 50334 like 50268 test-amd64-i386-pair21 guest-migrate/src_host/dst_host fail like 36775 Tests which did not succeed, but are not blocking: test-armhf-armhf-xl-multivcpu 10 migrate-support-check fail in 50334 never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 16 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl-sedf 12 migrate-support-checkfail never pass test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail never pass test-amd64-i386-xl-qemut-winxpsp3-vcpus1 16 guest-stop fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 16 guest-stop fail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-xl-qemut-winxpsp3 16 guest-stopfail never pass test-amd64-i386-xl-winxpsp3 16 guest-stop fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 16 guest-stop fail never pass test-armhf-armhf-xl-sedf-pin 12 migrate-support-checkfail never pass test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 16 guest-stop fail never pass test-amd64-i386-xl-qemuu-winxpsp3 16 guest-stopfail never pass test-amd64-amd64-xl-win7-amd64 16 guest-stop fail never pass test-amd64-amd64-xl-qemut-winxpsp3 16 guest-stop fail never pass test-amd64-amd64-xl-winxpsp3 16 guest-stop fail never pass version targeted for testing: xen 0b754fb3ed6b7b6d0f2e1f7c1877d3c0a7da2168 baseline version: xen 7fe1c1b28581686aca42361d4fee740c643dde1b People who touched revisions under test: Andrew Cooper andrew.coop...@citrix.com denys drozdov denys.droz...@globallogic.com Ian Campbell ian.campb...@citrix.com Ian Jackson ian.jack...@eu.citrix.com Jan Beulich jbeul...@suse.com Julien Grall julien.gr...@linaro.org Konrad Rzeszutek Wilk konrad.w...@oracle.com Stefano Stabellini stefano.stabell...@eu.citrix.com jobs: build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass build-amd64-rumpuserxen pass build-i386-rumpuserxen pass test-amd64-amd64-xl pass test-armhf-armhf-xl
Re: [Xen-devel] [PATCH] x86/Dom0: Don't allow dom0_max_vcpus to be zero
On 04/14/2015 03:21 AM, Jan Beulich wrote: On 09.04.15 at 22:59, andrew.coop...@citrix.com wrote: On 09/04/2015 21:38, Boris Ostrovsky wrote: In case dom0_max_vcpus is incorrectly specified on boot line make sure we will still boot. Signed-off-by: Boris Ostrovsky boris.ostrov...@oracle.com Good catch - lets not do that. Reviewed-by: Andrew Cooper andrew.coop...@citrix.com I see it got committed already, and I don't really mind the change, but - are we really in need of this? I.e. are we really rejecting bad or insane command line option values everywhere else? I very much doubt that, and it very much looks like a then don't do this thing to me... This actually happened to me (something happened with our installer). I agree that we can't predict how every option can go bad but we do try to prevent obvious errors so I figured this was worth a patch, especially given that it was pretty trivial. -boris ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] preparing for 4.5.1
On Tue, Apr 14, 2015 at 6:42 PM, Ian Campbell ian.campb...@citrix.com wrote:
On Mon, 2015-04-13 at 09:35 +0100, Jan Beulich wrote:
On 02.04.15 at 12:01, ian.campb...@citrix.com wrote:
On Thu, 2015-03-26 at 17:07 +, Jan Beulich wrote:
having been released mid January, it is time to get ready for 4.5.1-rc1.
Please reply with backport requests which you consider necessary but
still missing. Please also be patient with them being pulled in - I'll be
gone the coming two weeks, and I'd hope to get an RC1 put together
soon thereafter.
On my list for ARM I have this patch, which also touches x86. What do
you think?
If it fixes a real problem in 4.5 (rather than just a theoretical one,
exposed only in 4.6), then I'm fine with this (and assume since it's
mostly for ARM you'll take care of doing and applying the backport).
The original impetus was a bit lost in the various iterations. I think
it was something which was exposed by Vijay's new ITS code, which did a
larger vmalloc than any existing code and exposed the issue. Vijay, is
that correct?
Yes, correct.
Any allocation beyond 128MB will fail.
I think it is unlikely that there is anything in 4.5 which would do a
similarly large vmalloc, or at least I don't recall any reports of such.
So I think the conclusion is not to backport the patch, unless someone
knows of a practical issue on 4.5.
For those new to the CC line the commit is below.
Thanks,
Ian.
commit c2453291b177cc2e89dc104bd4233c3d8bb73922
Author: Vijaya Kumar K vijaya.ku...@caviumnetworks.com
Date: Tue Mar 24 17:14:47 2015 +0530
xen: Add populate_pt_range interface to reserve non-leaf level table
entries
On x86, for the pages mapped with PAGE_HYPERVISOR attribute
non-leaf page tables are allocated with valid pte entries.
and with MAP_SMALL_PAGES attribute only non-leaf page tables are
allocated with invalid (valid bit set to 0) pte entries.
However on arm this is not the case. On arm for the pages
mapped with PAGE_HYPERVISOR and MAP_SMALL_PAGES both
non-leaf and leaf level page table are allocated with valid bit
in pte entries.
This behaviour in arm makes common vmap code fail to
allocate memory beyond 128MB as described below.
In vm_init, map_pages_to_xen() is called for mapping
vm_bitmap. Initially one page of vm_bitmap is allocated
and mapped using PAGE_HYPERVISOR attribute.
For the rest of vm_bitmap pages, MAP_SMALL_PAGES attribute
is used to map.
In ARM for both PAGE_HYPERVISOR and MAP_SMALL_PAGES, valid bit
is set to 1 in pte entry for these mapping.
In vm_alloc(), map_pages_to_xen() is failing for 128MB because
for this next vm_bitmap page the mapping is already set in vm_init()
with valid bit set in pte entry. So map_pages_to_xen() in
ARM returns error.
With this patch, MAP_SMALL_PAGES is dropped and arch specific
populate_pt_range() api is introduced to populate non-leaf
page table entries for the requested pages. Added RESERVE option
to map non-leaf page table entries.
Signed-off-by: Vijaya Kumar Kvijaya.ku...@caviumnetworks.com
Acked-by: Jan Beulich jbeul...@suse.com
Acked-by: Ian Campbell ian.campb...@citrix.com
[ ijc -- rewrote subject line ]
diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 7d4ba0c..d103f8f 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -827,7 +827,8 @@ static int create_xen_table(lpae_t *entry)
enum xenmap_operation {
INSERT,
-REMOVE
+REMOVE,
+RESERVE
};
static int create_xen_entries(enum xenmap_operation op,
@@ -859,12 +860,15 @@ static int create_xen_entries(enum xenmap_operation op,
switch ( op ) {
case INSERT:
+case RESERVE:
if ( third[third_table_offset(addr)].pt.valid )
{
printk(create_xen_entries: trying to replace an
existing mapping addr=%lx mfn=%lx\n,
addr, mfn);
return -EINVAL;
}
+if ( op == RESERVE )
+break;
pte = mfn_to_xen_entry(mfn, ai);
pte.pt.table = 1;
write_pte(third[third_table_offset(addr)], pte);
@@ -898,6 +902,13 @@ int map_pages_to_xen(unsigned long virt,
{
return create_xen_entries(INSERT, virt, mfn, nr_mfns, flags);
}
+
+int populate_pt_range(unsigned long virt, unsigned long mfn,
+ unsigned long nr_mfns)
+{
+return create_xen_entries(RESERVE, virt, mfn, nr_mfns, 0);
+}
+
void destroy_xen_mappings(unsigned long v, unsigned long e)
{
create_xen_entries(REMOVE, v, 0, (e - v) PAGE_SHIFT, 0);
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 8e29675..786ed47 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -5725,6 +5725,12 @@ int map_pages_to_xen(
return
