Re: [Xen-devel] dom0 kenrel crashes for openstack + libvirt + libxl
On Wed, 2014-11-12 at 11:41 -0700, Xing Lin wrote: [ 9448.347994] [ cut here ] [ 9448.348004] WARNING: CPU: 1 PID: 19902 at /build/buildd/linux-3.13.0/mm/mmap.c:2736 exit_mmap+0x16b/0x170() more message ignored The most interesting bits of the message are likely to be the lines which follow here, i.e. the kernel stack trace and associated info. Please can you paste the complete log from cut here until the end. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] libxc: Turn on the pdpe1gb cpuid flag by default
On 13.11.14 at 06:31, liang.z...@intel.com wrote: Apart from the subject being kind of wrong (you're not turning it on by default, but only expose it if the hardware supports it), ... --- a/tools/libxc/xc_cpuid_x86.c +++ b/tools/libxc/xc_cpuid_x86.c @@ -192,6 +192,7 @@ static void intel_xc_cpuid_policy( bitmaskof(X86_FEATURE_ABM)); regs[3] = (bitmaskof(X86_FEATURE_NX) | bitmaskof(X86_FEATURE_LM) | +bitmaskof(X86_FEATURE_PAGE1GB) | bitmaskof(X86_FEATURE_SYSCALL) | bitmaskof(X86_FEATURE_RDTSCP)); break; ... this is incomplete: The AMD function would seem to need the same change, and the !PAE special casing in xc_cpuid_hvm_policy() should imo disable the flag. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH for 4.5] xl: Return proper error codes for block-attach and block-detach
On Wed, 2014-11-12 at 17:31 +, George Dunlap wrote:
@@ -6444,6 +6445,7 @@ int main_blockdetach(int argc, char **argv)
rc = libxl_device_disk_remove(ctx, domid, disk, 0);
if (rc) {
fprintf(stderr, libxl_device_disk_remove failed.\n);
+return 1;
}
libxl_device_disk_dispose(disk);
return rc;
This one seems odd to me, you have inadvertently arranged to skip the
disk dispose and the old code returned non-zero in the failure case
already, since it returns rc.
If it is important to return 0 or 1 then perhaps the last line should
just be:
return rc ? 1 : 0;
Or maybe the ultimate caller (i.e. the xl command dispatcher) ought to
be translating libxl ERROR_FOO into suitable process exit codes (perhaps
as simplistically as suggested above).
Skipping the dispose is a memory leak, albeit in a process which is just
about to die, but we like to try and keep xl valgrind clean so far as
possible such that leaks in the underlying libxl stand out.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [TestDay]Xen-4.5-RC1: Dom0 failed to resume from S3 power state with operations on '/sys/power/state'
On 13.11.14 at 03:32, robert...@intel.com wrote: Hi, This is a separated report for bug http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1897 Environment: Service Arch (ia32/ia32e/IA64): ia32e Guest Arch (ia32/ia32e/IA64): Guest OS Type (Linux/Windows): Change Set: Xen4.5-RC1 (git:1b068a5b485062c862c20d8ba7674faa97ee3714) Hardware: Ivybridge-EP, Grantley-EP Other: Bug detailed description: -- Boot into Dom0 (kernel 3.17.0), execute the command echo mem /sys/power/state, to make Dom0 system get into S3 sleep state, then press any key or power button to resume from S3 state, but failed and system hangs up with black screen. Reproduce steps: 1. Boot into Dom0, execute the command echo mem /sys/power/state to make Dom0 get into S3 state. 2. Press any key or press power button to resume from S3,no resume to dom0 Current result: Dom0 system cannot resume from S3 power state. Considering the Konrad confirmed this to work on other hardware it's likely going to be difficult to analyze this for anyone not in possession of a machine where things don't work as expected. I.e. again presumably a case where at least initial investigation would ideally be done by your engineers. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] About sharing pages between Xen and guest kernel
On 13.11.14 at 00:52, am...@gatech.edu wrote: Hello, I am trying to set up a shared page between the hypervisor and a Linux guest kernel. In Xen I am doing: void *ptr = alloc_xenheap_page(); share_xen_page_with_guest(virt_to_page(ptr), current-domain, XENSHARE_writable); unsigned int mfn = virt_to_mfn(ptr); And my plan was to pass the mfn to the guest kernel and retrieve the pfn with mfn_to_pfn(). However, this returned ~0. So I took a look at share_xen_page_with_guest() and I noticed it calls set_gpfn_from_mfn(mfn, INVALID_M2P_ENTRY), where INVALID_M2P_ENTRY = ~0. My questions are: 1. Do I have to call set_gpfn_from_mfn() after calling share_xen_page_with_guest() in the hypervisor? 2. If yes, what gpfn should I use? I am thinking I could allocate a page in the guest, and retrieve the pfn with page_to_pfn(), and then pass that to the hypervisor. But I don’t know if I am overcomplicating things. No, that wouldn't be correct (as is implied by 2). Instead you want to map the page based on its MFN (i.e. potentially without even establishing a PFN for it). But I suppose you looked at other examples in the source code, and you should have realized that this isn't really meant to be used for arbitrary memory sharing. Perhaps xentrace's map_tbufs() would be the closest reference to use. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen_disk: fix unmapping of persistent grants
El 12/11/14 a les 18.41, Stefano Stabellini ha escrit: On Wed, 12 Nov 2014, Roger Pau Monne wrote: This patch fixes two issues with persistent grants and the disk PV backend (Qdisk): - Don't use batch mappings when using persistent grants, doing so prevents unmapping single grants (the whole area has to be unmapped at once). The real issue is that destroy_grant cannot work with batch_maps. One could reimplement destroy_grant to build a single array with all the grants to unmap and make a single xc_gnttab_munmap call. Do you think that would be feasible? Making destroy_grant work with batch maps using the current tree structure is going to be quite complicated, because destroy_grant iterates on every entry on the tree, and doesn't know which grants belong to which regions. IMHO a simpler solution would be to introduce another tree (or list) that keeps track of grant-mapped regions, and on tear down use the data in that list to unmap the regions. This way the current tree will still be used to perform the grant_ref-vaddr translation, but on teardown the newly introduced list would be used instead. In general I was reluctant to do this because not using batch maps with persistent grants should not introduce a noticeable performance regression due to the fact that grants are only mapped once for the whole life-cycle of the virtual disk. Also, if we plan to implement indirect descriptors for Qdisk we really need to be able to unmap single grants in order to purge the list, since in that case it's not possible to keep all possible grants persistently mapped. Since this alternate solution is easy to implement I will send a new patch using this approach, then we can decide what to do. Roger. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] delaying 4.4.2 and 4.3.4
All, while the 3 month period since the previous stable releases would expire at the beginning of December, looking at the number of changes in the stable trees I don't think starting preparations right now would make much sense. Unless I hear severe objections to this plan, and unless 4.5 gets significantly delayed, I think we should look at RC1s for them once 4.5 is (almost) out the door. That'll also minimize collisions between testing needs 4.5 and the stable releases have. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 2/3] x86: allow dma_get_required_mask() to be overridden
On 13/11/14 10:25, Jan Beulich wrote:
On 12.11.14 at 16:25, david.vra...@citrix.com wrote:
--- a/arch/x86/include/asm/device.h
+++ b/arch/x86/include/asm/device.h
@@ -13,4 +13,6 @@ struct dev_archdata {
struct pdev_archdata {
};
+#define ARCH_HAS_DMA_GET_REQUIRED_MASK
Is there a particular reason you put this here rather than in
dma-mapping.h?
I was because asm/dma-mapping is included too late for it to work, but
looking at the current code it looks like it ought to work.
David
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 2/3] x86: allow dma_get_required_mask() to be overridden
On 13.11.14 at 11:25, jbeul...@suse.com wrote:
On 12.11.14 at 16:25, david.vra...@citrix.com wrote:
--- a/arch/x86/include/asm/device.h
+++ b/arch/x86/include/asm/device.h
@@ -13,4 +13,6 @@ struct dev_archdata {
struct pdev_archdata {
};
+#define ARCH_HAS_DMA_GET_REQUIRED_MASK
Is there a particular reason you put this here rather than in
dma-mapping.h?
Never mind - I see you need it that way so that struct dma_map_ops
gets the get_required_mask field defined, other than e.g. ia64 which
handles through another abstraction layer.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen_disk: fix unmapping of persistent grants
Am 12.11.2014 um 18:41 hat Stefano Stabellini geschrieben:
On Wed, 12 Nov 2014, Roger Pau Monne wrote:
This patch fixes two issues with persistent grants and the disk PV backend
(Qdisk):
- Don't use batch mappings when using persistent grants, doing so prevents
unmapping single grants (the whole area has to be unmapped at once).
The real issue is that destroy_grant cannot work with batch_maps.
One could reimplement destroy_grant to build a single array with all the
grants to unmap and make a single xc_gnttab_munmap call.
Do you think that would be feasible?
Performance wise, it would certainly be better.
- Unmap persistent grants before switching to the closed state, so the
frontend can also free them.
Signed-off-by: Roger Pau Monné roger@citrix.com
Reported-and-Tested-by: George Dunlap george.dun...@eu.citrix.com
Cc: Stefano Stabellini stefano.stabell...@eu.citrix.com
Cc: Kevin Wolf kw...@redhat.com
Cc: Stefan Hajnoczi stefa...@redhat.com
Cc: George Dunlap george.dun...@eu.citrix.com
---
hw/block/xen_disk.c | 35 ---
1 file changed, 24 insertions(+), 11 deletions(-)
diff --git a/hw/block/xen_disk.c b/hw/block/xen_disk.c
index 231e9a7..1300c0a 100644
--- a/hw/block/xen_disk.c
+++ b/hw/block/xen_disk.c
@@ -43,8 +43,6 @@
/* - */
-static int batch_maps = 0;
-
static int max_requests = 32;
/* - */
@@ -105,6 +103,7 @@ struct XenBlkDev {
blkif_back_rings_t rings;
int more_work;
int cnt_map;
+boolbatch_maps;
/* request lists */
QLIST_HEAD(inflight_head, ioreq) inflight;
@@ -309,7 +308,7 @@ static void ioreq_unmap(struct ioreq *ioreq)
if (ioreq-num_unmap == 0 || ioreq-mapped == 0) {
return;
}
-if (batch_maps) {
+if (ioreq-blkdev-batch_maps) {
if (!ioreq-pages) {
return;
}
@@ -386,7 +385,7 @@ static int ioreq_map(struct ioreq *ioreq)
new_maps = ioreq-v.niov;
}
-if (batch_maps new_maps) {
+if (ioreq-blkdev-batch_maps new_maps) {
ioreq-pages = xc_gnttab_map_grant_refs
(gnt, new_maps, domids, refs, ioreq-prot);
if (ioreq-pages == NULL) {
@@ -433,7 +432,7 @@ static int ioreq_map(struct ioreq *ioreq)
*/
grant = g_malloc0(sizeof(*grant));
new_maps--;
-if (batch_maps) {
+if (ioreq-blkdev-batch_maps) {
grant-page = ioreq-pages + (new_maps) * XC_PAGE_SIZE;
} else {
grant-page = ioreq-page[new_maps];
@@ -718,7 +717,9 @@ static void blk_alloc(struct XenDevice *xendev)
QLIST_INIT(blkdev-freelist);
blkdev-bh = qemu_bh_new(blk_bh, blkdev);
if (xen_mode != XEN_EMULATE) {
-batch_maps = 1;
+blkdev-batch_maps = TRUE;
+} else {
+blkdev-batch_maps = FALSE;
}
true and false, lower capitals
Or just blkdev-batch_maps = (xen_mode != XEN_EMULATE);
Kevin
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [rumpuserxen test] 31509: regressions - FAIL
Ian Jackson writes (Re: [rumpuserxen test] 31509: regressions - FAIL): ... This is weird. Actually, I think, the problem is that the rumpkernel now exits successfully rather than crashing, and my domain config file says only `on_crash=preserve' and not `on_shutdown=preserve'. So this is a bug in the tests, exposed by a correct change to the rumpkernel software. I will fix the test and hopefully this will get a test pass in another day or two. Thanks to Wei for listening to me explain :-). Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [qemu-mainline test] 31517: regressions - FAIL
flight 31517 qemu-mainline real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/31517/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl 9 guest-start fail REGR. vs. 30603 test-amd64-i386-pair 17 guest-migrate/src_host/dst_host fail REGR. vs. 30603 Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 9 guest-start fail never pass test-amd64-i386-libvirt 9 guest-start fail never pass test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-amd64-libvirt 9 guest-start fail never pass test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop fail never pass test-amd64-amd64-xl-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-amd64-xl-winxpsp3 14 guest-stop fail never pass test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop fail never pass test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-qemut-winxpsp3 14 guest-stopfail never pass test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stopfail never pass test-amd64-i386-xl-winxpsp3 14 guest-stop fail never pass version targeted for testing: qemuue0d0041ec6dce1b8bfb3f66e9e4b8b9cd7e34806 baseline version: qemuub00a0ddb31a393b8386d30a9bef4d9bbb249e7ec People who touched revisions under test: Adam Crume adamcr...@gmail.com Alex Bennée alex.ben...@linaro.org Alex Williamson alex.william...@redhat.com Alexander Graf ag...@suse.de Alexey Kardashevskiy a...@ozlabs.ru Amit Shah amit.s...@redhat.com Andreas Färber afaer...@suse.de Andrew Jones drjo...@redhat.com Ard Biesheuvel ard.biesheu...@linaro.org Aurelien Jarno aurel...@aurel32.net Bastian Koppelmann kbast...@mail.uni-paderborn.de Bharata B Rao bhar...@linux.vnet.ibm.com Bin Wu wu.wu...@huawei.com Chao Peng chao.p.p...@linux.intel.com Chen Fan chen.fan.f...@cn.fujitsu.com Chen Gang gang.chen.5...@gmail.com Chenliang chenlian...@huawei.com Chris Spiegel chris.spie...@cypherpath.com Christian Borntraeger borntrae...@de.ibm.com Claudio Fontana claudio.font...@huawei.com Cole Robinson crobi...@redhat.com Corey Minyard cminy...@mvista.com Cornelia Huck cornelia.h...@de.ibm.com David Gibson da...@gibson.dropbear.id.au David Hildenbrand d...@linux.vnet.ibm.com Denis V. Lunev d...@openvz.org Don Slutz dsl...@verizon.com Dongxue Zhang elta@gmail.com Dr. David Alan Gilbert dgilb...@redhat.com Edgar E. Iglesias edgar.igles...@xilinx.com Eduardo Habkost ehabk...@redhat.com Eduardo Otubo eduardo.ot...@profitbricks.com Fabian Aggeler aggel...@ethz.ch Fam Zheng f...@redhat.com Frank Blaschka blasc...@linux.vnet.ibm.com Gal Hammer gham...@redhat.com Gerd Hoffmann kra...@redhat.com Gonglei arei.gong...@huawei.com Greg Bellows greg.bell...@linaro.org Gu Zheng guz.f...@cn.fujitsu.com Hannes Reinecke h...@suse.de Heinz Graalfs graa...@linux.vnet.ibm.com Igor Mammedov imamm...@redhat.com James Harper james.har...@ejbdigital.com.au James Harper ja...@ejbdigital.com.au Jan Kiszka jan.kis...@siemens.com Jan Vesely jano.ves...@gmail.com Jens Freimann jf...@linux.vnet.ibm.com Joel Schopp jsch...@linux.vnet.ibm.com John Snow js...@redhat.com Jonas Gorski j...@openwrt.org Jonas Maebe jonas.ma...@elis.ugent.be Juan Quintela quint...@redhat.com Juan Quintela quint...@trasno.org Jun Li junm...@gmail.com Kevin Wolf kw...@redhat.com KONRAD Frederic fred.kon...@greensocs.com Laszlo Ersek ler...@redhat.com Leon Alrae leon.al...@imgtec.com Li Liu john.li...@huawei.com Luiz Capitulino lcapitul...@redhat.com Maciej W. Rozycki ma...@codesourcery.com Magnus Reftel ref...@spotify.com Marc-André Lureau marcandre.lur...@gmail.com Marcel Apfelbaum marce...@redhat.com Mark Cave-Ayland mark.cave-ayl...@ilande.co.uk Markus Armbruster arm...@redhat.com Martin Decky mar...@decky.cz Martin Simmons mar...@lispworks.com Max Filippov jcmvb...@gmail.com Max Reitz mre...@redhat.com Michael Ellerman m...@ellerman.id.au Michael Roth mdr...@linux.vnet.ibm.com Michael S. Tsirkin
[Xen-devel] [linux-3.10 test] 31520: regressions - FAIL
flight 31520 linux-3.10 real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/31520/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemut-winxpsp3 7 windows-install fail REGR. vs. 26303 Regressions which are regarded as allowable (not blocking): test-amd64-i386-qemuu-rhel6hvm-amd 7 redhat-install fail like 26261 test-amd64-amd64-xl-qemuu-debianhvm-amd64 7 debian-hvm-install fail blocked in 26303 test-amd64-i386-pair17 guest-migrate/src_host/dst_host fail like 26303 test-amd64-amd64-xl-winxpsp3 7 windows-install fail like 26303 Tests which did not succeed, but are not blocking: test-amd64-i386-libvirt 9 guest-start fail never pass test-amd64-amd64-libvirt 9 guest-start fail never pass test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-armhf-armhf-xl 5 xen-boot fail never pass test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop fail never pass test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop fail never pass test-amd64-amd64-xl-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-winxpsp3 14 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 14 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-qemut-winxpsp3 14 guest-stopfail never pass test-armhf-armhf-libvirt 5 xen-boot fail never pass test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stopfail never pass version targeted for testing: linux816b571ac0e9eb9700df1ebc99702f9ad04e8607 baseline version: linuxbe67db109090b17b56eb8eb2190cd70700f107aa 698 people touched revisions under test, not listing them all jobs: build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass build-amd64-rumpuserxen pass build-i386-rumpuserxen pass test-amd64-amd64-xl pass test-armhf-armhf-xl fail test-amd64-i386-xl pass test-amd64-i386-rhel6hvm-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd fail test-amd64-amd64-xl-qemut-debianhvm-amd64pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64fail test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-rumpuserxen-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64fail test-amd64-i386-xl-credit2 pass test-amd64-i386-freebsd10-i386 pass test-amd64-i386-rumpuserxen-i386 pass test-amd64-amd64-xl-pcipt-intel
[Xen-devel] Problems accessing passthrough PCI device
Hi all, I am back on my virtual machine once again and have run into a bit of a problem (once again). So I am coming to you cap in hand... I am having 2 major problems at the moment. 1.- Access to the PCI device from the PV will fail the second time I create it UNLESS I call xl pci-assignable-remove/pci-assignable-add between each creation. If I don't do this then all PCI accesses return -1. I get the same if I disable memory access in the PCI configuration register. 1.1.- Is this expected behaviour? 1.2.- If not, how do I work around it? I have looked at HYPERVISOR_physdev_op but I'm not sure how/whether to use it. 1.3.- xl dmesg and dmesg in Dom0 do not show anything. I have set loglvl=all in the Xen command line. 2.- Whenever I perform a software reset on the PCI device (it is an Intel 82546 Ethernet NIC) the hypervisor crashes. There is no oops, kernel panic or the like, just a crash. My development device has no serial port so I can't do much debugging. Any suggestions. -- Best regards, Simon mailto:furryfutt...@gmail.com ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] XenServer results from the Test Day for RC2
Hi, While attempting to test Konrads new interrupt injection logic, I got blocked behind yet another Pygrub bug caused by c/s d1b93ea This is the first time I have looked into the issue, but a cursory inspection of the first hunk shows that it cannot possibly be correct as self._default is either an integer or string. I have a possible workaround which I am testing, but cursory review of the patch would have shown that it cannot work as intended. Notice that self._default is now either a string or an integer, defaulting to an integer, and the top level code is updated to require a string. As a result, any bootloader configuration which doesn't explicitly set a default, or still drives this logic with integers (ExtLinux or LiLO) will die with an AttributeError ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2] xen: remove Xencomm
On 13.11.14 at 17:03, t...@xen.org wrote: Being a feature that has only been used by ia64 and/or ppc it doesn't seem like we need to keep it any longer in the tree. So remove it. Signed-off-by: Boris Ostrovsky boris.ostrov...@oracle.com Signed-off-by: Tim Deegan t...@xen.org Acked-by: Jan Beulich jbeul...@suse.com ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH ARM v8 1/4] mini-os: arm: time
On 27 October 2014 10:34, Ian Campbell ian.campb...@citrix.com wrote:
On Sun, 2014-10-26 at 09:51 +, Thomas Leonard wrote:
On 21 October 2014 11:50, Ian Campbell ian.campb...@citrix.com wrote:
On Fri, 2014-10-03 at 10:20 +0100, Thomas Leonard wrote:
Based on an initial patch by Karim Raslan.
Signed-off-by: Karim Allah Ahmed karim.allah.ah...@gmail.com
Signed-off-by: Thomas Leonard tal...@gmail.com
Acked-by: Ian Campbell ian.campb...@citrix.com
+/* Wall-clock time is not currently available on ARM, so this is always
zero for now:
+ *
http://wiki.xenproject.org/wiki/Xen_ARM_TODO#Expose_Wallclock_time_to_guests
I have some slightly hacky patches for this, I really should dust them
off and submit them...
+void block_domain(s_time_t until)
+{
+uint64_t until_count = ns_to_ticks(until) + cntvct_at_init;
+ASSERT(irqs_disabled());
+if (read_virtual_count() until_count)
+{
+set_vtimer_compare(until_count);
+__asm__ __volatile__(wfi);
+unset_vtimer_compare();
+
+/* Give the IRQ handler a chance to handle whatever woke us up.
*/
+local_irq_enable();
+local_irq_disable();
+}
Just wondering, is this not roughly equivalent to a wfi loop with
interrupts enabled?
I'm not quite sure what you mean.
If we enable interrupts before the wfi then I think the following could
occur:
1. Application checks for work, finds none and calls block_domain.
2. block_domain enables interrupts.
3. An interrupt occurs.
4. The interrupt handler sets a flag indicating work to do.
5. wfi is called, putting the domain to sleep, even though there is work to
do.
Enabling IRQs after block_domain ensures we can't sleep while we have
work to do.
Ah, yes.
So, can this patch be applied as-is now?
--
Dr Thomas Leonardhttp://0install.net/
GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1
GPG: DA98 25AE CAD0 8975 7CDA BD8E 0713 3F96 CA74 D8BA
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RFC 1/7] xen/mem_event: Cleanup of mem_event structures
On Wed, Nov 12, 2014 at 4:58 PM, Andrew Cooper andrew.coop...@citrix.com
wrote:
On 12/11/14 15:31, Tamas K Lengyel wrote:
diff --git a/xen/include/public/mem_event.h
b/xen/include/public/mem_event.h
index 599f9e8..c0e9394 100644
--- a/xen/include/public/mem_event.h
+++ b/xen/include/public/mem_event.h
@@ -49,15 +49,19 @@
#define MEM_EVENT_FLAG_EMULATE_NOWRITE (1 6)
/* Reasons for the memory event request */
-#define MEM_EVENT_REASON_UNKNOWN 0/* typical reason */
-#define MEM_EVENT_REASON_VIOLATION 1/* access violation, GFN is
address */
-#define MEM_EVENT_REASON_CR0 2/* CR0 was hit: gfn is new
CR0 value, gla is previous */
-#define MEM_EVENT_REASON_CR3 3/* CR3 was hit: gfn is new
CR3 value, gla is previous */
-#define MEM_EVENT_REASON_CR4 4/* CR4 was hit: gfn is new
CR4 value, gla is previous */
-#define MEM_EVENT_REASON_INT35/* int3 was hit: gla/gfn are
RIP */
-#define MEM_EVENT_REASON_SINGLESTEP 6/* single step was invoked:
gla/gfn are RIP */
-#define MEM_EVENT_REASON_MSR 7/* MSR was hit: gfn is MSR
value, gla is MSR address;
- does NOT honour
HVMPME_onchangeonly */
+typedef enum {
+MEM_EVENT_REASON_UNKNOWN, /* Default case */
+MEM_EVENT_REASON_MEM_ACCESS_VIOLATION, /* Memory access violation */
+MEM_EVENT_REASON_MEM_SHARING, /* Memory sharing event */
+MEM_EVENT_REASON_MEM_PAGING, /* Memory paging event */
+MEM_EVENT_REASON_CR0, /* CR0 was updated */
+MEM_EVENT_REASON_CR3, /* CR3 was updated */
+MEM_EVENT_REASON_CR4, /* CR4 was updated */
+MEM_EVENT_REASON_INT3, /* Debug operation executed
(int3) */
+MEM_EVENT_REASON_SINGLESTEP, /* Single-step (MTF) */
+MEM_EVENT_REASON_MSR, /* An MSR was updated.
+* Does NOT honour
HVMPME_onchangeonly */
+} mem_event_reason_t;
Please keep these as defines. The width of an enum is implementation
defined, meaning that different compilers are free to interpret the
width of the above definition differently, which affects the size and
alignment of mem_event_st below.
OK, that makes sense.
Tamas
(It is completely wrong that Xen's ABI/API was ever specified using C,
rather than a document stating actual data structure widths, but that
horse has long-since bolted)
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] RFC: Configuring rumprun-xen application stacks from Xenstore
po...@iki.fi said: Actually, hmm, there's already an image for /etc available. I understood from irc discussion that you needed slight modifications to passwd for mathopd. In case your changes don't conflict with what's already up there, you could just update the existing downloadable /etc image: https://github.com/rumpkernel/rumprun-xen/tree/master/img I'll add in a new image rather than touch the current one, so that it can be cd9660 and read-only rather than ffs. Avoids needing to keep a clean image around in case of crashes while developing. The old one can stay until we replace the old demo code. Also, I'd prefer to call it 'stubetc' rather than 'etc' to make it clearer that it's not supposed to be used as a normal /etc. This brings up another question; what to do with resolv.conf, for example? Did you try running more than one? You should just be able to run as many domU's as you want and serve different content from each by altering -b, correct? Yes. In the final demo I will move the mathopd configuration file under /data, so that would work fine. However: Xen requires each domU to have a locally-unique name. At the moment xr just uses rumprun-$APP which will not be unique for more than one copy of APP. I will add an option allowing you to override that. In the long run I'd prefer a scheme similar to what Docker does: If you don't specify a name then a locally-unique admin-friendly one is generated for you, eg. (from a test I just ran on my system): boring_hopper, mad_mcclintock, ... Martin ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] RFC: Configuring rumprun-xen application stacks from Xenstore
On 13/11/14 17:07, Martin Lucina wrote: po...@iki.fi said: Actually, hmm, there's already an image for /etc available. I understood from irc discussion that you needed slight modifications to passwd for mathopd. In case your changes don't conflict with what's already up there, you could just update the existing downloadable /etc image: https://github.com/rumpkernel/rumprun-xen/tree/master/img I'll add in a new image rather than touch the current one, so that it can be cd9660 and read-only rather than ffs. Avoids needing to keep a clean image around in case of crashes while developing. The old one can stay until we replace the old demo code. Generally speaking, file systems support read-only mounts ... Also, I'd prefer to call it 'stubetc' rather than 'etc' to make it clearer that it's not supposed to be used as a normal /etc. I'd prefer it to be completely hidden from the user. But sure, call it stubetc for now. This brings up another question; what to do with resolv.conf, for example? Is resolv.conf an example, i.e. are there other files with similar needs? Or can we figure out how to handle it as a special case? ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 1/4] OvmfPkg/XenBusDxe: In XenStore, replace type of Len from UINTN to UINT32.
Since a message to XenStore have a lenght of type UINT32, have
XenStore.c deal only with UINT32 instead of a mixmatch with UINTN.
This patch replaces the type of Len in WRITE_REQUEST and the type of the
argument Len of XenStoreWriteStore and XenStoreReadStore.
This patch should avoid to have type cast were it does not make sense to
have them.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Anthony PERARD anthony.per...@citrix.com
---
CC: Xen Devel xen-devel@lists.xen.org
---
OvmfPkg/XenBusDxe/XenStore.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/OvmfPkg/XenBusDxe/XenStore.c b/OvmfPkg/XenBusDxe/XenStore.c
index f176b95..7c272b3 100644
--- a/OvmfPkg/XenBusDxe/XenStore.c
+++ b/OvmfPkg/XenBusDxe/XenStore.c
@@ -69,7 +69,7 @@
typedef struct {
CONST VOID *Data;
- UINTN Len;
+ UINT32 Len;
} WRITE_REQUEST;
/* Register callback to watch subtree (node) in the XenStore. */
@@ -456,7 +456,7 @@ STATIC
XENSTORE_STATUS
XenStoreWriteStore (
IN CONST VOID *DataPtr,
- IN UINTN Len
+ IN UINT32 Len
)
{
XENSTORE_RING_IDX Cons, Prod;
@@ -535,7 +535,7 @@ STATIC
XENSTORE_STATUS
XenStoreReadStore (
OUT VOID *DataPtr,
- IN UINTN Len
+ IN UINT32 Len
)
{
XENSTORE_RING_IDX Cons, Prod;
@@ -883,7 +883,7 @@ XenStoreSingle (
WRITE_REQUEST WriteRequest;
WriteRequest.Data = (VOID *) Body;
- WriteRequest.Len = AsciiStrSize (Body);
+ WriteRequest.Len = (UINT32)AsciiStrSize (Body);
return XenStoreTalkv (Transaction, RequestType, WriteRequest, 1,
LenPtr, Result);
@@ -912,9 +912,9 @@ XenStoreWatch (
WRITE_REQUEST WriteRequest[2];
WriteRequest[0].Data = (VOID *) Path;
- WriteRequest[0].Len = AsciiStrSize (Path);
+ WriteRequest[0].Len = (UINT32)AsciiStrSize (Path);
WriteRequest[1].Data = (VOID *) Token;
- WriteRequest[1].Len = AsciiStrSize (Token);
+ WriteRequest[1].Len = (UINT32)AsciiStrSize (Token);
return XenStoreTalkv (XST_NIL, XS_WATCH, WriteRequest, 2, NULL, NULL);
}
@@ -938,9 +938,9 @@ XenStoreUnwatch (
WRITE_REQUEST WriteRequest[2];
WriteRequest[0].Data = (VOID *) Path;
- WriteRequest[0].Len = AsciiStrSize (Path);
+ WriteRequest[0].Len = (UINT32)AsciiStrSize (Path);
WriteRequest[1].Data = (VOID *) Token;
- WriteRequest[1].Len = AsciiStrSize (Token);
+ WriteRequest[1].Len = (UINT32)AsciiStrSize (Token);
return XenStoreTalkv (XST_NIL, XS_UNWATCH, WriteRequest, 2, NULL, NULL);
}
@@ -1245,9 +1245,9 @@ XenStoreWrite (
Path = XenStoreJoin (DirectoryPath, Node);
WriteRequest[0].Data = (VOID *) Path;
- WriteRequest[0].Len = AsciiStrSize (Path);
+ WriteRequest[0].Len = (UINT32)AsciiStrSize (Path);
WriteRequest[1].Data = (VOID *) Str;
- WriteRequest[1].Len = AsciiStrLen (Str);
+ WriteRequest[1].Len = (UINT32)AsciiStrLen (Str);
Status = XenStoreTalkv (Transaction, XS_WRITE, WriteRequest, 2, NULL, NULL);
FreePool (Path);
--
Anthony PERARD
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] kexec-tools: Read always one vmcoreinfo file
Hi Petr, On Thu, Nov 13, 2014 at 04:51:48PM +0100, Petr Tesarik wrote: Hi all, this thread got somehow forgotten because of vacations... Anyway, read below. On Tue, 24 Jul 2012 15:54:10 +0200 Daniel Kiper daniel.ki...@oracle.com wrote: On Tue, Jul 24, 2012 at 10:18:34AM +0200, Petr Tesarik wrote: Dne Po 23. ??ervence 2012 22:10:59 Daniel Kiper napsal(a): Hi Petr, On Mon, Jul 23, 2012 at 03:30:55PM +0200, Petr Tesarik wrote: Dne Po 23. ??ervence 2012 14:56:07 Petr Tesarik napsal(a): Dne ??t 5. ??ervence 2012 14:16:35 Daniel Kiper napsal(a): vmcoreinfo file could exists under /sys/kernel (valid on baremetal only) and/or under /sys/hypervisor (valid when Xen dom0 is running). Read only one of them. It means that only one PT_NOTE will be always created. Remove extra code for second PT_NOTE creation. Hi Daniel, are you absolutely sure this is the right thing to do? IIUC these two VMCORINFO notes are very different. The one from /sys/kernel/vmcoreinfo describes the Dom0 kernel (type 'VMCOREINFO'), while the one from /sys/hypervisor describes the Xen hypervisor (type 'XEN_VMCOREINFO'). If you keep only the hypervisor note, then e.g. makedumpfile won't be able to use dumplevel greater than 1, nor will it be able to extract the log buffer. I've just verified this, and I'm confident we have to keep both notes in the dump file. Simon, please revert Daniel's patch to avoid regressions. I'm attaching a sample VMCOREINFO_XEN and VMCOREINFO to demonstrate the difference. Note that the VMCOREINFO_XEN note is actually too big, because Xen doesn't bother to maintain the correct note size in the note header, so it always spans a complete page minus sizeof(Elf64_Nhdr)... [...] The problem with /sys/kernel/vmcoreinfo under Xen is that it expose invalid physical address. It breaks /proc/vmcore in crash kernel. That is why I proposed that fix. Additionally, /sys/kernel/vmcoreinfo is not available under Xen Linux Ver. 2.6.18. However, I did not do any makedumpfile tests. If you discovered any issues with my patch please drop me more details about your tests (Xen version, Linux Kernel version, makedumpfile version, command lines, config files, logs, etc.). I will be more then happy to fix/improve kexec-tools and makedumpfile. Hi Daniel, well, Linux v2.6.18 does not have /sys/kernel/vmcoreinfo, simply because the VMCOREINFO infrastructure was not present in 2.6.18. It was added later with Yep. commit fd59d231f81cb02870b9cf15f456a897f3669b4e, which went into 2.6.24. Hmmm... As I know 2.6.24 does not support kexec/kdump under Xen dom0. Correct? I tested with the following combinations: * xen-3.3.1 + kernel-xen-2.6.27.54 + kexec-tools-2.0.0 + makedumpfile-1.3.1 * xen-4.0.3 + kernel-xen-2.6.32.59 + kexec-tools-2.0.0 + makedumpfile-1.3.1 * xen-4.1.2 + kernel-xen-3.0.34 + kexec-tools-2.0.0 + makedumpfile-1.4.0 These versions correspond to SLES11-GA, SLES11-SP1 and SLES11-SP2, respectively. All of them work just fine and save both ELF notes into the dump. Could you test current kexec-tools development version and latest makedumpfile version on latest SLES version? And indeed, I've just hit this regression with SLES12 GA (kernel 3.12.28, kexec-tools 2.0.5, makedumpfile 1.5.6). In the secondary kernel, makedumpfile complains that VMCOREINFO is not stored in /proc/vmcore: bash-4.2# makedumpfile -d 31 -X -E /proc/vmcore /kdump/mnt1/abuild/dumps/2014-11-13-13\:13/vmcore.elf Switched running mode from cyclic to non-cyclic, because the cyclic mode doesn't support Xen. /proc/vmcore doesn't contain vmcoreinfo. Specify '-x' option or '-i' option. Commandline parameter is invalid. Try `makedumpfile --help' for more information. makedumpfile Failed. Then I reverted commit 455d79f57e9367e5c59093fd74798905bd5762fc and everything works just fine. What do you mean by invalid physical address? I'm getting the correct physical address under Xen. Obviously, it must be translated to machine addresses if you need them from the secondary kernel. Correct vmcoreinfo address should be established by calling HYPERVISOR_kexec_op(KEXEC_CMD_kexec_get_range, KEXEC_RANGE_MA_VMCOREINFO). The addresses I get from /sys/kernel/vmcoreinfo and from /sys/hypervisor/vmcoreinfo are machine addresses in both cases, so when a non-Xen kernel is used for dumping, everything works as expected. I am well aware that the Xen implementation in SLES differs substantially from mainline, but it seems to me that: 1. both VMCOREINFO and VMCOREINFO_XEN is required for dumpfile filtering, and 2. both sysfs files should report machine addresses, because the current
Re: [Xen-devel] Security policy ambiguities - XSA-108 process post-mortem
George Dunlap writes (Re: [Xen-devel] Security policy ambiguities - XSA-108 process post-mortem): On Mon, Nov 10, 2014 at 6:01 PM, Ian Jackson ijack...@chiark.greenend.org.uk wrote: III. Information-sharing ... List members are allowed to share fixes to embargoed issues, analysis, etc., with the security teams of other list members. Technical measures must be taken to prevents non-list-member to prevents = either which prevents or to prevent Thanks. I take it in general the technical measures you envision is pgp / gpg? No, I don't (honestly) expect anything that sophisticated. I meant that eg website downloads ought to be password protected. We should give that as an example. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Problems accessing passthrough PCI device
Hello Jan, Yes, the first thing I do in the driver is set the PCI configuration access bits to 7 that should enable IO space, Memory Space and Master BUS access. As a test I disabled this and all reads to the PCI device return -1, even the first one. I implied your earlier statement to mean that. But - did you also verify that the three flags actually end up set (ideally from both DomU and Dom0 perspective)? The PCI backend may be screwing up things... Yes I do verify the write. How do I check this from Dom0? I agree, this looks more than a hang than a crash. I've just found a link to the USB debug cable. I've ordered one but it will take a while And I hope you first verified that your system meets the criteria for this to work in the first place? I followed the checks in the Kernel earlyprintk debugging HOWTO, i.e. lspci -vvv to check the USB debug capability, and it verified. The device is ordered and now just to wait -- Best regards, Simonmailto:furryfutt...@gmail.com ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v3 for-xen-4.5] xen_disk: fix unmapping of persistent grants
This patch fixes two issues with persistent grants and the disk PV backend
(Qdisk):
- Keep track of memory regions where persistent grants have been mapped
since we need to unmap them as a whole. It is not possible to unmap a
single grant if it has been batch-mapped. A new check has also been added
to make sure persistent grants are only used if the whole mapped region
can be persistently mapped in the batch_maps case.
- Unmap persistent grants before switching to the closed state, so the
frontend can also free them.
Signed-off-by: Roger Pau Monné roger@citrix.com
Reported-by: George Dunlap george.dun...@eu.citrix.com
Cc: Stefano Stabellini stefano.stabell...@eu.citrix.com
Cc: Kevin Wolf kw...@redhat.com
Cc: Stefan Hajnoczi stefa...@redhat.com
Cc: George Dunlap george.dun...@eu.citrix.com
Cc: Konrad Rzeszutek Wilk konrad.w...@oracle.com
---
Xen release exception: this is obviously an important bug-fix that should be
included in 4.5. Without this fix, trying to do a block-detach of a Qdisk
from a running guest can lead to guest crash depending on the blkfront
implementation.
---
Changea since v2:
- Expand the commit message to mention the newly added check.
- Don't use persistent_regions in the !batch_maps case, we can use the
previous implementation which works fine in that case.
Changes since v1:
- Instead of disabling batch mappings when using persistent grants, keep
track of the persistently mapped regions and unmap them on disconnection.
This prevents unmapping single persistent grants, but the current
implementation doesn't require it.
This new version is slightly faster than the previous one, the following
test results are in IOPS from 20 runs of a block-attach, fio run,
block-detach test loop:
x batch
+ no_batch
+--+
| + + xx + + + x xx x |
|+ + x x+ *+++ * +x* +++x* x xx x *|
| |_A_M__||
||A_M___| |
+--+
N Min MaxMedian AvgStddev
x 20 52941 63822 62396 61180.15 2673.6497
+ 20 49967 63849 60322 59116.9 3456.3455
Difference at 95.0% confidence
-2063.25 +/- 1977.66
-3.37242% +/- 3.23252%
(Student's t, pooled s = 3089.88)
---
hw/block/xen_disk.c | 72 -
1 file changed, 66 insertions(+), 6 deletions(-)
diff --git a/hw/block/xen_disk.c b/hw/block/xen_disk.c
index 231e9a7..21842a0 100644
--- a/hw/block/xen_disk.c
+++ b/hw/block/xen_disk.c
@@ -59,6 +59,13 @@ struct PersistentGrant {
typedef struct PersistentGrant PersistentGrant;
+struct PersistentRegion {
+void *addr;
+int num;
+};
+
+typedef struct PersistentRegion PersistentRegion;
+
struct ioreq {
blkif_request_t req;
int16_t status;
@@ -118,6 +125,7 @@ struct XenBlkDev {
gbooleanfeature_discard;
gbooleanfeature_persistent;
GTree *persistent_gnts;
+GSList *persistent_regions;
unsigned intpersistent_gnt_count;
unsigned intmax_grants;
@@ -177,6 +185,23 @@ static void destroy_grant(gpointer pgnt)
g_free(grant);
}
+static void remove_persistent_region(gpointer data, gpointer dev)
+{
+PersistentRegion *region = data;
+struct XenBlkDev *blkdev = dev;
+XenGnttab gnt = blkdev-xendev.gnttabdev;
+
+if (xc_gnttab_munmap(gnt, region-addr, region-num) != 0) {
+xen_be_printf(blkdev-xendev, 0,
+ xc_gnttab_munmap region %p failed: %s\n,
+ region-addr, strerror(errno));
+}
+xen_be_printf(blkdev-xendev, 3,
+ unmapped grant region %p with %d pages\n,
+ region-addr, region-num);
+g_free(region);
+}
+
static struct ioreq *ioreq_start(struct XenBlkDev *blkdev)
{
struct ioreq *ioreq = NULL;
@@ -343,6 +368,7 @@ static int ioreq_map(struct ioreq *ioreq)
void *page[BLKIF_MAX_SEGMENTS_PER_REQUEST];
int i, j, new_maps = 0;
PersistentGrant *grant;
+PersistentRegion *region;
/* domids and refs variables will contain the information necessary
* to map the grants that are needed to fulfill this request.
*
@@ -421,7 +447,22 @@ static int ioreq_map(struct ioreq *ioreq)
}
}
}
-if (ioreq-blkdev-feature_persistent) {
+if (ioreq-blkdev-feature_persistent new_maps != 0
+(!batch_maps || (ioreq-blkdev-persistent_gnt_count + new_maps =
+ioreq-blkdev-max_grants))) {
+/*
+ * If we are using persistent grants and batch mappings only
+ * add the new maps
Re: [Xen-devel] [PATCH] kexec-tools: Read always one vmcoreinfo file
On Thu, 13 Nov 2014 18:22:17 +0100 Daniel Kiper daniel.ki...@oracle.com wrote: Hi Petr, On Thu, Nov 13, 2014 at 04:51:48PM +0100, Petr Tesarik wrote: Hi all, this thread got somehow forgotten because of vacations... Anyway, read below. On Tue, 24 Jul 2012 15:54:10 +0200 Daniel Kiper daniel.ki...@oracle.com wrote: On Tue, Jul 24, 2012 at 10:18:34AM +0200, Petr Tesarik wrote: Dne Po 23. ??ervence 2012 22:10:59 Daniel Kiper napsal(a): Hi Petr, On Mon, Jul 23, 2012 at 03:30:55PM +0200, Petr Tesarik wrote: Dne Po 23. ??ervence 2012 14:56:07 Petr Tesarik napsal(a): Dne ??t 5. ??ervence 2012 14:16:35 Daniel Kiper napsal(a): vmcoreinfo file could exists under /sys/kernel (valid on baremetal only) and/or under /sys/hypervisor (valid when Xen dom0 is running). Read only one of them. It means that only one PT_NOTE will be always created. Remove extra code for second PT_NOTE creation. Hi Daniel, are you absolutely sure this is the right thing to do? IIUC these two VMCORINFO notes are very different. The one from /sys/kernel/vmcoreinfo describes the Dom0 kernel (type 'VMCOREINFO'), while the one from /sys/hypervisor describes the Xen hypervisor (type 'XEN_VMCOREINFO'). If you keep only the hypervisor note, then e.g. makedumpfile won't be able to use dumplevel greater than 1, nor will it be able to extract the log buffer. I've just verified this, and I'm confident we have to keep both notes in the dump file. Simon, please revert Daniel's patch to avoid regressions. I'm attaching a sample VMCOREINFO_XEN and VMCOREINFO to demonstrate the difference. Note that the VMCOREINFO_XEN note is actually too big, because Xen doesn't bother to maintain the correct note size in the note header, so it always spans a complete page minus sizeof(Elf64_Nhdr)... [...] The problem with /sys/kernel/vmcoreinfo under Xen is that it expose invalid physical address. It breaks /proc/vmcore in crash kernel. That is why I proposed that fix. Additionally, /sys/kernel/vmcoreinfo is not available under Xen Linux Ver. 2.6.18. However, I did not do any makedumpfile tests. If you discovered any issues with my patch please drop me more details about your tests (Xen version, Linux Kernel version, makedumpfile version, command lines, config files, logs, etc.). I will be more then happy to fix/improve kexec-tools and makedumpfile. Hi Daniel, well, Linux v2.6.18 does not have /sys/kernel/vmcoreinfo, simply because the VMCOREINFO infrastructure was not present in 2.6.18. It was added later with Yep. commit fd59d231f81cb02870b9cf15f456a897f3669b4e, which went into 2.6.24. Hmmm... As I know 2.6.24 does not support kexec/kdump under Xen dom0. Correct? I tested with the following combinations: * xen-3.3.1 + kernel-xen-2.6.27.54 + kexec-tools-2.0.0 + makedumpfile-1.3.1 * xen-4.0.3 + kernel-xen-2.6.32.59 + kexec-tools-2.0.0 + makedumpfile-1.3.1 * xen-4.1.2 + kernel-xen-3.0.34 + kexec-tools-2.0.0 + makedumpfile-1.4.0 These versions correspond to SLES11-GA, SLES11-SP1 and SLES11-SP2, respectively. All of them work just fine and save both ELF notes into the dump. Could you test current kexec-tools development version and latest makedumpfile version on latest SLES version? And indeed, I've just hit this regression with SLES12 GA (kernel 3.12.28, kexec-tools 2.0.5, makedumpfile 1.5.6). In the secondary kernel, makedumpfile complains that VMCOREINFO is not stored in /proc/vmcore: bash-4.2# makedumpfile -d 31 -X -E /proc/vmcore /kdump/mnt1/abuild/dumps/2014-11-13-13\:13/vmcore.elf Switched running mode from cyclic to non-cyclic, because the cyclic mode doesn't support Xen. /proc/vmcore doesn't contain vmcoreinfo. Specify '-x' option or '-i' option. Commandline parameter is invalid. Try `makedumpfile --help' for more information. makedumpfile Failed. Then I reverted commit 455d79f57e9367e5c59093fd74798905bd5762fc and everything works just fine. What do you mean by invalid physical address? I'm getting the correct physical address under Xen. Obviously, it must be translated to machine addresses if you need them from the secondary kernel. Correct vmcoreinfo address should be established by calling HYPERVISOR_kexec_op(KEXEC_CMD_kexec_get_range, KEXEC_RANGE_MA_VMCOREINFO). The addresses I get from /sys/kernel/vmcoreinfo and from /sys/hypervisor/vmcoreinfo are machine addresses in both cases, so when a non-Xen kernel is used for dumping, everything works as expected. I am well aware that the Xen
Re: [Xen-devel] XenServer results from the Test Day for RC2
On Thu, Nov 13, 2014 at 04:02:47PM +, Andrew Cooper wrote: Hi, While attempting to test Konrads new interrupt injection logic, I got blocked behind yet another Pygrub bug caused by c/s d1b93ea This is the first time I have looked into the issue, but a cursory inspection of the first hunk shows that it cannot possibly be correct as self._default is either an integer or string. I have a possible workaround which I am testing, but cursory review of the patch would have shown that it cannot work as intended. Notice that self._default is now either a string or an integer, defaulting to an integer, and the top level code is updated to require a string. As a result, any bootloader configuration which doesn't explicitly set a default, or still drives this logic with integers (ExtLinux or LiLO) will die with an AttributeError Thank you for testing it. In case you don't get to it - and are preempted by other stuff - please do give me a braindump (and preliminary patch if you have one) so I can dig into it. Thank you! ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2] xen: remove Xencomm
On Thu, Nov 13, 2014 at 04:18:58PM +, Jan Beulich wrote: On 13.11.14 at 17:03, t...@xen.org wrote: Being a feature that has only been used by ia64 and/or ppc it doesn't seem like we need to keep it any longer in the tree. So remove it. Signed-off-by: Boris Ostrovsky boris.ostrov...@oracle.com Signed-off-by: Tim Deegan t...@xen.org Acked-by: Jan Beulich jbeul...@suse.com Are folks OK if this is deferred to Xen 4.6? Thank you! ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [TestDay] VMX test report for Xen 4.5.0-rc1
-Original Message- From: Fabio Fantoni [mailto:fabio.fant...@m2r.biz] Sent: Wednesday, November 12, 2014 5:59 PM To: Hu, Robert; xen-devel@lists.xen.org Cc: jbeul...@suse.com Subject: Re: [Xen-devel] [TestDay] VMX test report for Xen 4.5.0-rc1 Il 12/11/2014 07:58, Hu, Robert ha scritto: Hi All, This is a bug summary for Xen 4.5-rc1 on Intel Server platforms. Test environment: Xen: Xen 4.5-rc1 Dom0: Linux kernel 3.17.0 Hardware: Intel IVT-EX, Haswell-EP, BDW Client, HSW-EX, IVT-EX, HSW-UP New bugs(9): 1. with xen_platform_pci=0 option, the guest with VT-d device fails to boot up http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1893 Have you tried with recent domU's kernel that contain this commit? https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=51c71a 3bbaca868043cc45b3ad3786dd48a90235 If I remember good there is a critical boot problem with xen_platform_pci=0 and without it. 2. Failed to hotplug a VT-d device with XEN4.5-RC1 http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1894 3. Fail to hot add multi devices to guest http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1895 4. Not all PFs are available if assign multi VT-d devices to Wndows guest VM http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1896 5. Dom0 failed to resume from S3 power state http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1897 6. Networking is unavailable after saverestore Windows guest http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1898 Should be the same problem I reported 1 year ago or more and still present, the workaround is use fixed mac address in domUs xl cfg :( http://lists.xen.org/archives/html/xen-devel/2013-04/msg02459.html http://lists.xen.org/archives/html/xen-devel/2013-04/msg02747.html if we assign vif as following, it works with fix-mac. # Network devices vif = [ 'type=ioemu, mac=00:15:17:19:2D:35, bridge=xenbr0' ] if we assign VF to guest as following, it till don't have network working with fix-mac; after saverestore, the networking status shows as Network cable unplugged, without IP address. #SR-IOV VF device BDF pci = [ '81:10.1' ] 7. Error msg occurred after attaching multi SR-IOV VF device to running guest http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1899 8. xl vcpu-set will report error when adding vcpus number http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1900 9. xl psr-cmt-show cache_occupancy $dom_id will report error http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1901 1 old legacy bug(1): 1. Guest hang after resume from S3 http://bugzilla-archived.xenproject.org/bugzilla/show_bug.cgi?id=1828 Best Regards, Robert ___ 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
