[Xen-devel] [xen-unstable-smoke test] 88647: regressions - FAIL
flight 88647 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/88647/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-libvirt 5 libvirt-build fail REGR. vs. 88144 build-armhf 5 xen-build fail REGR. vs. 88144 Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a version targeted for testing: xen d887c19f00c58e67086f3a9885883f470ea35ba2 baseline version: xen 96ae556569b8eaedc0bb242932842c3277b515d8 Last test of basis88144 2016-03-31 13:06:39 Z3 days Failing since 88279 2016-04-01 14:03:55 Z2 days 31 attempts Testing same since88315 2016-04-01 20:03:45 Z2 days 28 attempts People who touched revisions under test: Andrew Cooper Changlong Xie Chong Li Dario Faggioli George Dunlap Ian Campbell Ian Jackson Jan Beulich Juergen Gross Kevin Tian Konrad Rzeszutek Wilk Meng Xu Olaf Hering Paul Durrant Roger Pau Monne Roger Pau Monné Sisu Xi Wei Liu Wen Congyang Yang Hongyang jobs: build-amd64 pass build-armhf fail build-amd64-libvirt fail test-armhf-armhf-xl blocked test-amd64-amd64-xl-qemuu-debianhvm-i386 pass test-amd64-amd64-libvirt blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 799 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] HPA <-> GPA mapping
>>> On 04.04.16 at 10:04, wrote: > Does Xen under any circumstances ever modify GPA -> HPA translations > _while_ a HVM guest is running? I could find no cases where that would > happen, but I would appreciate an authoritative answer. Of course we do, namely when asked to by the guest itself (see grant table operations or XENMEM_*_physmap). Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Getting rid of inside_vm in intel8x0
On 02/04/16 13:57, Andy Lutomirski wrote: > On Fri, Apr 1, 2016 at 10:33 PM, Takashi Iwai wrote: >> On Sat, 02 Apr 2016 00:28:31 +0200, >> Luis R. Rodriguez wrote: >>> If the former, could a we somehow detect an emulated device other than >>> through >>> this type of check ? Or could we *add* a capability of some sort to detect >>> it >>> on the driver ? This would not address the removal, but it could mean >>> finding a >>> way to address emulation issues. >>> >>> If its an IO issue -- exactly what is the causing the delays in IO ? >> >> Luis, there is no problem about emulation itself. It's rather an >> optimization to lighten the host side load, as I/O access on a VM is >> much heavier. >> >> This is satisfied mostly only on VM, and can't >> be measured easily unlike the IO read speed. > > Interesting, note the original patch claimed it was for KVM and > Parallels hypervisor only, but since the code uses: > > +#if defined(__i386__) || defined(__x86_64__) > + inside_vm = inside_vm || > boot_cpu_has(X86_FEATURE_HYPERVISOR); > +#endif > > This makes it apply also to Xen as well, this makes this hack more > broad, but does is it only applicable when an emulated device is > used ? What about if a hypervisor is used and PCI passthrough is > used ? A good question. Xen was added there at the time from positive results by quick tests, but it might show an issue if it's running on a very old chip with PCI passthrough. But I'm not sure whether PCI passthrough would work on such old chipsets at all. >>> >>> If it did have an issue then that would have to be special cased, that >>> is the module parameter would not need to be enabled for such type of >>> systems, and heuristics would be needed. As you note, fortunately this >>> may not be common though... >> >> Actually this *is* module parametered. If set to a boolean value, it >> can be applied / skipped forcibly. So, if there has been a problem on >> Xen, this should have been reported. That's why I wrote it's no >> common case. This comes from the real experience. >> >>> but if this type of work around may be >>> taken as a precedent to enable other types of hacks in other drivers >>> I'm very fearful of more hacks later needing these considerations as >>> well. >>> >>> There are a pile of nonsensical "are we in a VM" checks of various >>> sorts scattered throughout the kernel, they're all a mess to maintain >>> (there are lots of kinds of VMs in the world, and Linux may not even >>> know it's a guest), and, in most cases, it appears that the correct >>> solution is to delete the checks. I just removed a nasty one in the >>> x86_32 entry asm, and this one is written in C so it should be a piece >>> of cake :) >> >> This cake looks sweet, but a worm is hidden behind the cream. >> The loop in the code itself is already a kludge for the buggy hardware >> where the inconsistent read happens not so often (only at the boundary >> and in a racy way). It would be nice if we can have a more reliably >> way to know the hardware buggyness, but it's difficult, >> unsurprisingly. > > The concern here is setting precedents for VM cases sprinkled in the > kernel. > The assumption here is such special cases are really paper'ing over > another > type of issue, so its best to ultimately try to root cause the issue in > a more generalized fashion. Well, it's rather bare metal that shows the buggy behavior, thus we need to paper over it. In that sense, it's other way round; we don't tune for VM. The VM check we're discussing is rather for skipping the strange workaround. >>> >>> What is it exactly about a VM that enables this work around to be skipped? >>> I don't quite get it yet. >> >> VM -- at least the full one with the sound hardware emulation -- >> doesn't have the hardware bug. So, the check isn't needed. > > Here's the issue, though: asking "am I in a VM" is not a good way to > learn properties of hardware. Just off the top of my head, here are > some types of VM and what they might imply about hardware: > > Intel Kernel Guard: your sound card is passed through from real hardware. > > Xen: could go either way. In dom0, it's likely passed through. In > domU, it could be passed through or emulated, and I believe this is > the case for all of the Xen variants. > > KVM: Probably emulated, but could be passed through. I'm not sure exactly why I was CC'd into this thread, but this is an important point -- even if you're running in a VM, you may actually have direct un-emulated IO access to a real (buggy) piece of hardware; in which case it sounds like you still need the work-around. So boot_cpu_has(X86_FEATURE_HYPERVISOR) is probably not the right check. -George ___ Xen-devel mailing list Xen-devel@
[Xen-devel] [linux-linus test] 88539: regressions - FAIL
flight 88539 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/88539/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-rumpuserxen6 xen-build fail REGR. vs. 59254 test-amd64-amd64-xl-credit2 15 guest-localmigratefail REGR. vs. 59254 build-amd64-rumpuserxen 6 xen-build fail REGR. vs. 59254 test-amd64-amd64-xl 14 guest-saverestore fail REGR. vs. 59254 test-amd64-amd64-xl-xsm 15 guest-localmigratefail REGR. vs. 59254 test-amd64-i386-xl-xsm 15 guest-localmigratefail REGR. vs. 59254 test-amd64-amd64-xl-multivcpu 14 guest-saverestorefail REGR. vs. 59254 test-amd64-i386-xl 15 guest-localmigratefail REGR. vs. 59254 test-armhf-armhf-xl-multivcpu 11 guest-start fail REGR. vs. 59254 test-amd64-amd64-pair 22 guest-migrate/dst_host/src_host fail REGR. vs. 59254 test-amd64-i386-pair 22 guest-migrate/dst_host/src_host fail REGR. vs. 59254 test-armhf-armhf-xl-credit2 16 guest-start.2 fail REGR. vs. 59254 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 13 guest-localmigrate fail REGR. vs. 59254 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-rtds 15 guest-localmigratefail REGR. vs. 59254 test-armhf-armhf-xl-rtds 11 guest-start fail REGR. vs. 59254 test-amd64-amd64-libvirt-pair 22 guest-migrate/dst_host/src_host fail baseline untested test-amd64-i386-libvirt-pair 21 guest-migrate/src_host/dst_host fail baseline untested test-armhf-armhf-xl-vhd 9 debian-di-install fail baseline untested test-amd64-i386-libvirt-xsm 15 guest-saverestore.2 fail blocked in 59254 test-amd64-i386-libvirt 15 guest-saverestore.2 fail blocked in 59254 test-amd64-amd64-libvirt-xsm 15 guest-saverestore.2 fail blocked in 59254 test-amd64-amd64-libvirt 14 guest-saverestorefail blocked in 59254 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 59254 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 59254 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 59254 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 59254 Tests which did not succeed, but are not blocking: test-amd64-amd64-rumpuserxen-amd64 1 build-check(1) blocked n/a test-amd64-i386-rumpuserxen-i386 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-xl-pvh-intel 14 guest-saverestorefail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass test-amd64-amd64-qemuu-nested-intel 13 xen-boot/l1 fail never pass test-armhf-armhf-libvirt-raw 13 guest-saverestorefail never pass test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 13 xen-boot/l1 fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail never pass test-armhf-armhf-libvirt 14 guest-saverestorefail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 saverestore-support-checkfail never pass version targeted for testing: linux4c3b73c6a2ee
Re: [Xen-devel] xen-utils not running within xen or no compatible utils
On Sun, Apr 03, 2016 at 02:38:41PM +0200, aicha hamza wrote: > but how can i prebuild the image from somewhere !! > Try using Debian debootstrap? I don't normally use xen-tools or Xen on ARM so I don't really have good recommendations. Maybe also search wiki.xenproject.org to see if there is anything useful? Wei. > On Fri, Apr 1, 2016 at 6:47 PM, Wei Liu wrote: > > > Add back xen-devel > > > > On Fri, Apr 01, 2016 at 05:45:31PM +0200, aicha hamza wrote: > > > yes i compiled xen from the source .. this is exactly what i did > > > > > http://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions/OMAP5432_uEVM > > > > > > and i get xen running in my board .. but i can't build guest because > > there > > > > So this is done. Good. I misread. > > > > > is no xen-utils-common > > > and as i told you before there is internet connection in my board .. so > > how > > > can i get sen.utils package !! > > > > > > > As far as I can tell xen-tools uses Debian debootstrap to build a guest > > which means you have to have Internet connection. Maybe you can prebuild > > the image from somewhere. > > > > Julien, do you have pointers on how to get an ARM guest image? > > > > Wei. > > ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] Mini-OS: netfront: fix off-by-one error introduced in 7c8f3483
On Fri, Apr 01, 2016 at 08:26:16PM +0200, Samuel Thibault wrote: > 7c8f3483 introduced a break within a loop in netfront.c such that > cons and nr_consumed were no longer always being incremented. The > offset at cons will be processed multiple times with the break in > place. > > This commit reverts to using the "some" variable in the loop condition, > but avoids ifdefs for the non-libc case. It also renames it to dobreak > to make its usage clearer. > > Suggested-by: Sarah Newman > Signed-off-by: Samuel Thibault > Tested-by: Sarah Newman Queued. Thank you both! ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] Fixed --enable-systemd on latest Debian stretch. Added xencommons as a systemd.service.
On Sat, Apr 02, 2016 at 01:24:07PM +0200, Sjoer van der Ploeg wrote: > Well if you install ocaml-nox oxenstored is made default, so I tested both > situations this morning with and without ocaml. That location is not > causing the problem, as it happened without ocaml too. The install path for > ocaml is worth checking, as it should not default to /usr/local, after > grepping the files I found one occurrence of /usr/local > in configure:ac_default_prefix=/usr/local (requires further investigation. This is not a problem. That's the default value if you don't have --prefix in ./configure invocation. Could you post the exact commands you used to produce the problem? Wei. > > Starting the xendomains systemd service manually works on a fresh install. > Enabling the xendomains systemd service does not. > > After I had enabled xencommons through update-rc.d once, the systemd > service for xendomains would enable. > > I am not at home over the weekend, but have remote access to the machines > at home so might test further when I get the chance. > > > Yours, > > Sjoer van der Ploeg > > On Sat, Apr 2, 2016 at 12:59 PM, Wei Liu wrote: > > > On Sat, Apr 02, 2016 at 02:45:41AM +0200, Sjoer van der Ploeg wrote: > > > Just finished a fresh testbed, xendomains still refused to get enabled > > when > > > using --prefix=/usr and modules did load. > > > > > > Took a look at /usr/local (which was non-existent before make install), > > > ocaml dumped its files there in /usr/local/lib and after moving that > > > directory into /usr/lib I could systemctl enable xendomains without an > > > error! > > > > > > I'll double check it over the weekend to confirm the issue, find the > > exact > > > cause and submit a fix. > > > > > > > Did you perhaps use ocaml xenstored implementation? Then there might be > > a problem with its install target. > > > > The ocaml tools are under tools/ocaml directory if you want to check. > > > > Wei. > > > > > Yours, > > > > > > Sjoer van der Ploeg > > > On Apr 1, 2016 9:43 PM, "Olaf Hering" wrote: > > > > > > > On Fri, Apr 01, Wei Liu wrote: > > > > > > > > > Ah, so it is the kernel modules that are not loaded. I can see why > > that > > > > > would be a problem. My experience with systemd is a bit rusty at the > > > > > moment. I will find some time to have a look at this next week. > > > > > > > > They get loaded via the system-modules-load.service, perhaps that one > > is > > > > disabled. > > > > > > > > Olaf > > > > > > ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 03/16] xen: sched: make implementing .alloc_pdata optional
>>> On 01.04.16 at 19:01, wrote:
> On Mon, 2016-03-21 at 09:07 -0600, Jan Beulich wrote:
>> > > > On 21.03.16 at 15:48, wrote:
>> > On 18/03/16 20:04, Dario Faggioli wrote:
>> > > @@ -1491,9 +1491,9 @@ static int cpu_schedule_up(unsigned int
>> > > cpu)
>> > > if ( idle_vcpu[cpu] == NULL )
>> > > return -ENOMEM;
>> > >
>> > > -if ( (ops.alloc_pdata != NULL) &&
>> > > - ((sd->sched_priv = ops.alloc_pdata(&ops, cpu)) == NULL)
>> > > )
>> > > -return -ENOMEM;
>> > > +sd->sched_priv = SCHED_OP(&ops, alloc_pdata, cpu);
>> > > +if ( IS_ERR(sd->sched_priv) )
>> > > +return PTR_ERR(sd->sched_priv);
>> > Calling xfree() with an IS_ERR() value might be a bad idea.
>> > Either you need to set sd->sched_priv to NULL in error case or you
>> > modify xfree() to return immediately not only in the NULL case, but
>> > in the IS_ERR() case as well.
>> The latter option is a no-go imo.
>>
> Ok, I'll do:
>
> sd->sched_priv = SCHED_OP(&ops, alloc_pdata, cpu);
> if ( IS_ERR(sd->sched_priv) )
> {
> int err = PTR_ERR(sd->sched_priv);
>
> sd->sched_priv = NULL;
> return err;
> }
>
> Is this ok?
Depends: Can ->sched_priv be looked at by another CPU between
the first and second assignments? If yes, you need to use an
intermediary local variable.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [linux-4.1 test] 88510: regressions - FAIL
flight 88510 linux-4.1 real [real] http://logs.test-lab.xenproject.org/osstest/logs/88510/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 3 host-install(3) broken in 87395 REGR. vs. 66399 build-amd64-rumpuserxen 6 xen-build fail REGR. vs. 66399 build-i386-rumpuserxen6 xen-build fail REGR. vs. 66399 Tests which are failing intermittently (not blocking): test-armhf-armhf-xl-multivcpu 15 guest-start/debian.repeat fail in 86830 pass in 88510 test-armhf-armhf-xl-xsm 16 guest-start.2 fail in 87117 pass in 86830 test-armhf-armhf-xl 15 guest-start/debian.repeat fail in 87204 pass in 88073 test-armhf-armhf-xl-rtds 11 guest-startfail in 87204 pass in 88510 test-armhf-armhf-xl-cubietruck 11 guest-start fail in 87204 pass in 88510 test-armhf-armhf-libvirt-qcow2 6 xen-boot fail in 87204 pass in 88510 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail in 87295 pass in 88510 test-amd64-amd64-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail in 87295 pass in 88510 test-armhf-armhf-xl-credit2 16 guest-start.2 fail in 87395 pass in 87295 test-armhf-armhf-xl-credit2 11 guest-startfail in 87582 pass in 88510 test-armhf-armhf-xl-multivcpu 11 guest-start fail in 87582 pass in 88510 test-armhf-armhf-libvirt 6 xen-boot fail in 88073 pass in 88510 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 15 guest-localmigrate/x10 fail in 88073 pass in 88510 test-armhf-armhf-xl-xsm 15 guest-start/debian.repeat fail pass in 87117 test-amd64-amd64-libvirt-pair 21 guest-migrate/src_host/dst_host fail pass in 87204 test-armhf-armhf-xl-credit2 15 guest-start/debian.repeat fail pass in 87395 test-amd64-i386-libvirt-pair 21 guest-migrate/src_host/dst_host fail pass in 87582 test-armhf-armhf-xl 11 guest-start fail pass in 88251 test-armhf-armhf-xl-cubietruck 15 guest-start/debian.repeat fail pass in 88251 test-armhf-armhf-xl-arndale 9 debian-install fail pass in 88390 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-libvirt-qcow2 9 debian-di-install fail in 88251 like 66399 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 66399 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 66399 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 66399 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeatfail like 66399 test-armhf-armhf-xl-vhd 9 debian-di-installfail like 66399 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 66399 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1)blocked in 87395 n/a build-amd64-rumpuserxen 1 build-check(1)blocked in 87395 n/a test-amd64-amd64-xl-pvh-intel 1 build-check(1) blocked in 87395 n/a test-amd64-amd64-xl-pvh-amd 1 build-check(1)blocked in 87395 n/a test-amd64-amd64-xl-multivcpu 1 build-check(1) blocked in 87395 n/a test-amd64-amd64-xl 1 build-check(1)blocked in 87395 n/a test-amd64-i386-xl1 build-check(1)blocked in 87395 n/a test-amd64-i386-pair 1 build-check(1)blocked in 87395 n/a test-amd64-amd64-libvirt 1 build-check(1)blocked in 87395 n/a test-amd64-amd64-xl-credit2 1 build-check(1)blocked in 87395 n/a test-amd64-i386-libvirt 1 build-check(1)blocked in 87395 n/a test-amd64-amd64-libvirt-xsm 1 build-check(1)blocked in 87395 n/a test-amd64-amd64-i386-pvgrub 1 build-check(1)blocked in 87395 n/a test-amd64-amd64-pair 1 build-check(1)blocked in 87395 n/a test-amd64-i386-qemut-rhel6hvm-amd 1 build-check(1) blocked in 87395 n/a test-amd64-amd64-pygrub 1 build-check(1)blocked in 87395 n/a test-amd64-amd64-xl-rtds 1 build-check(1)blocked in 87395 n/a test-amd64-amd64-amd64-pvgrub 1 build-check(1) blocked in 87395 n/a test-amd64-i386-libvirt-pair 1 build-check(1)blocked in 87395 n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked in 87395 n/a test-amd64-amd64-xl-qcow2 1 build-check(1)blocked in 87395 n/a test-amd64-amd64-libvirt-pair 1 build-check(1) blocked in 87395 n/a test-amd64-amd64-qemuu-nested-amd 1 build-check(1) blocked in 87395 n/a test-amd64-i386-qemuu-rhel6hvm-amd 1 build-check(1) blocked in 87395 n/a test-amd64-i386-qemuu-rhel6hvm-intel 1 build-check(1)blocked in 87395 n/a test-amd64-i386-freebsd10-amd64 1 build-check(1) blocked in 87395 n/a test-amd64-i386-xl-qemut-win7-amd64 1 build-check(1) blocked
Re: [Xen-devel] xen-utils not running within xen or no compatible utils
what you mean by using debian debootstrap !! how can i work with it ! On Mon, Apr 4, 2016 at 12:27 PM, Wei Liu wrote: > On Sun, Apr 03, 2016 at 02:38:41PM +0200, aicha hamza wrote: > > but how can i prebuild the image from somewhere !! > > > > Try using Debian debootstrap? I don't normally use xen-tools or Xen on > ARM so I don't really have good recommendations. > > Maybe also search wiki.xenproject.org to see if there is anything > useful? > > Wei. > > > On Fri, Apr 1, 2016 at 6:47 PM, Wei Liu wrote: > > > > > Add back xen-devel > > > > > > On Fri, Apr 01, 2016 at 05:45:31PM +0200, aicha hamza wrote: > > > > yes i compiled xen from the source .. this is exactly what i did > > > > > > > > http://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions/OMAP5432_uEVM > > > > > > > > and i get xen running in my board .. but i can't build guest because > > > there > > > > > > So this is done. Good. I misread. > > > > > > > is no xen-utils-common > > > > and as i told you before there is internet connection in my board .. > so > > > how > > > > can i get sen.utils package !! > > > > > > > > > > As far as I can tell xen-tools uses Debian debootstrap to build a guest > > > which means you have to have Internet connection. Maybe you can > prebuild > > > the image from somewhere. > > > > > > Julien, do you have pointers on how to get an ARM guest image? > > > > > > Wei. > > > > ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [GIT PULL] xen: regression and bug fixes for 4.6-rc2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Linus, Please git pull the following tag: git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git for-linus-4.6-rc2-tag xen: regression and bug fixes for 4.6-rc2 - - Safely migrate event channels between CPUs. - - Fix CPU hotplug. - - Maintainer changes. Thanks. David MAINTAINERS | 10 +- arch/x86/xen/apic.c | 12 ++-- arch/x86/xen/smp.c | 2 ++ drivers/xen/events/events_base.c | 28 4 files changed, 41 insertions(+), 11 deletions(-) Boris Ostrovsky (3): xen/apic: Provide Xen-specific version of cpu_present_to_apicid APIC op xen/x86: Call cpu_startup_entry(CPUHP_AP_ONLINE_IDLE) from xen_play_dead() xen/events: Mask a moving irq Konrad Rzeszutek Wilk (1): MAINTAINERS: xen: Konrad to step down and Juergen to pick up Stefano Stabellini (1): Xen on ARM and ARM64: update MAINTAINERS info -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJXAkSyAAoJEFxbo/MsZsTRcpQIAKZzi6hF5QdQqQzwkKmP/TFV NVDvZeeU63J3MvV2eZlv49n/Ut1Q5na6HVn7B/mCN5z+Uf36Oo46C6+AJ6Uk08E6 Mwz7jrbtas5HqVAR/Hql10/qLQcScbxS4bRRLkqr9NSYtwoex+Q4SSMv8t6UKXrO aegsDfeyvrLjbjqK4amTlaBwUrfnPVNeRBd4S03C4MhFV96+N0XLPe+R6kEzI8oO OHNsWOHy9RRA0CTARk4jY07vVm3MXJI28NeX+2YK+RRg68ko/tafNVa5Ez3pu5IH 5b7YB8+bdR0AyuaAi0/LoyET5fMPzAzJ3O4JBuLk/KPfD2ouHqtxjlIhKEFEb6Y= =Y92Q -END PGP SIGNATURE- ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] HPA <-> GPA mapping
Hello, Does Xen under any circumstances ever modify GPA -> HPA translations _while_ a HVM guest is running? I could find no cases where that would happen, but I would appreciate an authoritative answer. Thanks, Razvan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] xen-utils not running within xen or no compatible utils
On Mon, Apr 04, 2016 at 12:40:30PM +0200, aicha hamza wrote: > what you mean by using debian debootstrap !! how can i work with it ! > http://lmgtfy.com/?q=debian+debootstrap Google is your friend. :-) And please read http://wiki.xenproject.org/wiki/Asking_Developer_Questions Wei. > On Mon, Apr 4, 2016 at 12:27 PM, Wei Liu wrote: > > > On Sun, Apr 03, 2016 at 02:38:41PM +0200, aicha hamza wrote: > > > but how can i prebuild the image from somewhere !! > > > > > > > Try using Debian debootstrap? I don't normally use xen-tools or Xen on > > ARM so I don't really have good recommendations. > > > > Maybe also search wiki.xenproject.org to see if there is anything > > useful? > > > > Wei. > > > > > On Fri, Apr 1, 2016 at 6:47 PM, Wei Liu wrote: > > > > > > > Add back xen-devel > > > > > > > > On Fri, Apr 01, 2016 at 05:45:31PM +0200, aicha hamza wrote: > > > > > yes i compiled xen from the source .. this is exactly what i did > > > > > > > > > > > http://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions/OMAP5432_uEVM > > > > > > > > > > and i get xen running in my board .. but i can't build guest because > > > > there > > > > > > > > So this is done. Good. I misread. > > > > > > > > > is no xen-utils-common > > > > > and as i told you before there is internet connection in my board .. > > so > > > > how > > > > > can i get sen.utils package !! > > > > > > > > > > > > > As far as I can tell xen-tools uses Debian debootstrap to build a guest > > > > which means you have to have Internet connection. Maybe you can > > prebuild > > > > the image from somewhere. > > > > > > > > Julien, do you have pointers on how to get an ARM guest image? > > > > > > > > Wei. > > > > > > ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen: write information about supported backends
On 30/03/16 15:10, Juergen Gross wrote: > Add a Xenstore directory for each supported pv backend. This will allow > Xen tools to decide which backend type to use in case there are > multiple possibilities. > > The information is added under > /local/domain//device-model//backends > before the "running" state is written to Xenstore. Using a directory > for each directory enables us to add parameters for specific backends > in the future. "Using a directory for each backend..."? > > In order to reuse the Xenstore directory creation already present in > hw/xen/xen_devconfig.c move the related functions to > hw/xen/xen_backend.c where they fit better. Why Xenstore and not QMP? David ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] libxl: fix compilation on ARM
Wei Liu writes ("[PATCH] libxl: fix compilation on ARM"):
> COLO introduced a few callbacks. The original implementation used
> unsigned long for a type which in fact should be xen_pfn_t. That broke
> libxl compilation on ARM, because xen_pfn_t is not a synonym for
> unsigned long on ARM platform.
>
> Fixing this requires modifying the perl script. Specifically now we need
> to include xenctrl.h in helper header file so that we can use xen_pfn_t
> there.
>
> Reported-by: Olaf Hering
> Signed-off-by: Wei Liu
Following discussion on irc, here is a v2:
* AFAICT all that's needed is to change the ordering of the headers
before END_HELPER. _libxl_save_msgs_helper.h isn't a "proper"
header: it has no multiple inclusion protection, either. It's for
use in only the two places. (_libxl_save_msgs_helper.c and
libxl_save_helper.c - both of which already have xenctrl.h) I think
I prefer to perhpas-duplicate some #include lines to adding a new
facility to the Perl script (which I would like to keep no more
complex than necessary).
* Better patch title.
Thanks,
Ian.
From ca9654206863224cbf2cc998d8f6a2bd6c1511b3 Mon Sep 17 00:00:00 2001
From: Ian Jackson
Date: Mon, 4 Apr 2016 11:41:19 +0100
Subject: [PATCH] libxl: ARM build: fix type of
libxl__srm_callout_callback_restore_results
COLO introduced a few callbacks. The original implementation used
unsigned long for a type which in fact should be xen_pfn_t. That broke
libxl compilation on ARM, because xen_pfn_t is not a synonym for
unsigned long on ARM platform.
Fixing this requires modifying the perl script. Specifically now we need
to include xenctrl.h in helper header file so that we can use xen_pfn_t
there.
Reported-by: Olaf Hering
Signed-off-by: Wei Liu
Signed-off-by: Ian Jackson
---
tools/libxl/libxl_create.c |4 ++--
tools/libxl/libxl_save_msgs_gen.pl |8
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 6882ff8..4b02de9 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -1109,8 +1109,8 @@ static void domcreate_bootloader_done(libxl__egc *egc,
domcreate_stream_done(egc, &dcs->srs, rc);
}
-void libxl__srm_callout_callback_restore_results(unsigned long store_mfn,
- unsigned long console_mfn, void *user)
+void libxl__srm_callout_callback_restore_results(xen_pfn_t store_mfn,
+ xen_pfn_t console_mfn, void *user)
{
libxl__save_helper_state *shs = user;
libxl__domain_create_state *dcs = shs->caller_state;
diff --git a/tools/libxl/libxl_save_msgs_gen.pl
b/tools/libxl/libxl_save_msgs_gen.pl
index c2243f2..3ae7373 100755
--- a/tools/libxl/libxl_save_msgs_gen.pl
+++ b/tools/libxl/libxl_save_msgs_gen.pl
@@ -29,8 +29,8 @@ our @msgs = (
[ 6, 'srcxA', "wait_checkpoint", [] ],
[ 7, 'scxA', "switch_qemu_logdirty", [qw(int domid
unsigned enable)] ],
-[ 8, 'rcx',"restore_results", ['unsigned long', 'store_gfn',
- 'unsigned long', 'console_gfn']
],
+[ 8, 'rcx',"restore_results", ['xen_pfn_t', 'store_gfn',
+ 'xen_pfn_t', 'console_gfn'] ],
[ 9, 'srW',"complete", [qw(int retval
int errnoval)] ],
);
@@ -70,9 +70,9 @@ END_BOTH
END_CALLOUT
-#include "_libxl_save_msgs_${ah}.h"
#include
#include
+#include "_libxl_save_msgs_${ah}.h"
END_HELPER
}
@@ -141,7 +141,7 @@ static void bytes_put(unsigned char *const buf, int *len,
END
-foreach my $simpletype (qw(int uint16_t uint32_t unsigned), 'unsigned long') {
+foreach my $simpletype (qw(int uint16_t uint32_t unsigned), 'unsigned long',
'xen_pfn_t') {
my $typeid = typeid($simpletype);
$out_body{'callout'} .=
Re: [Xen-devel] [PATCH] xen: write information about supported backends
On 04/04/16 11:18, David Vrabel wrote: > On 30/03/16 15:10, Juergen Gross wrote: >> Add a Xenstore directory for each supported pv backend. This will allow >> Xen tools to decide which backend type to use in case there are >> multiple possibilities. >> >> The information is added under >> /local/domain//device-model//backends >> before the "running" state is written to Xenstore. Using a directory >> for each directory enables us to add parameters for specific backends >> in the future. > > "Using a directory for each backend..."? Yes. As I've written: this enables us to enhance the interface later without the need to modify it first. >> In order to reuse the Xenstore directory creation already present in >> hw/xen/xen_devconfig.c move the related functions to >> hw/xen/xen_backend.c where they fit better. > > Why Xenstore and not QMP? We need to communicate with qemu only once instead of each time a device is added to the domain. Doing the communication via Xenstore is much simpler. Juergen ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] libxl: fix compilation on ARM
Ian Jackson writes ("Re: [PATCH] libxl: fix compilation on ARM"):
> Following discussion on irc, here is a v2:
I forgot to update the commit message.
Ian.
From 4cbc583020642d6c333d07e297c52594bb88b542 Mon Sep 17 00:00:00 2001
From: Ian Jackson
Date: Mon, 4 Apr 2016 11:41:19 +0100
Subject: [PATCH] libxl: ARM build: fix type of
libxl__srm_callout_callback_restore_results
COLO introduced a few callbacks. The original implementation used
unsigned long for a type which in fact should be xen_pfn_t. That broke
libxl compilation on ARM, because xen_pfn_t is not a synonym for
unsigned long on ARM platform.
Fixing this requires modifying the perl script: specifically now we
need to include xenctrl.h before _libxl_save_msgs_*.h, rather than
afterwards, so that we can use xen_pfn_t there.
Reported-by: Olaf Hering
Signed-off-by: Wei Liu
Signed-off-by: Ian Jackson
---
tools/libxl/libxl_create.c |4 ++--
tools/libxl/libxl_save_msgs_gen.pl |8
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 6882ff8..4b02de9 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -1109,8 +1109,8 @@ static void domcreate_bootloader_done(libxl__egc *egc,
domcreate_stream_done(egc, &dcs->srs, rc);
}
-void libxl__srm_callout_callback_restore_results(unsigned long store_mfn,
- unsigned long console_mfn, void *user)
+void libxl__srm_callout_callback_restore_results(xen_pfn_t store_mfn,
+ xen_pfn_t console_mfn, void *user)
{
libxl__save_helper_state *shs = user;
libxl__domain_create_state *dcs = shs->caller_state;
diff --git a/tools/libxl/libxl_save_msgs_gen.pl
b/tools/libxl/libxl_save_msgs_gen.pl
index c2243f2..3ae7373 100755
--- a/tools/libxl/libxl_save_msgs_gen.pl
+++ b/tools/libxl/libxl_save_msgs_gen.pl
@@ -29,8 +29,8 @@ our @msgs = (
[ 6, 'srcxA', "wait_checkpoint", [] ],
[ 7, 'scxA', "switch_qemu_logdirty", [qw(int domid
unsigned enable)] ],
-[ 8, 'rcx',"restore_results", ['unsigned long', 'store_gfn',
- 'unsigned long', 'console_gfn']
],
+[ 8, 'rcx',"restore_results", ['xen_pfn_t', 'store_gfn',
+ 'xen_pfn_t', 'console_gfn'] ],
[ 9, 'srW',"complete", [qw(int retval
int errnoval)] ],
);
@@ -70,9 +70,9 @@ END_BOTH
END_CALLOUT
-#include "_libxl_save_msgs_${ah}.h"
#include
#include
+#include "_libxl_save_msgs_${ah}.h"
END_HELPER
}
@@ -141,7 +141,7 @@ static void bytes_put(unsigned char *const buf, int *len,
END
-foreach my $simpletype (qw(int uint16_t uint32_t unsigned), 'unsigned long') {
+foreach my $simpletype (qw(int uint16_t uint32_t unsigned), 'unsigned long',
'xen_pfn_t') {
my $typeid = typeid($simpletype);
$out_body{'callout'} .=
Re: [Xen-devel] [PATCH] libxl: fix compilation on ARM
On Mon, Apr 04, 2016 at 11:48:59AM +0100, Ian Jackson wrote:
> Ian Jackson writes ("Re: [PATCH] libxl: fix compilation on ARM"):
> > Following discussion on irc, here is a v2:
>
> I forgot to update the commit message.
>
> Ian.
>
> From 4cbc583020642d6c333d07e297c52594bb88b542 Mon Sep 17 00:00:00 2001
> From: Ian Jackson
> Date: Mon, 4 Apr 2016 11:41:19 +0100
> Subject: [PATCH] libxl: ARM build: fix type of
> libxl__srm_callout_callback_restore_results
>
> COLO introduced a few callbacks. The original implementation used
> unsigned long for a type which in fact should be xen_pfn_t. That broke
> libxl compilation on ARM, because xen_pfn_t is not a synonym for
> unsigned long on ARM platform.
>
> Fixing this requires modifying the perl script: specifically now we
> need to include xenctrl.h before _libxl_save_msgs_*.h, rather than
> afterwards, so that we can use xen_pfn_t there.
>
> Reported-by: Olaf Hering
> Signed-off-by: Wei Liu
> Signed-off-by: Ian Jackson
Acked-by: Wei Liu
> ---
> tools/libxl/libxl_create.c |4 ++--
> tools/libxl/libxl_save_msgs_gen.pl |8
> 2 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
> index 6882ff8..4b02de9 100644
> --- a/tools/libxl/libxl_create.c
> +++ b/tools/libxl/libxl_create.c
> @@ -1109,8 +1109,8 @@ static void domcreate_bootloader_done(libxl__egc *egc,
> domcreate_stream_done(egc, &dcs->srs, rc);
> }
>
> -void libxl__srm_callout_callback_restore_results(unsigned long store_mfn,
> - unsigned long console_mfn, void *user)
> +void libxl__srm_callout_callback_restore_results(xen_pfn_t store_mfn,
> + xen_pfn_t console_mfn, void *user)
> {
> libxl__save_helper_state *shs = user;
> libxl__domain_create_state *dcs = shs->caller_state;
> diff --git a/tools/libxl/libxl_save_msgs_gen.pl
> b/tools/libxl/libxl_save_msgs_gen.pl
> index c2243f2..3ae7373 100755
> --- a/tools/libxl/libxl_save_msgs_gen.pl
> +++ b/tools/libxl/libxl_save_msgs_gen.pl
> @@ -29,8 +29,8 @@ our @msgs = (
> [ 6, 'srcxA', "wait_checkpoint", [] ],
> [ 7, 'scxA', "switch_qemu_logdirty", [qw(int domid
>unsigned enable)] ],
> -[ 8, 'rcx',"restore_results", ['unsigned long', 'store_gfn',
> - 'unsigned long',
> 'console_gfn'] ],
> +[ 8, 'rcx',"restore_results", ['xen_pfn_t', 'store_gfn',
> + 'xen_pfn_t', 'console_gfn'] ],
> [ 9, 'srW',"complete", [qw(int retval
> int errnoval)] ],
> );
> @@ -70,9 +70,9 @@ END_BOTH
>
> END_CALLOUT
>
> -#include "_libxl_save_msgs_${ah}.h"
> #include
> #include
> +#include "_libxl_save_msgs_${ah}.h"
>
> END_HELPER
> }
> @@ -141,7 +141,7 @@ static void bytes_put(unsigned char *const buf, int *len,
>
> END
>
> -foreach my $simpletype (qw(int uint16_t uint32_t unsigned), 'unsigned long')
> {
> +foreach my $simpletype (qw(int uint16_t uint32_t unsigned), 'unsigned long',
> 'xen_pfn_t') {
> my $typeid = typeid($simpletype);
> $out_body{'callout'} .= < static int ${typeid}_get(const unsigned char **msg,
> --
> 1.7.10.4
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] libxl: fix compilation on ARM
Wei Liu writes ("Re: [PATCH] libxl: fix compilation on ARM"):
> Acked-by: Wei Liu
Thanks, pushed. Hopefully this will unblock the smoke test.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] Getting rid of inside_vm in intel8x0
On Mon, 04 Apr 2016 11:05:43 +0200, George Dunlap wrote: > > On 02/04/16 13:57, Andy Lutomirski wrote: > > On Fri, Apr 1, 2016 at 10:33 PM, Takashi Iwai wrote: > >> On Sat, 02 Apr 2016 00:28:31 +0200, > >> Luis R. Rodriguez wrote: > >>> If the former, could a we somehow detect an emulated device other than > >>> through > >>> this type of check ? Or could we *add* a capability of some sort to > >>> detect it > >>> on the driver ? This would not address the removal, but it could mean > >>> finding a > >>> way to address emulation issues. > >>> > >>> If its an IO issue -- exactly what is the causing the delays in IO ? > >> > >> Luis, there is no problem about emulation itself. It's rather an > >> optimization to lighten the host side load, as I/O access on a VM is > >> much heavier. > >> > >> This is satisfied mostly only on VM, and can't > >> be measured easily unlike the IO read speed. > > > > Interesting, note the original patch claimed it was for KVM and > > Parallels hypervisor only, but since the code uses: > > > > +#if defined(__i386__) || defined(__x86_64__) > > + inside_vm = inside_vm || > > boot_cpu_has(X86_FEATURE_HYPERVISOR); > > +#endif > > > > This makes it apply also to Xen as well, this makes this hack more > > broad, but does is it only applicable when an emulated device is > > used ? What about if a hypervisor is used and PCI passthrough is > > used ? > > A good question. Xen was added there at the time from positive > results by quick tests, but it might show an issue if it's running on > a very old chip with PCI passthrough. But I'm not sure whether PCI > passthrough would work on such old chipsets at all. > >>> > >>> If it did have an issue then that would have to be special cased, that > >>> is the module parameter would not need to be enabled for such type of > >>> systems, and heuristics would be needed. As you note, fortunately this > >>> may not be common though... > >> > >> Actually this *is* module parametered. If set to a boolean value, it > >> can be applied / skipped forcibly. So, if there has been a problem on > >> Xen, this should have been reported. That's why I wrote it's no > >> common case. This comes from the real experience. > >> > >>> but if this type of work around may be > >>> taken as a precedent to enable other types of hacks in other drivers > >>> I'm very fearful of more hacks later needing these considerations as > >>> well. > >>> > >>> There are a pile of nonsensical "are we in a VM" checks of various > >>> sorts scattered throughout the kernel, they're all a mess to maintain > >>> (there are lots of kinds of VMs in the world, and Linux may not even > >>> know it's a guest), and, in most cases, it appears that the correct > >>> solution is to delete the checks. I just removed a nasty one in the > >>> x86_32 entry asm, and this one is written in C so it should be a piece > >>> of cake :) > >> > >> This cake looks sweet, but a worm is hidden behind the cream. > >> The loop in the code itself is already a kludge for the buggy hardware > >> where the inconsistent read happens not so often (only at the boundary > >> and in a racy way). It would be nice if we can have a more reliably > >> way to know the hardware buggyness, but it's difficult, > >> unsurprisingly. > > > > The concern here is setting precedents for VM cases sprinkled in the > > kernel. > > The assumption here is such special cases are really paper'ing over > > another > > type of issue, so its best to ultimately try to root cause the issue in > > a more generalized fashion. > > Well, it's rather bare metal that shows the buggy behavior, thus we > need to paper over it. In that sense, it's other way round; we don't > tune for VM. The VM check we're discussing is rather for skipping the > strange workaround. > >>> > >>> What is it exactly about a VM that enables this work around to be skipped? > >>> I don't quite get it yet. > >> > >> VM -- at least the full one with the sound hardware emulation -- > >> doesn't have the hardware bug. So, the check isn't needed. > > > > Here's the issue, though: asking "am I in a VM" is not a good way to > > learn properties of hardware. Just off the top of my head, here are > > some types of VM and what they might imply about hardware: > > > > Intel Kernel Guard: your sound card is passed through from real hardware. > > > > Xen: could go either way. In dom0, it's likely passed through. In > > domU, it could be passed through or emulated, and I believe this is > > the case for all of the Xen variants. > > > > KVM: Probably emulated, but could be passed through. > > I'm not sure exactly why I was CC'd into this thread, but this is an > important point -- even if you're running in a VM, you may actually have > direct un-emulated IO access t
Re: [Xen-devel] P2M aliasing check
>>> On 01.04.16 at 19:18, wrote: > While trying to get hotplug scripts to work on FreeBSD, I've realized that > there's a check in the P2M code that prevents having multiple gfn pointing > to the same mfn. The check in question is performed at > guest_physmap_add_entry, and it means that the existing gfn -> mfn is > removed and the new one is added, leaving the previous gfn without a valid > mfn. > > This is a problem specially for PVH Dom0, since it means local-attach of > virtual disk devices lead to a crash of the Dom0. This happens because > Dom0 is sharing a grant with itself, and then the original gfn -> mfn > assignment gets destroyed in favor of the new one created by mapping the > grant reference. > > I would like to understand the reason why this check is in place, and why > aliased gfn -> mfn mappings are not permitted. This is a different behavior > as compared to PV guests, where multiple VA -> mfn mappings are permitted. That's the wrong thing to compare with: You mean pfn -> mfn mappings. And then the pointer direction is misleading too: In your first paragraph, you really mean to say that unique M -> P mappings are being enforced, and that's the same for PV. And not enforcing this would invalidate the (shared!) M2P, which in addition is part of the PV ABI. Iirc there are a few places where M -> P translations are being looked up inside the hypervisor even for non-PV guests, so breaking the unique mapping would render such translation requests ambiguous. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH] unmodified_drivers: enable use of register_oldmem_pfn_is_ram() API
From: Mike Meyer During the investigation of very slow dump times of guest images in Amazon EC2 instance, it was discovered that the register_oldmem_pfn_is_ram() API implemented by the upstream kernel commit 997c136f518c5debd63847e78e2a8694f56dcf90: fs/proc/vmcore.c: add hook to read_from_oldmem() to check for non-ram pages was not being called. This was due to the PV driver with the call to register_oldmem_pfn_is_ram() API was not including the kernel header file that is used to communicate support of the API in the kernel. Fix the issue by including the required header file. Signed-off-by: Mike Meyer Reviewed-by: Jan Beulich --- a/unmodified_drivers/linux-2.6/platform-pci/platform-pci.c +++ b/unmodified_drivers/linux-2.6/platform-pci/platform-pci.c @@ -23,6 +23,7 @@ #include #include #include +#include #include #include #include unmodified_drivers: enable use of register_oldmem_pfn_is_ram() API During the investigation of very slow dump times of guest images in Amazon EC2 instance, it was discovered that the register_oldmem_pfn_is_ram() API implemented by the upstream kernel commit 997c136f518c5debd63847e78e2a8694f56dcf90: fs/proc/vmcore.c: add hook to read_from_oldmem() to check for non-ram pages was not being called. This was due to the PV driver with the call to register_oldmem_pfn_is_ram() API was not including the kernel header file that is used to communicate support of the API in the kernel. Fix the issue by including the required header file. Signed-off-by: Mike Meyer Reviewed-by: Jan Beulich --- a/unmodified_drivers/linux-2.6/platform-pci/platform-pci.c +++ b/unmodified_drivers/linux-2.6/platform-pci/platform-pci.c @@ -23,6 +23,7 @@ #include #include #include +#include #include #include #include ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 11/28] xsplice: Implement support for applying/reverting/replacing patches.
>>> On 01.04.16 at 23:04, wrote:
> On Fri, Apr 01, 2016 at 07:28:00AM -0600, Jan Beulich wrote:
>> >>> On 24.03.16 at 21:00, wrote:
>> > From: Ross Lagerwall
>> >
>> > Implement support for the apply, revert and replace actions.
>> >
>> > To perform and action on a payload, the hypercall sets up a data
>> > structure to schedule the work. A hook is added in all the
>> > return-to-guest paths to check for work to do and execute it if needed.
>>
>> Looking at the diffstat alone I cannot see this being the case.
>> Perhaps it's just the description here which needs to become
>> more precise.
>
> s/all the/common/ ?
Considering that non of the entry.S files get touched, I think it's
the "return-to-guest paths" part which is wrong.
>> > In this way, patches can be applied with all CPUs idle and without
>> > stacks. The first CPU to do_xsplice() becomes the master and triggers a
>> > reschedule softirq to trigger all the other CPUs to enter do_xsplice()
>> > with no stack. Once all CPUs have rendezvoused, all CPUs disable IRQs
>> > and NMIs are ignored. The system is then quiscient and the master
>> > performs the action. After this, all CPUs enable IRQs and NMIs are
>> > re-enabled.
>> >
>> > Note that it is unsafe to patch do_nmi and the xSplice internal functions.
>> > Patching functions on NMI/MCE path is liable to end in disaster.
>>
>> So what measures are (planned to be) taken to make sure this
>> doesn't happen by accident?
>
> None in this patch.
>
> Please keep in mind that this issue is not only a problem with
> xSplice but also with alternative assembler patching.
Except that an issue there would cause only a boot failure, which
would be unlikely to re-occur on the next boot attempt. Whereas
things going wrong at runtime would likely mean worse
consequences.
> I haven't figured out a nice way to take care of this and was hoping
> to brainstorm that. For right now this part is left out as 'TODO'.
That's what I've assumed, which is fine for the moment. Just maybe
make this more explicit by adding (to the above) something like "For
now this needs to be ensured by the people creating patches."
>> > The action to perform is one of:
>> > - APPLY: For each function in the module, store the first 5 bytes of the
>> > old function and replace it with a jump to the new function.
>> > - REVERT: Copy the previously stored bytes into the first 5 bytes of the
>> > old function.
>> > - REPLACE: Revert each applied module and then apply the new module.
>> >
>> > To prevent a deadlock with any other barrier in the system, the master
>> > will wait for up to 30ms before timing out.
>> > Measurements found that the patch application to take about 100 μs on a
>> > 72 CPU system, whether idle or fully loaded.
>>
>> That's for an individual patch I suppose? What if REPLACE has to
>> revert dozens or hundreds of patches?
>
> The user-space can change the timeout to a larger value.
The question wasn't about the timeout expiring, but about the latency
of the operation (and the resulting effect on the system).
>> > --- a/docs/misc/xsplice.markdown
>> > +++ b/docs/misc/xsplice.markdown
>> > @@ -841,7 +841,8 @@ The implementation must also have a mechanism for:
>> > * Be able to lookup in the Xen hypervisor the symbol names of functions
>> > from the ELF payload.
>> > * Be able to patch .rodata, .bss, and .data sections.
>> > * Further safety checks (blacklist of which functions cannot be patched,
>> > check
>> > - the stack, make sure the payload is built with same compiler as
>> > hypervisor).
>> > + the stack, make sure the payload is built with same compiler as
>> > hypervisor,
>> > + and NMI/MCE handlers and do_nmi for right now - until an safe solution
>> > is found).
>>
>> The whole thing doesn't parse anymore for me with the addition,
>> so I can't really conclude what you mean to say here (and hence
>> whether that addresses the earlier question).
>
> It is adding handling of NMI/MCE on the 'TODO' list so that I don't forget
> about it.
Please try to re-word the addition then to make the result readable
again.
>> > +/* There can be only one outstanding patching action. */
>> > +static struct xsplice_work xsplice_work;
>> > +
>> > +/* Indicate whether the CPU needs to consult xsplice_work structure. */
>> > +static DEFINE_PER_CPU(bool_t, work_to_do);
>>
>> Peeking ahead to the uses of this, I can't see why this is needed
>> alongside xsplice_work.do_work.
>
> Andrew asked for this - he noticed that we pound on the xsplice_work
> structure quite often across a lot of CPUs. Instead of pounding on the same
> cache line - we could just read from a per-cpu cache line. Hence this
> addition.
Then please make the comment say so in a more explicit way.
>> > +sec = xsplice_elf_sec_by_name(elf, names[i]);
>> > +if ( !sec )
>> > +{
>> > +printk(XENLOG_ERR "%s%s: %s is missing!\n",
>> > + XSPLICE, elf->name, names[i]);
>> >
[Xen-devel] [ovmf test] 88546: regressions - FAIL
flight 88546 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/88546/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 65543 test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 65543 version targeted for testing: ovmf 00f18da1ca79beccdf71e30689e19e8b2e3a02fd baseline version: ovmf 5ac96e3a28dd26eabee421919f67fa7c443a47f1 Last test of basis65543 2015-12-08 08:45:15 Z 117 days Failing since 65593 2015-12-08 23:44:51 Z 117 days 135 attempts Testing same since88334 2016-04-01 23:14:47 Z2 days3 attempts People who touched revisions under test: "Samer El-Haj-Mahmoud" "Wu, Hao A" "Yao, Jiewen" Alcantara, Paulo Anbazhagan Baraneedharan Andrew Fish Ard Biesheuvel Arthur Crippa Burigo Cecil Sheng Chao Zhang Chao Zhang Charles Duffy Cinnamon Shia Cohen, Eugene Dandan Bi Daocheng Bu Daryl McDaniel David Woodhouse Derek Lin edk2 dev edk2-devel Eric Dong Eric Dong Eugene Cohen Evan Lloyd Feng Tian Fu Siyuan Gabriel Somlo Gary Ching-Pang Lin Gary Lin Ghazi Belaam Hao Wu Haojian Zhuang Hess Chen Heyi Guo Jaben Carsey James Bottomley Jeff Fan Jiaxin Wu jiewen yao Jim Dailey jim_dai...@dell.com Jordan Justen Juliano Ciocari Karyne Mayer Larry Hauch Laszlo Ersek Leahy, Leroy P Leahy, Leroy P Lee Leahy Leekha Shaveta Leendert van Doorn Leif Lindholm Leo Duran Liming Gao Mark Rutland Marvin Haeuser Marvin Häuser Michael Kinney Michael LeMay Michael Thomas MichaŠZegan Ni, Ruiyu Paolo Bonzini Paulo Alcantara Paulo Alcantara Cavalcanti Peter Kirmeier Qin Long Qiu Shumin Rodrigo Dias Correa Ruiyu Ni Ryan Harkin Samer El-Haj-Mahmoud Samer El-Haj-Mahmoud Sami Mujawar Shivamurthy Shastri Star Zeng Supreeth Venkatesh Tapan Shah Thomas Palmer Tian, Feng Vladislav Vovchenko Yao Jiewen Yao, Jiewen Ye Ting Yonghong Zhu Zeng, Star Zhang Lubo Zhang, Chao B Zhang, Lubo Zhangfei Gao 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-qemuu-ovmf-amd64 fail test-amd64-i386-xl-qemuu-ovmf-amd64 fail sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 16082 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH] x86/HVM: remove dead code
With commit 96ae556569 ("x86/HVM: fix forwarding of internally cached
requests") rc doesn't change anymore in the respective preceding
switch() statements.
Coverity ID: 1358080
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/hvm/intercept.c
+++ b/xen/arch/x86/hvm/intercept.c
@@ -151,8 +151,6 @@ int hvm_process_io_intercept(const struc
domain_crash(current->domain);
return X86EMUL_UNHANDLEABLE;
}
-if ( rc != X86EMUL_OKAY )
-break;
}
else
p->data = data;
@@ -181,8 +181,6 @@ int hvm_process_io_intercept(const struc
domain_crash(current->domain);
return X86EMUL_UNHANDLEABLE;
}
-if ( rc != X86EMUL_OKAY )
-break;
}
else
data = p->data;
x86/HVM: remove dead code
With commit 96ae556569 ("x86/HVM: fix forwarding of internally cached
requests") rc doesn't change anymore in the respective preceding
switch() statements.
Coverity ID: 1358080
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/hvm/intercept.c
+++ b/xen/arch/x86/hvm/intercept.c
@@ -151,8 +151,6 @@ int hvm_process_io_intercept(const struc
domain_crash(current->domain);
return X86EMUL_UNHANDLEABLE;
}
-if ( rc != X86EMUL_OKAY )
-break;
}
else
p->data = data;
@@ -181,8 +181,6 @@ int hvm_process_io_intercept(const struc
domain_crash(current->domain);
return X86EMUL_UNHANDLEABLE;
}
-if ( rc != X86EMUL_OKAY )
-break;
}
else
data = p->data;
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable-smoke test] 88629: regressions - FAIL
flight 88629 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/88629/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-libvirt 5 libvirt-build fail REGR. vs. 88144 build-armhf 5 xen-build fail REGR. vs. 88144 Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a version targeted for testing: xen d887c19f00c58e67086f3a9885883f470ea35ba2 baseline version: xen 96ae556569b8eaedc0bb242932842c3277b515d8 Last test of basis88144 2016-03-31 13:06:39 Z3 days Failing since 88279 2016-04-01 14:03:55 Z2 days 30 attempts Testing same since88315 2016-04-01 20:03:45 Z2 days 27 attempts People who touched revisions under test: Andrew Cooper Changlong Xie Chong Li Dario Faggioli George Dunlap Ian Campbell Ian Jackson Jan Beulich Juergen Gross Kevin Tian Konrad Rzeszutek Wilk Meng Xu Olaf Hering Paul Durrant Roger Pau Monne Roger Pau Monné Sisu Xi Wei Liu Wen Congyang Yang Hongyang jobs: build-amd64 pass build-armhf fail build-amd64-libvirt fail test-armhf-armhf-xl blocked test-amd64-amd64-xl-qemuu-debianhvm-i386 pass test-amd64-amd64-libvirt blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 799 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] unmodified_drivers: enable use of register_oldmem_pfn_is_ram() API
On Mon, Apr 04, Jan Beulich wrote: > From: Mike Meyer > > During the investigation of very slow dump times of guest images in > Amazon EC2 instance, it was discovered that the > register_oldmem_pfn_is_ram() API implemented by the upstream kernel > commit 997c136f518c5debd63847e78e2a8694f56dcf90: > > fs/proc/vmcore.c: add hook to read_from_oldmem() to check >for non-ram pages > > was not being called. This was due to the PV driver with the call > to register_oldmem_pfn_is_ram() API was not including the > kernel header file that is used to communicate support of the API in the > kernel. Fix the issue by including the required header file. > > Signed-off-by: Mike Meyer > Reviewed-by: Jan Beulich Acked-by: Olaf Hering I'm sure I have tested it at that time, not sure why it used to work a few years ago. Olaf ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] Fixed --enable-systemd on latest Debian stretch. Added xencommons as a systemd.service.
Add back xen-devel On Mon, Apr 04, 2016 at 01:28:03PM +0200, Sjoer van der Ploeg wrote: > Ocaml search path was set to /usr/local > > I haven't had the time to check why xendomains fails, I've got a few > deadlines for school to finish before Friday. > No worries. Your deadlines are more important than this bug. :-) If you can provide me the exact commands you used to fetch the repository and build, I will have a look at this at some point. Wei. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 05/10] xl_cmdimpl: improve return codes for memset commands
On 01/04/16 15:33, Roger Pau Monné wrote:
> On Fri, 1 Apr 2016, Paulina Szubarczyk wrote:
>
>> - Use EXIT_{SUCCESS,FAILURE} for main_mem*() function
>> - Use 0/1 as return values of set_memory_{max,target}
>>
>> Signed-off-by: Paulina Szubarczyk
>> ---
>> tools/libxl/xl_cmdimpl.c | 24
>> 1 file changed, 16 insertions(+), 8 deletions(-)
>>
>> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
>> index 7ee6953..31f037f 100644
>> --- a/tools/libxl/xl_cmdimpl.c
>> +++ b/tools/libxl/xl_cmdimpl.c
>> @@ -3380,15 +3380,15 @@ static int set_memory_max(uint32_t domid, const char
>> *mem)
>> memorykb = parse_mem_size_kb(mem);
>> if (memorykb == -1) {
>> fprintf(stderr, "invalid memory size: %s\n", mem);
>> -exit(3);
>> +exit(EXIT_FAILURE);
>
> IMHO (I would like to hear others' opinion) but I think you can just
> return 1 here instead of exiting.
I'm generally not in favor of non-top-level functions calling exit()
unless returning an error is really impossible (as libxl does with
memory allocation failures).
IOW, I tend to agree with Roger.
-George
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 09/10] libxl: Fix libxl_set_memory_target return value
On 01/04/16 15:55, Roger Pau Monné wrote: > On Fri, 1 Apr 2016, Paulina Szubarczyk wrote: >> libxl_set_memory_target seems to have the following return values: >> >> * 1 on failure, if the failure happens because of a xenstore error *or* >> * invalid >> target > > AFAICT it seems like you haven't touched this patch at all, but the commit > message looks messed up (at least there's an extra "\n" here). > > Also, I'm not a git expert, but I think if the patch is from George, and > you haven't touched it, it should contain an extra "From:" field in > the message body with George's address. I'm not sure the "From" thing is really worth a re-send, but since she's re-sending it anyway, you might as well. :-) -George ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 3/9] x86/head: Move early exception panic code into early_fixup_exception
On Sat 02-04-16 13:58:19, Andy Lutomirski wrote:
> [cc Jan Kara]
>
> On Sat, Apr 2, 2016 at 1:47 PM, Borislav Petkov wrote:
> > On Sat, Apr 02, 2016 at 01:13:37PM -0700, Andy Lutomirski wrote:
> >> Given that I this isn't really a regression with my patches (it
> >> probably never worked much better on 32-bit and the regs never would
> >> have shown at all on 64-bit),
> >
> > You're right. That thing calls printk *and* early_printk, WTF:
> >
> > #ifdef CONFIG_EARLY_PRINTK
> >
> > call early_printk
> > ...
> >
> > call dump_stack
> >
> > ...
> >
> > call __print_symbol
> >
> > those last two call printk. Great.
> >
> >> I propose a different approach: make
> >> printk work earlier. Something like:
> >>
> >> if (early) {
> >> early_printk(args);
> >> }
> >>
> >> or early_vprintk or whatever.
> >>
> >> If the cost of a branch mattered, this could be alternative-patched
> >> out later on, but that seems silly. I also bet that a more sensible
> >> fallback could be created in which printk would try to use an early
> >> console if there's no real console.
> >
> > So how about this:
> >
> > printk() does
> >
> > vprintk_func = this_cpu_read(printk_func);
> >
> > and that's
> >
> > DEFINE_PER_CPU(printk_func_t, printk_func) = vprintk_default
> >
> > I guess we can make that function be early_printk-something and once
> > printk is initialized, we overwrite it with vprintk_default.
> >
> > Elegant and no need for if branches and alternatives.
> >
> > Hmmm.
>
> Jan, IIRC you were looking at printk recently-ish. Any thoughts here?
Sounds like a good idea to me. I've also consulted this with Petr Mladek
(added to CC) who is using printk_func per-cpu variable in his
printk-from-NMI patches and he also doesn't see a problem with this.
I was just wondering about one thing - this way we add more early printks
if I understand your intention right. Are we guaranteed that they happen
only from a single CPU? Because currently there is no locking in
early_printk() and thus we can end up writing to early console several
messages in parallel from different CPUs. Not sure what's going to happen
in that case...
Honza
--
Jan Kara
SUSE Labs, CR
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v13 03/26] tools/libxl: Add back channel to allow migration target send data back
On Fri, Mar 25, Changlong Xie wrote: > +#elif defined(LIBXL_API_VERSION) && LIBXL_API_VERSION >= 0x040400 \ > + && LIBXL_API_VERSION < 0x040700 Is this supposed to work? libvirt.git fails to build now: libxl/libxl_domain.c: In function 'libxlDomainStart': libxl/libxl_domain.c:1077: warning: passing argument 5 of 'libxl_domain_create_restore' makes integer from pointer without a cast libxl/libxl_domain.c:1077: warning: passing argument 7 of 'libxl_domain_create_restore' from incompatible pointer type libxl/libxl_domain.c:1077: error: too few arguments to function 'libxl_domain_create_restore' make[3]: *** [libxl/libvirt_driver_libxl_impl_la-libxl_domain.lo] Error 1 Olaf ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] xen-utils not running within xen or no compatible utils
Hello, On 01/04/2016 17:47, Wei Liu wrote: Add back xen-devel On Fri, Apr 01, 2016 at 05:45:31PM +0200, aicha hamza wrote: yes i compiled xen from the source .. this is exactly what i did http://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions/OMAP5432_uEVM and i get xen running in my board .. but i can't build guest because there So this is done. Good. I misread. is no xen-utils-common and as i told you before there is internet connection in my board .. so how can i get sen.utils package !! As far as I can tell xen-tools uses Debian debootstrap to build a guest which means you have to have Internet connection. Maybe you can prebuild the image from somewhere. Julien, do you have pointers on how to get an ARM guest image? Linaro provides pre-built image [1]. Note that I haven't tried it recently. As mentioned by Wei, Debootstrap is a good alternative. You will get a small rootfs ready in a couple of minutes. Regards, [1] https://releases.linaro.org/15.06/ubuntu/vexpress/ -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH] xen: Add comment for missing FROZEN notifier transitions
Xen guests do not offline/online CPUs during suspend/resume and
therefore FROZEN notifier transitions are not required. Add this
explanation as a comment in the code to get not confused why
CPU_TASKS_FROZEN masked transitions are not considered.
Cc: David Vrabel
Cc: Stefano Stabellini
Cc: xen-de...@lists.xenproject.org
Signed-off-by: Anna-Maria Gleixner
---
arch/arm/xen/enlighten.c |6 ++
arch/x86/xen/enlighten.c |7 +++
drivers/xen/events/events_fifo.c |6 ++
3 files changed, 19 insertions(+)
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -213,6 +213,12 @@ static int xen_cpu_notification(struct n
unsigned long action,
void *hcpu)
{
+ /*
+* Xen guests do not offline/online CPUs during
+* suspend/resume, thus CPU_TASKS_FROZEN masked transitions
+* are not considered.
+*/
+
switch (action) {
case CPU_STARTING:
xen_percpu_init();
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -1788,6 +1788,13 @@ static int xen_hvm_cpu_notify(struct not
void *hcpu)
{
int cpu = (long)hcpu;
+
+ /*
+* Xen guests do not offline/online CPUs during
+* suspend/resume, thus CPU_TASKS_FROZEN masked transitions
+* are not considered.
+*/
+
switch (action) {
case CPU_UP_PREPARE:
xen_vcpu_setup(cpu);
--- a/drivers/xen/events/events_fifo.c
+++ b/drivers/xen/events/events_fifo.c
@@ -425,6 +425,12 @@ static int evtchn_fifo_cpu_notification(
int cpu = (long)hcpu;
int ret = 0;
+ /*
+* Xen guests do not offline/online CPUs during
+* suspend/resume, thus CPU_TASKS_FROZEN masked transitions
+* are not considered.
+ */
+
switch (action) {
case CPU_UP_PREPARE:
if (!per_cpu(cpu_control_block, cpu))
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 19/28] build_id: Provide ld-embedded build-ids
>>> On 24.03.16 at 21:00, wrote:
> The version of ld that first implemented --build-id is v2.18.
> Hence we check for that or later version - if older version
> found we do not build the hypervisor with the build-id
> (and the return code is -ENODATA for xen_build_id() call).
This appears to be stale.
> The EFI binary is more complicated. Having any non-recognizable
> sections (.note, .data.note, etc) causes the boot to hang.
> Moving the .note in the .data section makes it work. It is also
> worth noting that the PE/COFF does not have any "comment"
> sections to the author.
I'm afraid this is too vague: What exactly is happening there? And
is this due to binutils doing something wrong, or an issue with the
firmware on the box you've tried? While the placement of .note is
not really a big deal, any unusual placement needs a source
comment attached explaining the whys, to prevent people down
the road moving the section back into the "expected" place. But
see also below.
> Lastly, we MUST call --binary-id=sha1 on all linker invocation so that
> symbol offsets don't changes (which means we have multiple binary
> ids - except that the last one is the final one). Without this change,
> the symbol table embedded in Xen are incorrect - some of the values it
> contains are offset by the size of the included build id.
> This obviously causes problems when resolving symbols.
Would this also be a problem if you place the notes segment/section
last in the binary?
> --- a/Config.mk
> +++ b/Config.mk
> @@ -126,6 +126,17 @@ endef
> check-$(gcc) = $(call cc-ver-check,CC,0x040100,"Xen requires at least
> gcc-4.1")
> $(eval $(check-y))
>
> +ld-ver-build-id = $(shell $(1) --build-id 2>&1 | \
> + grep -q unrecognized && echo n || echo
> y)
> +
> +# binutils 2.18 implement build-id.
I don't think this comment is really relevant anymore.
> --- a/xen/arch/arm/xen.lds.S
> +++ b/xen/arch/arm/xen.lds.S
> @@ -22,6 +22,9 @@ OUTPUT_ARCH(FORMAT)
> PHDRS
> {
>text PT_LOAD /* XXX should be AT ( XEN_PHYS_START ) */ ;
> +#if defined(BUILD_ID)
> + note PT_NOTE ;
> +#endif
Is this in line with ...
> @@ -57,9 +60,18 @@ SECTIONS
> *(.lockprofile.data)
> __lock_profile_end = .;
> #endif
> + } :text
>
> -_erodata = .; /* End of read-only data */
> +#if defined(BUILD_ID)
> + .note : {
> + __note_gnu_build_id_start = .;
> + *(.note.gnu.build-id)
> + __note_gnu_build_id_end = .;
> + *(.note)
> + *(.note.*)
>} :text
> +#endif
... there not being any :note here? And if so, why the earlier
"} :text"?
> --- a/xen/arch/x86/Makefile
> +++ b/xen/arch/x86/Makefile
> @@ -72,9 +72,16 @@ efi-y := $(shell if [ ! -r
> $(BASEDIR)/include/xen/compile.h
> -o \
>-O $(BASEDIR)/include/xen/compile.h ]; then \
> echo '$(TARGET).efi'; fi)
>
> +ifdef build_id_linker
According to Config.mk this is always true. DYM
"ifneq ($(build_id_linker),)"?
> +build_id.o: $(TARGET)-syms
> + $(OBJCOPY) -O binary --only-section=.note $(BASEDIR)/xen-syms $@.bin
Considering your xen.lds.S changes, won't this potentially copy quite
a bit more than just the build ID (i.e. all notes)? This may be okay, and
may be even intended, but then the generate file's name should
reflect this to not misguide people.
> + $(OBJCOPY) -I binary -O elf64-x86-64 -B i386:x86-64 \
> + --rename-section=.data=.note.gnu.build-id -S $@.bin $@
Since you put the notes into .rodata anyway, why name the
section .note.*? Just name it .rodata.*, avoiding to mislead
others who also think that a section's name has much of a
meaning.
> @@ -138,6 +151,13 @@ $(TARGET).efi: VIRT_BASE = 0x$(shell $(NM)
> efi/relocs-dummy.o | sed -n 's, A VIR
> $(TARGET).efi: ALT_BASE = 0x$(shell $(NM) efi/relocs-dummy.o | sed -n 's, A
> ALT_START$$,,p')
> # Don't use $(wildcard ...) here - at least make 3.80 expands this too early!
> $(TARGET).efi: guard = $(if $(shell echo efi/dis* | grep disabled),:)
> +ifdef build_id_linker
See above.
> @@ -228,21 +257,22 @@ static void do_read(int fd, void *data, int len)
> int main(int argc, char **argv)
> {
> u64final_exec_addr;
> -u32loadbase, dat_siz, mem_siz;
> +u32loadbase, dat_siz, mem_siz, note_base, note_sz, offset;
> char *inimage, *outimage;
> intinfd, outfd;
> char buffer[1024];
> intbytes, todo, i;
> +intnum_phdrs;
>
> Elf32_Ehdr in32_ehdr;
>
> Elf64_Ehdr in64_ehdr;
> Elf64_Phdr in64_phdr;
>
> -if ( argc != 5 )
> +if ( argc != 6 )
> {
> fprintf(stderr, "Usage: mkelf32 "
> -" \n");
> +" headers>\n");
Even if only an internally used tool, I think this is a bad interface:
You want notes copied, and this only happens to result in a second
PHDR. Hence I think there should be an option "--notes" or some
such
Re: [Xen-devel] [PATCH v5 3/9] x86/head: Move early exception panic code into early_fixup_exception
On Mon, Apr 04, 2016 at 01:52:06PM +0200, Jan Kara wrote:
> Sounds like a good idea to me. I've also consulted this with Petr Mladek
> (added to CC) who is using printk_func per-cpu variable in his
> printk-from-NMI patches and he also doesn't see a problem with this.
There's a few printk() variants that do not go through this; which means
they're broken for a number of cases, including the kdb printk
redirection, this NMI stuff etc.
> I was just wondering about one thing - this way we add more early printks
> if I understand your intention right. Are we guaranteed that they happen
> only from a single CPU? Because currently there is no locking in
> early_printk() and thus we can end up writing to early console several
> messages in parallel from different CPUs. Not sure what's going to happen
> in that case...
You get lovely per char interleaving on you serial line ;-)
What I've done in the past was something like the below; that way you
only get the normal task->softirq->irq->nmi nesting, which is mostly
decipherable.
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index bfbf284e4218..c4c3269ff104 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -1907,17 +1907,36 @@ struct console *early_console;
asmlinkage __visible void early_printk(const char *fmt, ...)
{
va_list ap;
+ static int print_cpu = -1;
char buf[512];
- int n;
+ int n, cpu;
if (!early_console)
return;
+ preempt_disable();
+ cpu = raw_smp_processor_id();
+ for (;;) {
+ if (READ_ONCE(print_cpu) == cpu)
+ break;
+
+ if (READ_ONCE(print_cpu) == -1 &&
+ cmpxchg(&print_cpu, -1, cpu) == -1) {
+ cpu = -1;
+ break;
+ }
+
+ cpu_relax();
+ }
+
va_start(ap, fmt);
n = vscnprintf(buf, sizeof(buf), fmt, ap);
va_end(ap);
early_console->write(early_console, buf, n);
+
+ smp_store_release(&print_cpu, cpu);
+ preempt_enable();
}
#endif
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v13 03/26] tools/libxl: Add back channel to allow migration target send data back
CC Jim On Mon, Apr 04, 2016 at 02:07:28PM +0200, Olaf Hering wrote: > On Fri, Mar 25, Changlong Xie wrote: > > > +#elif defined(LIBXL_API_VERSION) && LIBXL_API_VERSION >= 0x040400 \ > > + && LIBXL_API_VERSION < 0x040700 > > Is this supposed to work? libvirt.git fails to build now: > > libxl/libxl_domain.c: In function 'libxlDomainStart': > libxl/libxl_domain.c:1077: warning: passing argument 5 of > 'libxl_domain_create_restore' makes integer from pointer without a cast > libxl/libxl_domain.c:1077: warning: passing argument 7 of > 'libxl_domain_create_restore' from incompatible pointer type > libxl/libxl_domain.c:1077: error: too few arguments to function > 'libxl_domain_create_restore' > make[3]: *** [libxl/libvirt_driver_libxl_impl_la-libxl_domain.lo] Error 1 > From the look of it that's because libvirt doesn't have LIBXL_API_VERSION defined before including libxl.h, so it always gets the latest API. The fix is to patch libvirt. Looking at libvirt code I think I need to patch Makefile.in to pass in an explicit LIBXL_API_VERSION number. Jim, does that sound right? Wei. > Olaf ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [qemu-mainline test] 88557: regressions - FAIL
flight 88557 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/88557/ 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. 86454 test-amd64-i386-freebsd10-amd64 10 guest-startfail REGR. vs. 86454 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail REGR. vs. 86454 test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 86454 test-amd64-amd64-xl-qemuu-debianhvm-amd64 9 debian-hvm-install fail REGR. vs. 86454 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail REGR. vs. 86454 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail REGR. vs. 86454 test-amd64-i386-libvirt-pair 21 guest-migrate/src_host/dst_host fail REGR. vs. 86454 test-amd64-i386-xl-qemuu-debianhvm-amd64 9 debian-hvm-install fail REGR. vs. 86454 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail REGR. vs. 86454 test-amd64-i386-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 86454 test-amd64-i386-qemuu-rhel6hvm-amd 9 redhat-install fail REGR. vs. 86454 test-amd64-i386-qemuu-rhel6hvm-intel 9 redhat-installfail REGR. vs. 86454 test-amd64-amd64-qemuu-nested-intel 9 debian-hvm-install fail REGR. vs. 86454 test-amd64-amd64-qemuu-nested-amd 9 debian-hvm-install fail REGR. vs. 86454 test-amd64-amd64-libvirt-pair 21 guest-migrate/src_host/dst_host fail REGR. vs. 86454 Tests which are failing intermittently (not blocking): test-armhf-armhf-xl 6 xen-bootfail pass in 88424 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds 15 guest-start/debian.repeat fail in 88424 blocked in 86454 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 86454 test-armhf-armhf-xl-rtds 11 guest-start fail like 86454 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 86454 Tests which did not succeed, but are not blocking: test-armhf-armhf-xl 12 migrate-support-check fail in 88424 never pass test-armhf-armhf-xl 13 saverestore-support-check fail in 88424 never pass test-armhf-armhf-xl-rtds 13 saverestore-support-check fail in 88424 never pass test-armhf-armhf-xl-rtds 12 migrate-support-check fail in 88424 never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-armhf-armhf-libvirt 14 guest-saverestorefail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 13 guest-saverestorefail never pass test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 saverestore-support-checkfail never pass version targeted for testing: qemuude1d099a448beb2ec39af4bd9ce4dd6452a18cb5 baseline version: qemuud1f8764099022bc1173f2413331b26d4ff609a0c Last test of basis86454 2016-03-17 06:01:30 Z 18 days Failing since 86547 2016-03-18 07:12:41 Z 17 days 19 attempts Testing same since88296 2016-04-01 16:31:12 Z2 days3 attempts --
[Xen-devel] [xen-unstable-smoke test] 88656: regressions - FAIL
flight 88656 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/88656/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-libvirt 5 libvirt-build fail REGR. vs. 88144 Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass version targeted for testing: xen d9eadad55eb99c80a0a2841e8ca227c75de66891 baseline version: xen 96ae556569b8eaedc0bb242932842c3277b515d8 Last test of basis88144 2016-03-31 13:06:39 Z4 days Failing since 88279 2016-04-01 14:03:55 Z2 days 32 attempts Testing same since88656 2016-04-04 11:01:48 Z0 days1 attempts People who touched revisions under test: Andrew Cooper Changlong Xie Chong Li Dario Faggioli George Dunlap Ian Campbell Ian Jackson Jan Beulich Juergen Gross Kevin Tian Konrad Rzeszutek Wilk Meng Xu Olaf Hering Paul Durrant Roger Pau Monne Roger Pau Monné Sisu Xi Wei Liu Wen Congyang Yang Hongyang jobs: build-amd64 pass build-armhf pass build-amd64-libvirt fail test-armhf-armhf-xl pass test-amd64-amd64-xl-qemuu-debianhvm-i386 pass test-amd64-amd64-libvirt blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 819 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] xen-utils not running within xen or no compatible utils
(Adding back xen-devel) Please don't top post and keep xen-devel CCed. On 04/04/2016 14:15, aicha hamza wrote: i'm actually looking for building a dom u for omap5 but the problem that i don't have an internet connection .. so i can't get the xen-utils .. (no xl command) is there an other method to have a guest for my board The first step would be looking why the board doesn't get network. Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [linux-3.16 test] 88561: regressions - FAIL
flight 88561 linux-3.16 real [real] http://logs.test-lab.xenproject.org/osstest/logs/88561/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-libvirt-pair 21 guest-migrate/src_host/dst_host fail REGR. vs. 85048 Tests which are failing intermittently (not blocking): test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail pass in 88445 Regressions which are regarded as allowable (not blocking): test-amd64-i386-xl-qemuu-win7-amd64 20 leak-check/check fail blocked in 85048 build-i386-rumpuserxen6 xen-buildfail like 85048 build-amd64-rumpuserxen 6 xen-buildfail like 85048 test-amd64-amd64-xl-credit2 17 guest-localmigrate/x10 fail like 85048 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 85048 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 85048 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 85048 test-armhf-armhf-xl-rtds 11 guest-start fail like 85048 Tests which did not succeed, but are not blocking: test-amd64-i386-rumpuserxen-i386 1 build-check(1) blocked n/a test-amd64-amd64-rumpuserxen-amd64 1 build-check(1) blocked n/a 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-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail never pass test-amd64-amd64-xl-multivcpu 17 guest-localmigrate/x10 fail never pass test-armhf-armhf-libvirt 14 guest-saverestorefail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-xl-rtds 17 guest-localmigrate/x10 fail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-libvirt-raw 13 guest-saverestorefail never pass test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail 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-arndale 13 saverestore-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 saverestore-support-checkfail never pass version targeted for testing: linux3a96c6601b6fc47baa6d296f9111ba7be4dad6fc baseline version: linux7f2a8840d127c8d5c59a5d79235e1205aba2e102 Last test of basis85048 2016-03-02 10:56:10 Z 33 days Testing same since87897 2016-03-29 14:28:05 Z5 days6 attempts People who touched revisions under test: Akshay Bhat Al Viro Alex Deucher Alex Williamson Alexander Deucher Amir Vadai Andreas Schwab Andrey Skvortsov Andy Lutomirski Andy Shevchenko Anton Protopopov Arnd Bergmann Avery Pennarun Ben Hutchings Benjamin Coddington Benjamin LaHaise Benjamin Poirier Bjørn Mork Chris Bainbridge Christian Borntraeger Christian König Christoffer Dall Christoph Hellwig Cong Wang CQ Tang Dan Carpenter Daniel Borkmann Daniele Pal
[Xen-devel] Policy for force pushing smoke branch Was: Re: [xen-unstable-smoke test] 88656: regressions - FAIL
On Mon, Apr 04, 2016 at 01:15:53PM +, osstest service owner wrote: > flight 88656 xen-unstable-smoke real [real] > http://logs.test-lab.xenproject.org/osstest/logs/88656/ > > Regressions :-( > > Tests which did not succeed and are blocking, > including tests which could not be run: > build-amd64-libvirt 5 libvirt-build fail REGR. vs. > 88144 > > Tests which did not succeed, but are not blocking: > test-amd64-amd64-libvirt 1 build-check(1) blocked n/a This failed because libvirt doesn't set LIBXL_API_VERSION. It is not a bug in Xen code base. I don't think we have precedent of force-pushing smoke branch, so we need to decide what to do here. It would take some time for libvirt fix to land and propagate to our own mirror. I would like to avoid holding backing xen.git push for too long if possible. So I'm for force-pushing the smoke branch and subsequently master branch if necessary. Wei. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] Policy for force pushing smoke branch Was: Re: [xen-unstable-smoke test] 88656: regressions - FAIL
Wei Liu writes ("Policy for force pushing smoke branch Was: Re: [Xen-devel]
[xen-unstable-smoke test] 88656: regressions - FAIL"):
> On Mon, Apr 04, 2016 at 01:15:53PM +, osstest service owner wrote:
> > flight 88656 xen-unstable-smoke real [real]
> > http://logs.test-lab.xenproject.org/osstest/logs/88656/
> >
> > Regressions :-(
> >
> > Tests which did not succeed and are blocking,
> > including tests which could not be run:
> > build-amd64-libvirt 5 libvirt-build fail REGR. vs.
> > 88144
> >
> > Tests which did not succeed, but are not blocking:
> > test-amd64-amd64-libvirt 1 build-check(1) blocked n/a
>
> This failed because libvirt doesn't set LIBXL_API_VERSION. It is not a
> bug in Xen code base.
>
> I don't think we have precedent of force-pushing smoke branch, so we
> need to decide what to do here.
Indeed.
> It would take some time for libvirt fix to land and propagate to our own
> mirror.
There is also a risk that the libvirt fix wouldn't pass osstest's push
gate for the libvirt branch.
> I would like to avoid holding backing xen.git push for too long
> if possible. So I'm for force-pushing the smoke branch and subsequently
> master branch if necessary.
I concur. I will wait a bit for contrary opinions, though.
Thanks,
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] Failed vm entry when emulating in hvm_do_resume()
Hello,
As a test, I've modified xen-access.c to this simplified skeleton:
http://pastebin.com/48WYwW00
then started up an x86 Windows 7 HVM guest, and ran it with:
# ./xen-access write
once the login screen appeared. The guest promptly crashed with this
backtrace:
http://pastebin.com/Bz0GeFta
The modified xen-access.c simply removes write rights for all of the
guest's pages, then attempts to emulate all instructions that might
cause a page fault. While I didn't expect the guest to run in a useable
manner, or Xen to be able to emulate all the instructions, I did not
expect the guest to crash.
So it would seem that hvm_do_resume() is, after all, not the best place
to emulate after a vm_event reply asks for emulation.
It's also not clear if (since in entry.S vmx_intr_assist() is being
called very early) we might not be, instead of right where we left off
on the VPCU when we sent out the mem_access vm_event, in an interrupt
handler (where emulating the first instruction is not good).
Could someone please recommend a safe place to try to emulate if
hvm_do_resume() is problematic?
Should I go back to the comparably inefficient way we did it before
(emulate on the second page fault where the RIP and GPA match)?
That indeed seems to offer no surprise crashes, but has the
aforementioned efficiency drawback, coupled with the fact that an
interrupt can cause the EIP and GPA to differ, in which case it would
take 4 page faults to finally emulate an offending instruction and
proceed. I did try the previous access_check() solution, and in addition
returning from vmx_intr_assist() (like the single stepping code does) if
there's an emulation request pending:
222 void vmx_intr_assist(void)
223 {
224 struct hvm_intack intack;
225 struct vcpu *v = current;
226 unsigned int tpr_threshold = 0;
227 enum hvm_intblk intblk;
228 int pt_vector = -1;
229
230 /* Block event injection when an instruction emulation is
pending. */
231 if ( unlikely(v->arch.vm_event) && v->arch.vm_event->emulate_flags )
232 return;
However that seems to trigger occassional BSODs related to clock
interrupts: http://i.imgur.com/EEz3JBV.png
Thanks,
Razvan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 20/28] HYPERCALL_version_op: Add VERSION_build_id to retrieve build-id.
>>> On 24.03.16 at 21:00, wrote: > The VERSION hypercall provides the flexibility to expose > the size of the build-id (so the callers can allocate the > proper size before trying to retrieve it). It also allows > in one nice swoop to retrieve the hypervisor build-id in the > provided buffer. > > Signed-off-by: Konrad Rzeszutek Wilk Non-XSM bits Acked-by: Jan Beulich provided the patch introducing version_op gets a replacement ack and hence doesn't need to be reverted. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 22/28] xsplice: Print build_id in keyhandler and on bootup.
>>> On 24.03.16 at 21:00, wrote:
> @@ -1414,10 +1420,16 @@ static void xsplice_printall(unsigned char key)
>
> static int __init xsplice_init(void)
> {
> +const void *binary_id = NULL;
> +unsigned int len = 0;
Pointless initializer.
> BUILD_BUG_ON( sizeof(struct xsplice_patch_func) != 64 );
> BUILD_BUG_ON( offsetof(struct xsplice_patch_func, new_addr) != 8 );
> BUILD_BUG_ON( offsetof(struct xsplice_patch_func, new_size) != 24 );
>
> +if ( !xen_build_id(&binary_id, &len) )
> +printk(XENLOG_INFO "%s: build-id: %*phN\n", XSPLICE, len, binary_id);
With the above corrected and the string literal not handed to %s
Acked-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V2 1/9] xenalyze: Support for ARM platform
On Mon, Apr 04, 2016 at 03:10:46PM +0100, Wei Liu wrote: > I would retitle this patch: > > xentrace: build for both x86 and ARM platform ^ xenalyze Sorry for the typo. Wei. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V2 0/9] xentrace/xenalyze support on ARM
On Fri, Apr 01, 2016 at 04:33:44PM -0400, Benjamin Sanda wrote: > This patch set adds support for xentrace/xenalyze to the ARM platform. > > The Xen heap memory mapping, timestamping, and P2M translation needed > by xentrace is corrected for operation on the ARM platform using the > x86 platform as reference. Trace buffer initialization is added to > setup.c, XENMAPSPACE_gmfn_foreign page mapping and address translation > for DOMID_XEN is corrected in mm.c and p2m.c, and timestamping for the > trace buffers is corrected in time.c/.h. > > Finally the xenaylze makefile is configured to build the tool for ARM. > > --- > Changed since v1: > * Removed Flask changes as deemed uncessesary and unclear in > purpose > * Corrected all commit messages to be line limited to 72 chars > * Implimented v1 review comments as indicated in each file's > commit log. > > Benjamin Sanda (9): > xenalyze: Support for ARM platform > xentrace: Support for ARM platform > xentrace: Support for ARM platform > xentrace: Support for ARM platform > xentrace: Support for ARM platform > xentrace: Support for ARM platform > xentrace: Support for ARM platform > xentrace: Support for ARM platform > xentrace: Support for ARM platform You patches all have the same subject line. Please make them more specific. See my reply to #1 for example. Wei. > > tools/xentrace/Makefile| 3 +-- > xen/arch/arm/mm.c | 3 ++- > xen/arch/arm/p2m.c | 35 +++ > xen/arch/arm/setup.c | 3 +++ > xen/arch/arm/time.c| 9 +++- > xen/arch/x86/mm.c | 48 --- > xen/common/page_alloc.c| 51 > ++ > xen/include/asm-arm/time.h | 11 +- > xen/include/xen/mm.h | 2 ++ > 9 files changed, 103 insertions(+), 62 deletions(-) > > -- > 2.5.0 > ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V2 1/9] xenalyze: Support for ARM platform
I would retitle this patch: xentrace: build for both x86 and ARM platform to be more specific. On Fri, Apr 01, 2016 at 04:33:46PM -0400, Benjamin Sanda wrote: > Modified to provide building of the xenalyze binary for ARM platforms. > This was done in conjunction with patches to xentrace allowing its use > on ARM. The xenalyze binary is now built as part of the BIN list. > > Signed-off-by: Benjamin Sanda > Acked-by: Wei Liu And I think this patch is better to be moved to the end of your series because it depends on hypervisor support. Wei. > --- > Changed since v1: > * changed xenalyze target from SBIN to BIN > * removed uneeded $(BIN-y) from BIN list > --- > tools/xentrace/Makefile | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/tools/xentrace/Makefile b/tools/xentrace/Makefile > index 0157be2..edcc5a7 100644 > --- a/tools/xentrace/Makefile > +++ b/tools/xentrace/Makefile > @@ -9,8 +9,7 @@ LDLIBS += $(LDLIBS_libxenevtchn) > LDLIBS += $(LDLIBS_libxenctrl) > LDLIBS += $(ARGP_LDFLAGS) > > -BIN-$(CONFIG_X86) = xenalyze > -BIN = $(BIN-y) > +BIN = xenalyze > SBIN = xentrace xentrace_setsize > LIBBIN = xenctx > SCRIPTS = xentrace_format > -- > 2.5.0 > ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Failed vm entry when emulating in hvm_do_resume()
On 04/04/16 14:32, Razvan Cojocaru wrote: > Hello, > > As a test, I've modified xen-access.c to this simplified skeleton: > > http://pastebin.com/48WYwW00 > > then started up an x86 Windows 7 HVM guest, and ran it with: > > # ./xen-access write > > once the login screen appeared. The guest promptly crashed with this > backtrace: > > http://pastebin.com/Bz0GeFta > > The modified xen-access.c simply removes write rights for all of the > guest's pages, then attempts to emulate all instructions that might > cause a page fault. While I didn't expect the guest to run in a useable > manner, or Xen to be able to emulate all the instructions, I did not > expect the guest to crash. This is just a plain emulation bug in 'cli', and has already been reported on the list. Noone has addressed the issue yet. The vmentry failure will be eflags not matching up with some other vmcs state. Looks like you have valid VMEntry intr_info injecting vector 0xd1, and eflags.IF disabled. This smells like a bug when considering whether to inject the next pending interrupt from the lapic. The reason you are seeing this with introspection is because you are the first people to test these codepaths. Normally, there is no way a 'cli' instruction could fault for emulation, because it has no memory operand. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] libxl gentypes.pl "saved_FOO" oddity
Coverity is complaining (eg, CID 1358114) about this code in
_libxl_types.c:
*** CID 1358114: Code maintainability issues (UNUSED_VALUE)
/tools/libxl/_libxl_types.c: 11035 in libxl__device_usbdev_parse_json()
11029 x = libxl__json_map_get("hostaddr", x, JSON_INTEGER);
11030 if (x) {
11031 rc = libxl__uint8_parse_json(gc, x, &p->u.hostdev.hostaddr);
11032 if (rc)
11033 goto out;
11034 }
>>> CID 1358114: Code maintainability issues (UNUSED_VALUE)
>>> Assigning value from "saved_hostaddr" to "x" here, but that stored
>>> vale is overwritten before it can be used.
11035 x = saved_hostaddr;
This does seem rather odd. I wasn't able to find any occurrences of
`x' outside these save/restore regions. So x is saved and restored
for no particular reason.
The root cause seems to be the reuse of x by both inner and outer
autogenerated code, where the generator may not know what is to be
inserted. Why not have a separate variable for each
libxl__json_map_get ?
This code is generated by gentypes.py, near line 438. It was written
by Ian Campbell in 2010 and doesn't seem to have been much touched
since.
Opinions welcome. In particular, should I attempt a patch to make
this code less odd-looking ?
Thanks,
Ian.
(CCing Wei who seems from git log like the only person who might have
a view.)
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 23/28] xsplice: Stacking build-id dependency checking.
>>> On 24.03.16 at 21:00, wrote:
> @@ -929,6 +932,33 @@ being loaded and requires an hypervisor build-id to
> match against.
> The old code allows much more flexibility and an additional guard,
> but is more complex to implement.
>
> +The second option which requires an build-id of the hypervisor
> +is implemented in the Xen Project hypervisor.
> +
> +Specifically each payload has two build-id ELF notes:
> + * The build-id of the payload itself (generated via --build-id).
> + * The build-id of the payload it depends on (extracted from the
> + the previous payload or hypervisor during build time).
> +
> +This means that the very first payload depends on the hypervisor
> +build-id.
So this is mean to be a singly linked chain, not something with
branches and alike, allowing independent patches to be applied
solely based on the base build ID? Is such a restriction not going
to get in the way rather sooner than later?
> +# Not Yet Done
> +
> +This is for further development of xSplice.
> +
> +## Goals
> +
> +The implementation must also have a mechanism for:
> +
> + * Be able to lookup in the Xen hypervisor the symbol names of functions
> from the ELF payload.
> + * Be able to patch .rodata, .bss, and .data sections.
> + * Further safety checks (blacklist of which functions cannot be patched,
> check
> + the stack, make sure the payload is built with same compiler as
> hypervisor,
> + and NMI/MCE handlers and do_nmi for right now - until an safe solution is
> found).
> + * NOP out the code sequence if `new_size` is zero.
> + * Deal with other relocation types: R_X86_64_[8,16,32,32S],
> R_X86_64_PC[8,16,64] in payload file.
Does this belong here? Doesn't this duplicate something I saw earlier?
> --- a/xen/common/version.c
> +++ b/xen/common/version.c
> @@ -70,10 +70,29 @@ const char *xen_deny(void)
> /* Defined in linker script. */
> extern const Elf_Note __note_gnu_build_id_start[],
> __note_gnu_build_id_end[];
>
> +int xen_build_id_check(const Elf_Note *n, const void **p, unsigned int *len)
> +{
> +/* Check if we really have a build-id. */
> +if ( NT_GNU_BUILD_ID != n->type )
> +return -ENODATA;
> +
> +/* Sanity check, name should be "GNU" for ld-generated build-id. */
> +if ( strncmp(ELFNOTE_NAME(n), "GNU", n->namesz) != 0 )
> +return -ENODATA;
For the embedded notes this suffices as verification, but I question
this being enough for a patch module: No part of the note should
exceed the containing section. And maybe there are other things.
> #else
>
> +int xen_build_id_check(const Elf_Note *n, const void **p, unsigned int *len)
> +{
> +return -ENODATA;
> +}
What case is this needed for, considering that only xSplice code
should be calling it, and that code depends on build ID availability.
> +static int build_id_dep(struct payload *payload, bool_t ignore)
> +{
> +const void *id = NULL;
> +unsigned int len = 0;
> +int rc;
> +const char *name = "hypervisor";
> +
> +ASSERT(payload->dep.len && payload->dep.p);
> +
> +/* First time user is against hypervisor. */
> +if ( ignore || list_empty(&applied_list) )
"ignore" is perhaps not the most descriptive name, as you aren't
ignoring anything here. Maybe "internal"? And then maybe have
the caller pass the argument using list_empty(&applied_list)
instead of you checking it here?
> --- a/xen/include/xen/version.h
> +++ b/xen/include/xen/version.h
> @@ -17,4 +17,7 @@ const char *xen_deny(void);
> #include
> int xen_build_id(const void **p, unsigned int *len);
>
> +#include
> +int xen_build_id_check(const Elf_Note *n, const void **p, unsigned int *len);
The #include is misplaced again, and I'm rather hesitant to see
version.h gain this dependency. Couldn't this go into xen/elf.h?
> --- a/xen/include/xen/xsplice.h
> +++ b/xen/include/xen/xsplice.h
> @@ -40,6 +40,11 @@ struct xsplice_symbol {
> bool_t new_symbol;
> };
>
> +struct xsplice_build_id {
> + const void *p;
> + unsigned int len;
> +};
This isn't being used outside of xsplice.c, so please define the
structure there.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] Wrong use of sizeof() in libxl_pvusb.c
Coverity complains, rightly, as follows:
> *** CID 1358110: Incorrect expression (SIZEOF_MISMATCH)
> /tools/libxl/libxl_pvusb.c: 1068 in bind_usbintf()
> 1062 if (fd < 0) {
> 1063 LOGE(ERROR, "open file failed: '%s'", path);
> 1064 rc = ERROR_FAIL;
> 1065 goto out;
> 1066 }
> 1067
> >>> CID 1358110: Incorrect expression (SIZEOF_MISMATCH)
> >>> Passing argument "intf" of type "char const *" and argument "8L /*
> >>> sizeof (intf) */" to function "libxl_write_exactly" is suspicious.
> 1068 if (libxl_write_exactly(CTX, fd, intf, sizeof(intf), path,
> intf)) {
There is another occurrence in unbind_usbintf (CID 1358109).
AFAICT the right thing is probably to replace sizeof by strlen, but I
am not 100% sure.
Note that on i386 and armhf, sizeof(intf) will always be 4, and on
amd64 and arm64, always 8. So this will write() garbage data into
sysfs. Presumably the kernel doesn't notice because the garbage is
generally (a) in valid address space for the process and (b) starts
with the nul byte at the end of the string.
Chunyan: please provide a patch (or procure that someone else does
so).
Please mention, in your commit message,
CID: 1358110
CID: 1358109
Thanks,
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V2 0/9] xentrace/xenalyze support on ARM
Hello, On 04/04/2016 15:11, Wei Liu wrote: On Fri, Apr 01, 2016 at 04:33:44PM -0400, Benjamin Sanda wrote: --- Changed since v1: * Removed Flask changes as deemed uncessesary and unclear in purpose * Corrected all commit messages to be line limited to 72 chars * Implimented v1 review comments as indicated in each file's commit log. Benjamin Sanda (9): xenalyze: Support for ARM platform xentrace: Support for ARM platform xentrace: Support for ARM platform xentrace: Support for ARM platform xentrace: Support for ARM platform xentrace: Support for ARM platform xentrace: Support for ARM platform xentrace: Support for ARM platform xentrace: Support for ARM platform You patches all have the same subject line. Please make them more specific. See my reply to #1 for example. +1 Also, you should at least check that Xen still builds after applying each patch. Ideally, you also need to be careful to not break any feature currently supported. It's useful when someone needs to bisect the tree. For instance, you use the function get_pg_owner for ARM in patch #2 but introduce the function in patch #4. This will break ARM build. So the patch #2 should be moved after #4. Furthermore, you remove the functions get_pg_owner and put_pg_owner for x86 in patch #3 and then re-introduced them in patch #4. Therefore, the x86 will be broken after #3. In this case, it's better to have a patch that move the 2 functions from x86 to common. Finally, please CC all the x86 maintainers (Jan and Andrew) on x86 changes. You need to manually check the CCs as under certain conditions the script get_maintainers.pl may not return all the relevant maintainers. I will wait the next iteration of this series to review the code. Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 25/28] xsplice: Print dependency and payloads build_id in the keyhandler.
>>> On 24.03.16 at 21:00, wrote:
> --- a/xen/common/xsplice.c
> +++ b/xen/common/xsplice.c
> @@ -1514,6 +1514,11 @@ static void xsplice_printall(unsigned char key)
> if ( !(i % 100) )
> process_pending_softirqs();
> }
> +if ( data->id.len )
> +printk("build-id=%*phN\n", data->id.len, data->id.p);
> +
> +if ( data->dep.len )
> +printk("depend-on=%*phN\n", data->dep.len, data->dep.p);
> }
>
> spin_unlock_recursive(&payload_lock);
Looks certainly fine, but wouldn't this better be part of patch 23?
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 26/28] xsplice: Prevent duplicate payloads from being loaded.
>>> On 24.03.16 at 21:00, wrote:
> --- a/xen/common/xsplice.c
> +++ b/xen/common/xsplice.c
> @@ -566,6 +566,27 @@ static int prepare_payload(struct payload *payload,
> if ( !payload->id.len || !payload->id.p )
> return -EINVAL;
> }
> +/* Make sure it is not a duplicate. */
> +if ( payload->id.len )
The conditional is pointless considering the one visible in context
above.
> +{
> +struct payload *data;
> +
> +spin_lock_recursive(&payload_lock);
> +list_for_each_entry ( data, &payload_list, list )
> +{
> +/* No way payload is on the list. */
> +ASSERT( data != payload );
> +if ( data->id.len &&
> + !memcmp(data->id.p, payload->id.p, data->id.len) )
> +{
> +spin_unlock_recursive(&payload_lock);
> +dprintk(XENLOG_DEBUG, "%s%s: Already loaded as %s!\n",
> +XSPLICE, elf->name, data->name);
> +return -EEXIST;
> +}
> +}
> +spin_unlock_recursive(&payload_lock);
Similar question as asked elsewhere - with the lock getting dropped
here, how is the "no duplicate" state going to be ensured by the
time you actually load and insert this payload?
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] Redundant lstats in libxl_pvusb.c
In libxl_usb.c, usbintf_get_drvpath calls stat(2) on the driver sysfs
path, and then realpath on the same path.
And bind_usbintf calls stat(2) on the driver directory path, and then
open(2) on a file in that directory.
It seems to be that in both cases, libxl could simply directly access
the target object. Ie, it could always call realpath, and always call
open. Appropriate error handling would deal with the cases currently
dealt with by the stat.
Am I wrong about this ?
I'm prompted to look at this by Coverity, Coverity thinks that this
stat-then-realpath, or stat-then-open, might be a TOCTOU security
problem. I think it's wrong, but it would be nice to tidy up the code
and eliminate these complaints.
If I am right, I'd appreciate patch(es). They should mention
CID: 1358112
CID: 1358111
for these two functions, respectively.
Thanks,
Ian.
> *** CID 1358112: Security best practices violations (TOCTOU)
> /tools/libxl/libxl_pvusb.c: 995 in usbintf_get_drvpath()
> 989 spath = GCSPRINTF(SYSFS_USB_DEV "/%s/driver", intf);
> 990
> 991 r = lstat(spath, &st);
> 992 if (r == 0) {
> 993 /* Find the canonical path to the driver. */
> 994 dp = libxl__zalloc(gc, PATH_MAX);
> >>> CID 1358112: Security best practices violations (TOCTOU)
> >>> Calling function "realpath" that uses "spath" after a check function.
> >>> This can cause a time-of-check, time-of-use race condition.
> 995 dp = realpath(spath, dp);
> 996 if (!dp) {
> 997 LOGE(ERROR, "get realpath failed: '%s'", spath);
> 998 return ERROR_FAIL;
> 999 }
> 1000 } else if (errno == ENOENT) {
> *** CID 1358111: Security best practices violations (TOCTOU)
> /tools/libxl/libxl_pvusb.c: 1061 in bind_usbintf()
> 1055 return 0;
> 1056 if (r < 0 && errno != ENOENT)
> 1057 return ERROR_FAIL;
> 1058
> 1059 path = GCSPRINTF("%s/bind", drvpath);
> 1060
> >>> CID 1358111: Security best practices violations (TOCTOU)
> >>> Calling function "open" that uses "path" after a check function. This
> >>> can cause a time-of-check, time-of-use race condition.
> 1061 fd = open(path, O_WRONLY);
> 1062 if (fd < 0) {
> 1063 LOGE(ERROR, "open file failed: '%s'", path);
> 1064 rc = ERROR_FAIL;
> 1065 goto out;
> 1066 }
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] New Defects reported by Coverity Scan for XenProject
scan-ad...@coverity.com writes ("New Defects reported by Coverity Scan for
XenProject"):
> Please find the latest report on new defect(s) introduced to XenProject found
> with Coverity Scan.
>
> 35 new defect(s) introduced to XenProject found with Coverity Scan.
> 2 defect(s), reported by Coverity Scan earlier, were marked fixed in the
> recent build analyzed by Coverity Scan.
>
> New defect(s) Reported-by: Coverity Scan
> Showing 20 of 35 defect(s)
I have been through the tools reports here. None of them are security
problems in released branches.
I would like some advice from Coverity experts on the two below:
> ** CID 1358088: Concurrent data access violations (MISSING_LOCK)
Applies to 1358086..1358105 inclusive. Here is a sample:
> *** CID 1358088: Concurrent data access violations (MISSING_LOCK)
> /tools/libxl/libxl_event.c: 2189 in libxl__ao_progress_report()
> 2183 } else if (how->callback) {
> 2184 libxl__aop_occurred *aop = libxl__zalloc(&egc->gc,
> sizeof(*aop));
> 2185 ao->progress_reports_outstanding++;
> 2186 aop->ao = ao;
> 2187 aop->ev = ev;
> 2188 aop->how = how;
> >>> CID 1358088: Concurrent data access violations (MISSING_LOCK)
> >>> Accessing "egc->aops_for_callback.tqh_last" without holding lock
> >>> "libxl__ctx.lock". Elsewhere, "libxl__egc.aops_for_callback.tqh_last" is
> >>> accessed with "libxl__ctx.lock" held 34 out of 44 times.
> 2189 LIBXL_TAILQ_INSERT_TAIL(&egc->aops_for_callback, aop, entry);
> 2190 LOG(DEBUG,"ao %p: progress report: callback queued
> aop=%p",ao,aop);
> 2191 } else {
> 2192 LOG(DEBUG,"ao %p: progress report: event queued ev=%p
> type=%s",
> 2193 ao, ev, libxl_event_type_to_string(ev->type));
> 2194 libxl__event_occurred(egc, ev);
This is a false positive. An egc is always allocated on the stack of
the thread that uses it. It is only ever used by that thread. So
does not need to be protected by a lock.
Is there a way we can teach Coverity about this ?
> ** CID 1358085: Incorrect expression (IDENTICAL_BRANCHES)
> /tools/libxl/_libxl_types.c: 5611 in libxl_device_usbdev_gen_json()
Applies to 1358081..1358084 inclusive.
Here is a sample:
> *** CID 1358085: Incorrect expression (IDENTICAL_BRANCHES)
> /tools/libxl/_libxl_types.c: 5611 in libxl_device_usbdev_gen_json()
> 5605 if (s != yajl_gen_status_ok)
> 5606 goto out;
> 5607 break;
> 5608 }
> 5609 }
> 5610 s = yajl_gen_map_close(hand);
> >>> CID 1358085: Incorrect expression (IDENTICAL_BRANCHES)
> >>> The same code is executed when the condition "s !=
> >>> yajl_gen_status_ok" is true or false, because the code in the if-then
> >>> branch and after the if statement is identical. Should the if statement
> >>> be removed?
> 5611 if (s != yajl_gen_status_ok)
> 5612 goto out;
> 5613 out:
> 5614 return s;
This is a false positive arising from autogenerated code. The
autogenerated code naturally has a completely systematic error
handling pattern, which leads to it sometimes doing this:
if (error)
goto out;
out:
/* exit path */
Is there a way to arrange to always persuade Coverity that this is
intentional ?
Thanks,
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 5/9] libxl: Rearrange qemu upstream disk argument code
On 01/04/16 15:31, Ian Jackson wrote:
> George Dunlap writes ("[PATCH v3 5/9] libxl: Rearrange qemu upstream disk
> argument code"):
>> Reorganize the qemuu disk argument code to make a clean separation
>> between finding a file to use, and constructing the parameters:
>
> This didn't apply to staging, since colo went in.
> I have tried to rebase it and the result compiles.
>
> Can you check it's right please ?
>
> Thanks,
> Ian.
>
> From 6ab86b63462c8e6dc243c796f5ea10240aadc5de Mon Sep 17 00:00:00 2001
> From: George Dunlap
> Date: Thu, 24 Mar 2016 17:18:33 +
> Subject: [PATCH] libxl: Rearrange qemu upstream disk argument code
>
> Reorganize the qemuu disk argument code to make a clean separation
> between finding a file to use, and constructing the parameters:
>
> * Rename pdev_path to target_path
>
> * Only use qemu_disk_format_string() in circumstances where qemu may
> be interpreting the disk (i.e., backend==QDISK). In all other cases,
> it should use RAW.
>
> * Share as much as possible between the is_cdrom path and the normal
> path.
>
> This is mainly prep for sharing the local path finder with the
> bootloader; but it does allow cdroms to use any backend that a normal
> disk can use. Previously this was limited to RAW files or things that
> qemu could handle directly; as of this changeset, it now includes tap
> disks; and in future changesets it will include backends with custom
> block scripts.
>
> NB that this retains an existing bug, that disks with custom block
> scripts or non-dom0 backends will have the bogus pdev_path passed in
> to qemu, most likely resulting in qemu exiting with an error. This
> will be fixed in follow-up patches.
>
> Signed-off-by: George Dunlap
> Signed-off-by: Ian Jackson
I looked through the patch in the branch provided in your reply to 0/9
[1], and it looks correct; morever, I tested it and it and the basic
functionality (using the "dummy" block script) still works.
Reviewed-by: George Dunlap
Tested-by: George Dunlap
[1] git://xenbits.xenproject.org/people/iwj/xen.git wip.gwd.hotplug-v3.1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [hypervisor deadlock] Re: [PATCH v9 for Xen 4.7 1/4] xen: enable per-VCPU parameter for RTDS
On 01/04/16 05:59, Chong Li wrote:
> diff --git a/xen/common/sched_credit.c b/xen/common/sched_credit.c
> index 305889a..e5d15d8 100644
> --- a/xen/common/sched_credit.c
> +++ b/xen/common/sched_credit.c
> @@ -1080,15 +1080,13 @@ csched_dom_cntl(
> * lock. Runq lock not needed anywhere in here. */
> spin_lock_irqsave(&prv->lock, flags);
>
> -if ( op->cmd == XEN_DOMCTL_SCHEDOP_getinfo )
> +switch ( op->cmd )
> {
> +case XEN_DOMCTL_SCHEDOP_getinfo:
> op->u.credit.weight = sdom->weight;
> op->u.credit.cap = sdom->cap;
> -}
> -else
> -{
> -ASSERT(op->cmd == XEN_DOMCTL_SCHEDOP_putinfo);
> -
> +break;
> +case XEN_DOMCTL_SCHEDOP_putinfo:
> if ( op->u.credit.weight != 0 )
> {
> if ( !list_empty(&sdom->active_sdom_elem) )
> @@ -1101,7 +1099,9 @@ csched_dom_cntl(
>
> if ( op->u.credit.cap != (uint16_t)~0U )
> sdom->cap = op->u.credit.cap;
> -
> +break;
> +default:
> +return -EINVAL;
This path returns without unlocking prv->lock.
> }
>
> spin_unlock_irqrestore(&prv->lock, flags);
> diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
> index 7ddad38..d48ed5a 100644
> --- a/xen/common/sched_credit2.c
> +++ b/xen/common/sched_credit2.c
> @@ -1421,14 +1421,12 @@ csched2_dom_cntl(
> * runq lock to update csvcs. */
> spin_lock_irqsave(&prv->lock, flags);
>
> -if ( op->cmd == XEN_DOMCTL_SCHEDOP_getinfo )
> +switch ( op->cmd )
> {
> +case XEN_DOMCTL_SCHEDOP_getinfo:
> op->u.credit2.weight = sdom->weight;
> -}
> -else
> -{
> -ASSERT(op->cmd == XEN_DOMCTL_SCHEDOP_putinfo);
> -
> +break;
> +case XEN_DOMCTL_SCHEDOP_putinfo:
> if ( op->u.credit2.weight != 0 )
> {
> struct vcpu *v;
> @@ -1457,6 +1455,9 @@ csched2_dom_cntl(
> vcpu_schedule_unlock(lock, svc->vcpu);
> }
> }
> +break;
> +default:
> +return -EINVAL;
As does this.
Please submit a bugfix ASAP. This will become a security vulnerability
if Xen 4.7 is shipped without it being fixed.
> }
>
> spin_unlock_irqrestore(&prv->lock, flags);
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 2/2] libxl: Do not leak data on error path from libxl__read_sysfs_file_contents
Bug introduced in bc023ecd "libxl_utils: add internal function to read sysfs file contents" CID: 1358108 Signed-off-by: Ian Jackson CC: cover...@xenproject.org CC: Chunyan Liu --- tools/libxl/libxl_utils.c |1 + 1 file changed, 1 insertion(+) diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c index ceb8825..bd58a52 100644 --- a/tools/libxl/libxl_utils.c +++ b/tools/libxl/libxl_utils.c @@ -466,6 +466,7 @@ int libxl__read_sysfs_file_contents(libxl__gc *gc, const char *filename, e = errno; assert(e != ENOENT); if (f) fclose(f); +free(data); return e; } -- 1.7.10.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 1/2] libxl: Set rc on failure of usbdev_busaddr_to_busid
We must set rc before using `goto out'.
Bug introduced in bf7628f0 "libxl: add pvusb API".
CID: 1358113
Signed-off-by: Ian Jackson
CC: cover...@xenproject.org
CC: Simon Cao
CC: George Dunlap
CC: Chunyan Liu
---
tools/libxl/libxl_pvusb.c |1 +
1 file changed, 1 insertion(+)
diff --git a/tools/libxl/libxl_pvusb.c b/tools/libxl/libxl_pvusb.c
index 5f92628..6f53317 100644
--- a/tools/libxl/libxl_pvusb.c
+++ b/tools/libxl/libxl_pvusb.c
@@ -905,6 +905,7 @@ static int libxl__device_usbdev_add_xenstore(libxl__gc *gc,
uint32_t domid,
usbdev->u.hostdev.hostaddr);
if (!busid) {
LOG(DEBUG, "Fail to get busid of usb device");
+rc = ERROR_FAIL;
goto out;
}
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 27/28] xsplice: Add support for shadow variables.
>>> On 24.03.16 at 21:00, wrote:
> Shadow variables are a piece of infrastructure to be used by xsplice
> modules. They are used to attach a new piece of data to an existing
> structure in memory.
An already known question again: Out of recent XSAs, how many
needed such? I.e. can#t we put this off for now?
> Martin Pohlack also mentions that using the SHADOW_SLOTS of small
> prime numbers has the advantage of having a simple hash function.
This reads kind of backwards.
> +void xsplice_shadow_free(const void *obj, const char *var)
> +{
> +struct shadow_var *entry, *shadow = NULL;
> +unsigned int slot;
> +struct hlist_node *next;
> +
> +slot = (unsigned long)obj % SHADOW_SLOTS;
> +
> +spin_lock(&shadow_lock);
> +hlist_for_each_entry(entry, next, &shadow_tbl[slot], list)
> +{
> +if ( entry->obj == obj &&
> + !strcmp(entry->var, var) )
> +{
> +shadow = entry;
> +break;
> +}
> +}
> +if (shadow)
Coding style.
> +{
> +hlist_del(&shadow->list);
> +xfree(shadow->data);
> +xfree(shadow);
> +}
> +spin_unlock(&shadow_lock);
> +}
Uniqueness not being guaranteed by the allocation function, how
can you free the first hit here ...
> +void *xsplice_shadow_get(const void *obj, const char *var)
> +{
> +struct shadow_var *entry;
> +unsigned int slot;
> +struct hlist_node *next;
> +void *ret = NULL;
> +
> +slot = (unsigned long)obj % SHADOW_SLOTS;
> +
> +spin_lock(&shadow_lock);
> +hlist_for_each_entry(entry, next, &shadow_tbl[slot], list)
> +{
> +if ( entry->obj == obj &&
> + !strcmp(entry->var, var) )
> +{
> +ret = entry->data;
> +break;
> +}
> +}
> +
> +spin_unlock(&shadow_lock);
> +return ret;
> +}
.. or return the first match here?
> +static int __init xsplice_shadow_init(void)
> +{
> +int i;
unsigned int
> --- a/xen/include/xen/xsplice_patch.h
> +++ b/xen/include/xen/xsplice_patch.h
> @@ -56,4 +56,40 @@ typedef void (*xsplice_unloadcall_t)(void);
> #define XSPLICE_UNLOAD_HOOK(_fn) \
> xsplice_unloadcall_t __attribute__((weak)) xsplice_unload_data
> __section(".xsplice.hooks.unload") = _fn;
>
> +
> +/*
> + * The following definitions are to be used in patches. They are taken
> + * from kpatch.
> + */
> +
> +/*
> + * xsplice shadow variables
> + *
> + * These functions can be used to add new "shadow" fields to existing data
> + * structures. For example, to allocate a "newpid" variable associated with
> an
> + * instance of task_struct, and assign it a value of 1000:
> + *
> + * struct task_struct *tsk = current;
> + * int *newpid;
> + * newpid = xsplice_shadow_alloc(tsk, "newpid", sizeof(int));
> + * if (newpid)
> + * *newpid = 1000;
> + *
> + * To retrieve a pointer to the variable:
> + *
> + * struct task_struct *tsk = current;
> + * int *newpid;
> + * newpid = xsplice_shadow_get(tsk, "newpid");
> + * if (newpid)
> + * printk("task newpid = %d\n", *newpid); // prints "task newpid = 1000"
> + *
> + * To free it:
> + *
> + * xsplice_shadow_free(tsk, "newpid");
> + */
While this indeed provides some basic understanding, I think this
should be using a more Xen-affine example, and I fail to see how
with particularly the example given this is going to be useful: How
would the patch module sanely and within reasonable time get
hold of all instances of a particular type?
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v13 03/26] tools/libxl: Add back channel to allow migration target send data back
On Mon, Apr 04, Wei Liu wrote:
> The fix is to patch libvirt. Looking at libvirt code I think I need to
> patch Makefile.in to pass in an explicit LIBXL_API_VERSION number.
That might be true.
But shouldnt at the same time libxl.h get a change to recognize
0x040700? Perhaps this will be part of the release management.
For the time being this change fixes it for me:
+++ libvirt.spec(working copy)
@@ -1163,6 +1163,7 @@
autoreconf -f -i
export CFLAGS="$RPM_OPT_FLAGS"
+export CFLAGS="$CFLAGS -DLIBXL_API_VERSION=0x040500"
%configure --disable-static --with-pic \
%{?_without_xen} \
%{?_without_qemu} \
Olaf
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 3/9] x86/head: Move early exception panic code into early_fixup_exception
On Apr 4, 2016 4:51 AM, "Jan Kara" wrote:
>
> On Sat 02-04-16 13:58:19, Andy Lutomirski wrote:
> > [cc Jan Kara]
> >
> > On Sat, Apr 2, 2016 at 1:47 PM, Borislav Petkov wrote:
> > > On Sat, Apr 02, 2016 at 01:13:37PM -0700, Andy Lutomirski wrote:
> > >> Given that I this isn't really a regression with my patches (it
> > >> probably never worked much better on 32-bit and the regs never would
> > >> have shown at all on 64-bit),
> > >
> > > You're right. That thing calls printk *and* early_printk, WTF:
> > >
> > > #ifdef CONFIG_EARLY_PRINTK
> > >
> > > call early_printk
> > > ...
> > >
> > > call dump_stack
> > >
> > > ...
> > >
> > > call __print_symbol
> > >
> > > those last two call printk. Great.
> > >
> > >> I propose a different approach: make
> > >> printk work earlier. Something like:
> > >>
> > >> if (early) {
> > >> early_printk(args);
> > >> }
> > >>
> > >> or early_vprintk or whatever.
> > >>
> > >> If the cost of a branch mattered, this could be alternative-patched
> > >> out later on, but that seems silly. I also bet that a more sensible
> > >> fallback could be created in which printk would try to use an early
> > >> console if there's no real console.
> > >
> > > So how about this:
> > >
> > > printk() does
> > >
> > > vprintk_func = this_cpu_read(printk_func);
> > >
> > > and that's
> > >
> > > DEFINE_PER_CPU(printk_func_t, printk_func) = vprintk_default
> > >
> > > I guess we can make that function be early_printk-something and once
> > > printk is initialized, we overwrite it with vprintk_default.
> > >
> > > Elegant and no need for if branches and alternatives.
> > >
> > > Hmmm.
> >
> > Jan, IIRC you were looking at printk recently-ish. Any thoughts here?
>
> Sounds like a good idea to me. I've also consulted this with Petr Mladek
> (added to CC) who is using printk_func per-cpu variable in his
> printk-from-NMI patches and he also doesn't see a problem with this.
>
> I was just wondering about one thing - this way we add more early printks
> if I understand your intention right. Are we guaranteed that they happen
> only from a single CPU? Because currently there is no locking in
> early_printk() and thus we can end up writing to early console several
> messages in parallel from different CPUs. Not sure what's going to happen
> in that case...
Adding locking would be easy enough, wouldn't it?
But do any platforms really boot a second CPU before switching to real
printk? Given that I see all the smpboot stuff in dmesg, I guess real
printk happens first. I admit I haven't actually checked.
--Andy
>
> Honza
> --
> Jan Kara
> SUSE Labs, CR
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 3/9] x86/head: Move early exception panic code into early_fixup_exception
On 4/4/2016 8:32 AM, Andy Lutomirski wrote: Adding locking would be easy enough, wouldn't it? But do any platforms really boot a second CPU before switching to real printk? Given that I see all the smpboot stuff in dmesg, I guess real printk happens first. I admit I haven't actually checked. adding locking also makes things more fragile in terms of getting the last thing out before you go down in flaming death until it's a proven problem, this early, get the message out at all is more important than getting it out perfectly, sometimes. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] ARMv8: New board bring up hangs in kernel start?
Hi Julien, On 01.04.2016 18:34, Julien Grall wrote: On 31/03/16 18:41, Dirk Behme wrote: Hello Julien, Hello Dirk, On 29.03.2016 20:53, Julien Grall wrote: On 23/03/16 17:24, Dirk Behme wrote: trying to bring up Xen on a new ARMv8 64-bit Cortex A57 eval board, I get [1] and then its hanging there. The logs look normal. Do you know where the kernel get stuck? You can press CTRL-a 3 times to get access to the Xen console and then press: * 0 => dump Dom0 registers * d => dump registers Hmm, CTRL-a 3 times doesn't seem to work, either. This does need working interrupts, too? I.e. that it doesn't work is an additional hint that anything with the interrupt handling might be wrong? The entry point for all the interrupts is do_IRQ. You can add a breakpoint there to know if you receive interrupts. Maybe I should debug this, first. It's handled by Xen's drivers/char/console.c / serial.c and the board specific UART device driver, correct? The generic IRQ code (see do_IRQ) will dispatch the interrupt directly to the interrupt handler you specific via setup_irq/request_irq. Usually this handler is specific to the driver. I'd guess that it hangs due to missing timer interrupt, maybe missing interrupts at all? Any hints how to debug this? Or where to look? It might be possible that the board's firmware (arm-trusted-firmware based) doesn't configure anything correctly. Firmware is running at EL3, Xen at EL2. The same kernel is running fine without Xen. Using a JTAG debugger I've put breakpoints into xen/arch/arm/time.c timer_interrupt() & vtimer_interrupt() but these don't seem to be called at all (?) They should be called if the timer is configured correctly. Best regards Dirk [1] [...] > (XEN) Checking for initrd in /chosen > (XEN) RAM: 4800 - 7fff > (XEN) > (XEN) MODULE[0]: 4800 - 480058a2 Device Tree > (XEN) MODULE[1]: 4820 - 48c0 Kernel > (XEN) > (XEN) Command line: console=dtuart dom0_mem=512M loglvl=all > (XEN) Placing Xen at 0x7fe0-0x8000 > (XEN) Update BOOTMOD_XEN from 4900-49112e01 => > 7fe0-7ff12e01 > (XEN) Domain heap initialised > (XEN) Platform: ARMv8 Cortex A57 64-bit eval board > (XEN) Taking dtuart configuration from /chosen/stdout-path > (XEN) Looking for dtuart at "/soc/serial@e6e88000", options "" > Xen 4.7-unstable > (XEN) Xen version 4.7-unstable (dirk@build) (aarch64-poky-linux-gcc > (Linaro GCC 4.9-2015.03) 4.9.3 20150311 (prerelease)) debug=y Mon Mar 21 > 09:15:03 CET 2016 > (XEN) Latest ChangeSet: Tue Feb 9 09:37:15 2016 +0100 git:b0a2893 I can't find this changeset in tree. Can you provide your baseline commit and the list of patches you applied on top? This is 483ad4439f7fc7 xen-access: minor fixes plus a local patch to support the board's serial port. Is it a patch to add earlyprintk or a completely new driver? Just earlyprintk. Also have you tried a newer version of Xen? I've switched to the recent master a6f2cdb63 x86/hvm/viridian: keep APIC assist page mapped now. No difference. I'll have a deeper look into the interrupt configuration. Is there anywhere some basic description which interrupts are supposed to be handled by XEN and which by the Linux kernel? I.e. how the ARM GIC should be configured regarding the distributor/CPU/virtual parts? All the interrupts are taken by Xen. The function do_IRQ in Xen will dispatch the IRQ either to a guest or call a Xen specific handler. Xen handles only a limited number of interrupt: * timers * UART * SMMU The rest is either routed to guests or blacklisted by Xen. Ok, thanks, that helps :) Once I have it working, maybe I post a patch to add this info to the documentation. Just an other question: On ARMv8 64-bit Xen is supposed to be started at EL2 *nonsecure*, correct? It looks to me that the GICv2 on my board is already partly configured by the firmware at secure EL3. That does mean, whatever gicv2_dist_init() and gicv2_cpu_init() are supposed to do, they can't do it (completely) because they don't have access to the secure part of the GIC (?) Best regards Dirk ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH] x86/extable: Add a comment about early exception handlers
Borislav asked for a comment explaining why all exception handlers are allowed early. Signed-off-by: Andy Lutomirski --- arch/x86/mm/extable.c | 14 ++ 1 file changed, 14 insertions(+) diff --git a/arch/x86/mm/extable.c b/arch/x86/mm/extable.c index 98b5f45d9d79..36fe03bc81ee 100644 --- a/arch/x86/mm/extable.c +++ b/arch/x86/mm/extable.c @@ -132,6 +132,20 @@ void __init early_fixup_exception(struct pt_regs *regs, int trapnr) if (regs->cs != __KERNEL_CS) goto fail; + /* +* The full exception fixup machinery is available as soon as +* the early IDT is loaded. This means that it is the +* responsibility of extable users to either function correctly +* when handlers are invoked early or to simply avoid causing +* exceptions before they're ready to handle them. +* +* This is better than filtering which handlers can be used, +* because refusing to call a handler here is guaranteed to +* result in a hard-to-debug panic. +* +* Keep in mind that not all vectors actually get here. Early +* fage faults, for example, are special. +*/ if (fixup_exception(regs, trapnr)) return; -- 2.5.5 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 4/9] x86/traps: Enable all exception handler callbacks early
On Sun, Apr 3, 2016 at 7:10 AM, Borislav Petkov wrote: > On Sun, Apr 03, 2016 at 06:55:00AM -0700, Andy Lutomirski wrote: >> > No, please don't fail at early boot. >> > >> > Early boot is just about the *worst* situation to try to debug odd >> > failures, exactly since things like printk may not be reliable, and >> > things won't get logged etc. >> > >> > So particularly during early boot we should try as hard as possible >> > not to crash - even if it means not being able to log about a problem. >> > At least that way you have a hopefully working machine and can *maybe* >> > debug things. >> > >> >> In this regard, at least, my patch is the right approach. Calling the >> handler, whatever it is, is less likely to panic than refusing to call >> it. > > Ok, good. > > But can we pretty please document this whole situation, i.e., the > fact that we're trying really really hard not to fail early boot for > debuggability reasons - either in the commit message or better in the > code, for future reference. I think this is an important aspect to hold > down. I emailed out a followup patch to add a comment. --Andy > > Thanks. > > -- > Regards/Gruss, > Boris. > > ECO tip #101: Trim your mails when you reply. -- Andy Lutomirski AMA Capital Management, LLC ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V7 1/3] x86/xsaves: fix overwriting between non-lazy/lazy xsaves
>>> On 31.03.16 at 10:57, wrote: > xsaves will not be used until supervised state is introduced in hypervisor. > And XSTATE_XSAVES_ONLY (indicates supervised state is understood in xen) > is instroduced, the use of xsaves depend on whether XSTATE_XSAVES_ONLY There's still a spelling mistake here, despite me having pointed it out before (you fixed one instance, but not the other). This could be dealt with upon commit, though. > is set in xcr0_accum. Btw, I think this shouldn't be a #define, as it can - afaict - be derived from CPUID output. But this can easily be a follow-up patch, even one that doesn't make it into 4.7. > Signed-off-by: Shuai Ruan > Reported-by: Jan Beulich Reviewed-by: Jan Beulich ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V2 0/9] xentrace/xenalyze support on ARM
Julien and Wei, >> You patches all have the same subject line. Please make them more >> specific. See my reply to #1 for example. > > +1 > > Also, you should at least check that Xen still builds after applying > each patch. Ideally, you also need to be careful to not break any > feature currently supported. It's useful when someone needs to > bisect the tree. > > For instance, you use the function get_pg_owner for ARM in patch #2 > but introduce the function in patch #4. This will break ARM build. > So the patch #2 should be moved after #4. > > Furthermore, you remove the functions get_pg_owner and put_pg_owner > for x86 in patch #3 and then re-introduced them in patch #4. > Therefore, the x86 will be broken after #3. In this case, it's better > to have a patch that move the 2 functions from x86 to common. Thank you for the comments. I apologize for the errors in the patch format. This is my first time submitting a patch to Xen and I was unaware that the patch set order mattered or that I had to account for a piecewise application of the patch set. I will attempt to resubmit with this corrected and the patch names updated. So then it is permissible to have multiple file changes in one patch/commit? E.g. a patch that removes from one file and adds to another in the same commit. I initially thought each patch/ commit was only supposed to modify one file and that's why I did it that way Thank you, Ben Sanda ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable-smoke test] 88672: regressions - FAIL
flight 88672 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/88672/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-libvirt 5 libvirt-build fail REGR. vs. 88144 Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass version targeted for testing: xen a0f793d82d5ec2d0b67c57d7130bf01c91396c60 baseline version: xen 96ae556569b8eaedc0bb242932842c3277b515d8 Last test of basis88144 2016-03-31 13:06:39 Z4 days Failing since 88279 2016-04-01 14:03:55 Z3 days 33 attempts Testing same since88672 2016-04-04 14:03:45 Z0 days1 attempts People who touched revisions under test: Andrew Cooper Changlong Xie Chong Li Dario Faggioli George Dunlap Ian Campbell Ian Jackson Jan Beulich Juergen Gross Kevin Tian Konrad Rzeszutek Wilk Meng Xu Mike Meyer Olaf Hering Paul Durrant Roger Pau Monne Roger Pau Monné Sisu Xi Wei Liu Wen Congyang Yang Hongyang jobs: build-amd64 pass build-armhf pass build-amd64-libvirt fail test-armhf-armhf-xl pass test-amd64-amd64-xl-qemuu-debianhvm-i386 pass test-amd64-amd64-libvirt blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 856 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V2 0/9] xentrace/xenalyze support on ARM
On Mon, Apr 04, 2016 at 03:50:35PM +, Ben Sanda wrote: > Julien and Wei, > > >> You patches all have the same subject line. Please make them more > >> specific. See my reply to #1 for example. > > > > +1 > > > > Also, you should at least check that Xen still builds after applying > > each patch. Ideally, you also need to be careful to not break any > > feature currently supported. It's useful when someone needs to > > bisect the tree. > > > > For instance, you use the function get_pg_owner for ARM in patch #2 > > but introduce the function in patch #4. This will break ARM build. > > So the patch #2 should be moved after #4. > > > > Furthermore, you remove the functions get_pg_owner and put_pg_owner > > for x86 in patch #3 and then re-introduced them in patch #4. > > Therefore, the x86 will be broken after #3. In this case, it's better > > to have a patch that move the 2 functions from x86 to common. > > Thank you for the comments. I apologize for the errors in the patch > format. This is my first time submitting a patch to Xen and I was > unaware that the patch set order mattered or that I had to account for > a piecewise application of the patch set. I will attempt to resubmit > with this corrected and the patch names updated. > > So then it is permissible to have multiple file changes in one > patch/commit? E.g. a patch that removes from one file and adds to That's definitely allowed. Just think of each commit as a logically complete unit. It should compile. It should not break existing functionality. Wei. > another in the same commit. I initially thought each patch/ commit was > only supposed to modify one file and that's why I did it that way > > Thank you, > Ben Sanda ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [hypervisor deadlock] Re: [PATCH v9 for Xen 4.7 1/4] xen: enable per-VCPU parameter for RTDS
On Mon, Apr 4, 2016 at 10:14 AM, Andrew Cooper
wrote:
> On 01/04/16 05:59, Chong Li wrote:
>> diff --git a/xen/common/sched_credit.c b/xen/common/sched_credit.c
>> index 305889a..e5d15d8 100644
>> --- a/xen/common/sched_credit.c
>> +++ b/xen/common/sched_credit.c
>> @@ -1080,15 +1080,13 @@ csched_dom_cntl(
>> * lock. Runq lock not needed anywhere in here. */
>> spin_lock_irqsave(&prv->lock, flags);
>>
>> -if ( op->cmd == XEN_DOMCTL_SCHEDOP_getinfo )
>> +switch ( op->cmd )
>> {
>> +case XEN_DOMCTL_SCHEDOP_getinfo:
>> op->u.credit.weight = sdom->weight;
>> op->u.credit.cap = sdom->cap;
>> -}
>> -else
>> -{
>> -ASSERT(op->cmd == XEN_DOMCTL_SCHEDOP_putinfo);
>> -
>> +break;
>> +case XEN_DOMCTL_SCHEDOP_putinfo:
>> if ( op->u.credit.weight != 0 )
>> {
>> if ( !list_empty(&sdom->active_sdom_elem) )
>> @@ -1101,7 +1099,9 @@ csched_dom_cntl(
>>
>> if ( op->u.credit.cap != (uint16_t)~0U )
>> sdom->cap = op->u.credit.cap;
>> -
>> +break;
>> +default:
>> +return -EINVAL;
>
> This path returns without unlocking prv->lock.
>
>> }
>>
>> spin_unlock_irqrestore(&prv->lock, flags);
>> diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
>> index 7ddad38..d48ed5a 100644
>> --- a/xen/common/sched_credit2.c
>> +++ b/xen/common/sched_credit2.c
>> @@ -1421,14 +1421,12 @@ csched2_dom_cntl(
>> * runq lock to update csvcs. */
>> spin_lock_irqsave(&prv->lock, flags);
>>
>> -if ( op->cmd == XEN_DOMCTL_SCHEDOP_getinfo )
>> +switch ( op->cmd )
>> {
>> +case XEN_DOMCTL_SCHEDOP_getinfo:
>> op->u.credit2.weight = sdom->weight;
>> -}
>> -else
>> -{
>> -ASSERT(op->cmd == XEN_DOMCTL_SCHEDOP_putinfo);
>> -
>> +break;
>> +case XEN_DOMCTL_SCHEDOP_putinfo:
>> if ( op->u.credit2.weight != 0 )
>> {
>> struct vcpu *v;
>> @@ -1457,6 +1455,9 @@ csched2_dom_cntl(
>> vcpu_schedule_unlock(lock, svc->vcpu);
>> }
>> }
>> +break;
>> +default:
>> +return -EINVAL;
>
> As does this.
>
> Please submit a bugfix ASAP. This will become a security vulnerability
> if Xen 4.7 is shipped without it being fixed.
>
>> }
>>
>> spin_unlock_irqrestore(&prv->lock, flags);
>
Thanks for pointing this out.
Dario, do you want to include this bugfix in your cleanup patch, or
let me submit this?
Chong
--
Chong Li
Department of Computer Science and Engineering
Washington University in St.louis
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V7 2/3] x86/xsaves: fix two remained issues
>>> On 31.03.16 at 10:57, wrote:
Considering this isn't the last patch in the series, the subject isn't
really nice (apart from being mis-spelled). If you e.g. replaced
"remained" by "miscellaneous", I wouldn't insist on splitting.
> 1. get_xsave_addr() will only be called when
> xsave_area_compressed(xsave) is true. So drop the
> conditional expression.
>
> 2. expand_xsave_states() will memset the area when
> get NULL from get_xsave_addr().
Reported-by: ...
> Signed-off-by: Shuai Ruan
>
> xen/arch/x86/xstate.c | 10 --
> 1 file changed, 4 insertions(+), 6 deletions(-)
>
> diff --git a/xen/arch/x86/xstate.c b/xen/arch/x86/xstate.c
> index 8c652bc..f4ea54d 100644
> --- a/xen/arch/x86/xstate.c
> +++ b/xen/arch/x86/xstate.c
> @@ -164,12 +164,8 @@ static void *get_xsave_addr(struct xsave_struct *xsave,
> const uint16_t *comp_offsets,
> unsigned int xfeature_idx)
> {
> -if ( !((1ul << xfeature_idx) & xsave->xsave_hdr.xstate_bv) )
> -return NULL;
> -
> -return (void *)xsave + (xsave_area_compressed(xsave) ?
> -comp_offsets[xfeature_idx] :
> -xstate_offsets[xfeature_idx]);
> +return (1ul << xfeature_idx) & xsave->xsave_hdr.xstate_bv ?
> + (void *)xsave + comp_offsets[xfeature_idx] : NULL;
> }
I would really have expected an ASSERT() to get added as
(documenting) replacement.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 3/9] x86/head: Move early exception panic code into early_fixup_exception
On Mon, Apr 04, 2016 at 08:32:21AM -0700, Andy Lutomirski wrote: > Adding locking would be easy enough, wouldn't it? See patch in this thread.. > But do any platforms really boot a second CPU before switching to real > printk? I _only_ use early_printk() as printk() is a quagmire of fail :-) ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2] x86/hvm: separate ioreq server code from generic hvm code
On 04/01/2016 03:54 AM, Paul Durrant wrote: The code in hvm/hvm.c related to handling I/O emulation using the ioreq server framework is large and mostly self-contained. This patch separates the ioreq server code into a new hvm/ioreq.c source module and accompanying asm-x86/hvm/ioreq.h header file. There is no intended functional change, only code movement. This may be more than just code movement. It breaks PVH. I haven't looked at what exactly is breaking but I figured I'd give a heads-up. -boris (XEN) [ Xen-4.7-unstable x86_64 debug=y Tainted:C ] (XEN) CPU:2 (XEN) RIP:e008:[] handle_hvm_io_completion+0x1bb/0x288 (XEN) RFLAGS: 00010286 CONTEXT: hypervisor (d1v0) (XEN) rax: 8302453b8000 rbx: 8300a56e3000 rcx: 8302453bffc0 (XEN) rdx: 83024da8b000 rsi: 82d080326280 rdi: 8300a56e3000 (XEN) rbp: 8302453bfd80 rsp: 8302453bfc20 r8: 830247180ed0 (XEN) r9: ff21 r10: deadbeef r11: 0246 (XEN) r12: 8300a56e3000 r13: r14: 83024da8b250 (XEN) r15: 8302453f3000 cr0: 8005003b cr4: 001526e0 (XEN) cr3: 00024db49000 cr2: (XEN) ds: 002b es: 002b fs: gs: ss: e010 cs: e008 (XEN) Xen code around (handle_hvm_io_completion+0x1bb/0x288): (XEN) 00 94 fe ff ff 4d 8b 6d <00> 8b 45 00 0f 18 08 4d 39 f5 0f 85 73 fe ff ff (XEN) Xen stack trace from rsp=8302453bfc20: (XEN)8302453b8000 8302453bfc30 (XEN) 8302453bfc88 001526e0 8302453bfc88 (XEN)0046 8300a573d000 0002 8302453f3000 (XEN)8300a29fe000 8302453bfc98 82d080178ad1 8302453bfcf8 (XEN)82d0801659e1 8302453bff18 8302453b8000 efff0002453bfcd8 (XEN)8302453a9000 0046 0082 (XEN)00fd 005077eb2c26 8302453bfd10 (XEN)82d080197ced 8300a56e3000 8302453bfd60 001526e0 (XEN)8302453bfd50 0046 83009f7e7020 83024da8b000 (XEN)8300a56e3000 8302453bfdb0 8300a56e3000 (XEN)8300a573d000 83024da8b000 0002 8302453f3000 (XEN)8302453bfda0 82d0801d4496 8300a56e3000 8300a573d000 (XEN)8302453bfdc0 82d0801f49ee 8302453bfdc0 8300a56e3000 (XEN)8302453bfe20 82d08016a952 (XEN) 8302453bfe20 8300a573d000 (XEN)00507862cc3e 8300a56e3000 830247180128 0001 (XEN)8302453bfeb0 82d08012c50f 92dd98770002 830247180140 (XEN)0002003bfe60 830247180120 8302453bfe60 82d080130034 (XEN)8302453bfeb0 8300a56e3000 01c9c380 82d0801bed01 (XEN)8300a573d000 82d080312b00 82d080312a00 (XEN) Xen call trace: (XEN)[] handle_hvm_io_completion+0x1bb/0x288 (XEN)[] hvm_do_resume+0x35/0x14b (XEN)[] vmx_do_resume+0x12c/0x143 (XEN)[] context_switch+0xf4a/0xf4c (XEN)[] schedule.c#schedule+0x5a5/0x5d7 (XEN)[] softirq.c#__do_softirq+0x82/0x8d (XEN)[] do_softirq+0x13/0x15 (XEN)[] domain.c#idle_loop+0x5e/0x6e (XEN) (XEN) Pagetable walk from : (XEN) L4[0x000] = (XEN) (XEN) (XEN) Panic on CPU 2: (XEN) FATAL PAGE FAULT (XEN) [error_code=] (XEN) Faulting linear address: ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Intel MID / CE4100 - platform support - pnpbios support ?
On 03/31/16 13:03, Luis R. Rodriguez wrote: > Andy S, Peter, Thomas, Jiang (or who might know), > > Do Intel MID platforms exist with PNP BIOS support? What abot CE4100? > As it stands I don't see anything that would prevent this but I would > suspect a possibility might be that it doesn't. I'm sanitizing some > early boot code right now and pnpbios is one, and as I work on this, > this has come up as a question for me. > The "MID" platforms from a Linux platform perspective are the ones with SFI and DT bootloaders, respectively; by definition they don't have standard BIOS. -hpa ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V2 0/9] xentrace/xenalyze support on ARM
On 04/04/16 16:50, Ben Sanda wrote: > Julien and Wei, > >>> You patches all have the same subject line. Please make them more >>> specific. See my reply to #1 for example. >> +1 >> >> Also, you should at least check that Xen still builds after applying >> each patch. Ideally, you also need to be careful to not break any >> feature currently supported. It's useful when someone needs to >> bisect the tree. >> >> For instance, you use the function get_pg_owner for ARM in patch #2 >> but introduce the function in patch #4. This will break ARM build. >> So the patch #2 should be moved after #4. >> >> Furthermore, you remove the functions get_pg_owner and put_pg_owner >> for x86 in patch #3 and then re-introduced them in patch #4. >> Therefore, the x86 will be broken after #3. In this case, it's better >> to have a patch that move the 2 functions from x86 to common. > Thank you for the comments. I apologize for the errors in the patch > format. This is my first time submitting a patch to Xen and I was > unaware that the patch set order mattered or that I had to account for > a piecewise application of the patch set. I will attempt to resubmit > with this corrected and the patch names updated. > > So then it is permissible to have multiple file changes in one > patch/commit? E.g. a patch that removes from one file and adds to > another in the same commit. I initially thought each patch/ commit was > only supposed to modify one file and that's why I did it that way One logical change per patch (wherever possible). It is fine to change more than one file in a patch. In particular, your patches 3 though 5 are one logical change, "move get_pg_owner() from being x86-specific to being common". It is an absolute must that each invidiual patch compiles and doesn't regress functionality, so the resulting patches can be bisected in the case of an error being introduced. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [hypervisor deadlock] Re: [PATCH v9 for Xen 4.7 1/4] xen: enable per-VCPU parameter for RTDS
On 04/04/16 16:58, Chong Li wrote:
> On Mon, Apr 4, 2016 at 10:14 AM, Andrew Cooper
> wrote:
>> On 01/04/16 05:59, Chong Li wrote:
>>> diff --git a/xen/common/sched_credit.c b/xen/common/sched_credit.c
>>> index 305889a..e5d15d8 100644
>>> --- a/xen/common/sched_credit.c
>>> +++ b/xen/common/sched_credit.c
>>> @@ -1080,15 +1080,13 @@ csched_dom_cntl(
>>> * lock. Runq lock not needed anywhere in here. */
>>> spin_lock_irqsave(&prv->lock, flags);
>>>
>>> -if ( op->cmd == XEN_DOMCTL_SCHEDOP_getinfo )
>>> +switch ( op->cmd )
>>> {
>>> +case XEN_DOMCTL_SCHEDOP_getinfo:
>>> op->u.credit.weight = sdom->weight;
>>> op->u.credit.cap = sdom->cap;
>>> -}
>>> -else
>>> -{
>>> -ASSERT(op->cmd == XEN_DOMCTL_SCHEDOP_putinfo);
>>> -
>>> +break;
>>> +case XEN_DOMCTL_SCHEDOP_putinfo:
>>> if ( op->u.credit.weight != 0 )
>>> {
>>> if ( !list_empty(&sdom->active_sdom_elem) )
>>> @@ -1101,7 +1099,9 @@ csched_dom_cntl(
>>>
>>> if ( op->u.credit.cap != (uint16_t)~0U )
>>> sdom->cap = op->u.credit.cap;
>>> -
>>> +break;
>>> +default:
>>> +return -EINVAL;
>>
>> This path returns without unlocking prv->lock.
>>
>>> }
>>>
>>> spin_unlock_irqrestore(&prv->lock, flags);
>>> diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
>>> index 7ddad38..d48ed5a 100644
>>> --- a/xen/common/sched_credit2.c
>>> +++ b/xen/common/sched_credit2.c
>>> @@ -1421,14 +1421,12 @@ csched2_dom_cntl(
>>> * runq lock to update csvcs. */
>>> spin_lock_irqsave(&prv->lock, flags);
>>>
>>> -if ( op->cmd == XEN_DOMCTL_SCHEDOP_getinfo )
>>> +switch ( op->cmd )
>>> {
>>> +case XEN_DOMCTL_SCHEDOP_getinfo:
>>> op->u.credit2.weight = sdom->weight;
>>> -}
>>> -else
>>> -{
>>> -ASSERT(op->cmd == XEN_DOMCTL_SCHEDOP_putinfo);
>>> -
>>> +break;
>>> +case XEN_DOMCTL_SCHEDOP_putinfo:
>>> if ( op->u.credit2.weight != 0 )
>>> {
>>> struct vcpu *v;
>>> @@ -1457,6 +1455,9 @@ csched2_dom_cntl(
>>> vcpu_schedule_unlock(lock, svc->vcpu);
>>> }
>>> }
>>> +break;
>>> +default:
>>> +return -EINVAL;
>>
>> As does this.
>>
>> Please submit a bugfix ASAP. This will become a security vulnerability
>> if Xen 4.7 is shipped without it being fixed.
>>
>>> }
>>>
>>> spin_unlock_irqrestore(&prv->lock, flags);
>>
> Thanks for pointing this out.
>
> Dario, do you want to include this bugfix in your cleanup patch, or
> let me submit this?
If you're around and can test it, it's probably better if you can send a
patch right a way.
Thanks,
-George
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] x86/extable: Add a comment about early exception handlers
On Mon, Apr 04, 2016 at 08:46:22AM -0700, Andy Lutomirski wrote: > Borislav asked for a comment explaining why all exception handlers are > allowed early. > > Signed-off-by: Andy Lutomirski > --- > arch/x86/mm/extable.c | 14 ++ > 1 file changed, 14 insertions(+) > > diff --git a/arch/x86/mm/extable.c b/arch/x86/mm/extable.c > index 98b5f45d9d79..36fe03bc81ee 100644 > --- a/arch/x86/mm/extable.c > +++ b/arch/x86/mm/extable.c > @@ -132,6 +132,20 @@ void __init early_fixup_exception(struct pt_regs *regs, > int trapnr) > if (regs->cs != __KERNEL_CS) > goto fail; > > + /* > + * The full exception fixup machinery is available as soon as > + * the early IDT is loaded. This means that it is the > + * responsibility of extable users to either function correctly > + * when handlers are invoked early or to simply avoid causing > + * exceptions before they're ready to handle them. > + * > + * This is better than filtering which handlers can be used, > + * because refusing to call a handler here is guaranteed to > + * result in a hard-to-debug panic. > + * > + * Keep in mind that not all vectors actually get here. Early > + * fage faults, for example, are special. > + */ > if (fixup_exception(regs, trapnr)) > return; > > -- Thanks! Reviewed-by: Borislav Petkov -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen: Add comment for missing FROZEN notifier transitions
(CC Stefano new e-mail address)
Hello Anna-Maria,
On 04/04/2016 13:32, Anna-Maria Gleixner wrote:
Xen guests do not offline/online CPUs during suspend/resume and
therefore FROZEN notifier transitions are not required. Add this
explanation as a comment in the code to get not confused why
CPU_TASKS_FROZEN masked transitions are not considered.
Cc: David Vrabel
Cc: Stefano Stabellini
Cc: xen-de...@lists.xenproject.org
Signed-off-by: Anna-Maria Gleixner
---
arch/arm/xen/enlighten.c |6 ++
arch/x86/xen/enlighten.c |7 +++
drivers/xen/events/events_fifo.c |6 ++
3 files changed, 19 insertions(+)
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -213,6 +213,12 @@ static int xen_cpu_notification(struct n
unsigned long action,
void *hcpu)
{
+ /*
+* Xen guests do not offline/online CPUs during
+* suspend/resume, thus CPU_TASKS_FROZEN masked transitions
+* are not considered.
+*/
+
switch (action) {
case CPU_STARTING:
xen_percpu_init();
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -1788,6 +1788,13 @@ static int xen_hvm_cpu_notify(struct not
void *hcpu)
{
int cpu = (long)hcpu;
+
+ /*
+* Xen guests do not offline/online CPUs during
+* suspend/resume, thus CPU_TASKS_FROZEN masked transitions
+* are not considered.
+*/
+
switch (action) {
case CPU_UP_PREPARE:
xen_vcpu_setup(cpu);
--- a/drivers/xen/events/events_fifo.c
+++ b/drivers/xen/events/events_fifo.c
@@ -425,6 +425,12 @@ static int evtchn_fifo_cpu_notification(
int cpu = (long)hcpu;
int ret = 0;
+ /*
+* Xen guests do not offline/online CPUs during
+* suspend/resume, thus CPU_TASKS_FROZEN masked transitions
+* are not considered.
+ */
NIT: The '*' is not aligned with the others.
+
switch (action) {
case CPU_UP_PREPARE:
if (!per_cpu(cpu_control_block, cpu))
Regards,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 0/9] Improve non-"safe" MSR access failure handling
On Sat, Apr 02, 2016 at 07:01:31AM -0700, Andy Lutomirski wrote: > There are two parts here: > > * FIRST PART: EARLY EXCEPTIONS * > > The first few patches move some early panic code into C, add pt_regs > to early exception handling, and make fancy exception handlers work early. > > * SECOND PART: MSRs * > > Setting CONFIG_PARAVIRT=y has an unintended side effect: it silently > turns all rdmsr and wrmsr operations into the safe variants without > any checks that the operations actually succeed. ... FWIW: Reviewed-by: Borislav Petkov Definitely a step in the right direction, regardless of how we're going to be doing early_printk(), which is a tangential topic. This pile could be taken for a spin in tip. -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] libxl gentypes.pl "saved_FOO" oddity
On Mon, Apr 04, 2016 at 03:57:02PM +0100, Ian Jackson wrote:
> Coverity is complaining (eg, CID 1358114) about this code in
> _libxl_types.c:
>
> *** CID 1358114: Code maintainability issues (UNUSED_VALUE)
> /tools/libxl/_libxl_types.c: 11035 in libxl__device_usbdev_parse_json()
> 11029 x = libxl__json_map_get("hostaddr", x, JSON_INTEGER);
> 11030 if (x) {
> 11031 rc = libxl__uint8_parse_json(gc, x, &p->u.hostdev.hostaddr);
> 11032 if (rc)
> 11033 goto out;
> 11034 }
> >>> CID 1358114: Code maintainability issues (UNUSED_VALUE)
> >>> Assigning value from "saved_hostaddr" to "x" here, but that stored
> vale is overwritten before it can be used.
> 11035 x = saved_hostaddr;
>
> This does seem rather odd. I wasn't able to find any occurrences of
> `x' outside these save/restore regions. So x is saved and restored
> for no particular reason.
>
> The root cause seems to be the reuse of x by both inner and outer
> autogenerated code, where the generator may not know what is to be
> inserted. Why not have a separate variable for each
> libxl__json_map_get ?
>
> This code is generated by gentypes.py, near line 438. It was written
> by Ian Campbell in 2010 and doesn't seem to have been much touched
> since.
>
Actually I wrote that snippet back then. Maybe at the time I meant to
use `x' as a pointer of the node being processed for no particular
reason.
> Opinions welcome. In particular, should I attempt a patch to make
> this code less odd-looking ?
>
Sure. I don't object to this.
Wei.
> Thanks,
> Ian.
>
> (CCing Wei who seems from git log like the only person who might have
> a view.)
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [linux-mingo-tip-master test] 88622: regressions - FAIL
flight 88622 linux-mingo-tip-master real [real] http://logs.test-lab.xenproject.org/osstest/logs/88622/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-rumpuserxen 6 xen-build fail REGR. vs. 60684 build-amd64-pvops 5 kernel-build fail REGR. vs. 60684 build-i386-pvops 5 kernel-build fail REGR. vs. 60684 build-i386-rumpuserxen6 xen-build fail REGR. vs. 60684 Tests which did not succeed, but are not blocking: test-amd64-i386-rumpuserxen-i386 1 build-check(1) blocked n/a test-amd64-amd64-rumpuserxen-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvh-intel 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvh-amd 1 build-check(1) blocked n/a test-amd64-amd64-xl-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-i386-xl1 build-check(1) blocked n/a test-amd64-amd64-xl-multivcpu 1 build-check(1) blocked n/a test-amd64-amd64-xl 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-i386-xl-xsm1 build-check(1) blocked n/a test-amd64-amd64-xl-credit2 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-rtds 1 build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-amd64-pygrub 1 build-check(1) blocked n/a test-amd64-amd64-amd64-pvgrub 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-intel 1 build-check(1) blocked n/a test-amd64-amd64-i386-pvgrub 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-pair 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-i386 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-amd64 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-amd 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-pair 1 build-check(1) blocked n/a test-amd64-i386-xl-raw1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-debianhvm-amd64 1 build-check(1)blocked n/a test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 1 build-check(1)blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 1 build-check(1)blocked n/a test-amd64-amd64-xl-qcow2 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1)blocked n/a test-amd64-i386-xl-qemut-winxpsp3-vcpus1 1 build-check(1) blocked n/a test-amd64-amd64-pair 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-winxpsp3 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-winxpsp3 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-winxpsp3 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-winxpsp3 1 build-ch
Re: [Xen-devel] [PATCH] xen: Add comment for missing FROZEN notifier transitions
On 04/04/16 17:21, Julien Grall wrote: > (CC Stefano new e-mail address) > > Hello Anna-Maria, > > On 04/04/2016 13:32, Anna-Maria Gleixner wrote: >> Xen guests do not offline/online CPUs during suspend/resume and >> therefore FROZEN notifier transitions are not required. Add this >> explanation as a comment in the code to get not confused why >> CPU_TASKS_FROZEN masked transitions are not considered. Alternatively, these could be added even if they are not encountered. This might be more future-proof but the documentation might be clearer. Boris, Juergen, any opinion? David>> --- a/drivers/xen/events/events_fifo.c >> +++ b/drivers/xen/events/events_fifo.c >> @@ -425,6 +425,12 @@ static int evtchn_fifo_cpu_notification( >> int cpu = (long)hcpu; >> int ret = 0; >> >> +/* >> + * Xen guests do not offline/online CPUs during >> + * suspend/resume, thus CPU_TASKS_FROZEN masked transitions >> + * are not considered. >> +*/ > > NIT: The '*' is not aligned with the others. If this doesn't need any other changes, I'll fix this on commit. David ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 7/9] x86/paravirt: Add paravirt_{read, write}_msr
On 02/04/16 15:01, Andy Lutomirski wrote:
> This adds paravirt hooks for unsafe MSR access. On native, they
> call native_{read,write}_msr. On Xen, they use
> xen_{read,write}_msr_safe.
>
> Nothing uses them yet for ease of bisection. The next patch will
> use them in rdmsrl, wrmsrl, etc.
>
> I intentionally didn't make them warn on #GP on Xen. I think that
> should be done separately by the Xen maintainers.
...
> --- a/arch/x86/xen/enlighten.c
> +++ b/arch/x86/xen/enlighten.c
Reviewed-by: David Vrabel
> @@ -1092,6 +1092,26 @@ static int xen_write_msr_safe(unsigned int msr,
> unsigned low, unsigned high)
> return ret;
> }
>
> +static u64 xen_read_msr(unsigned int msr)
> +{
> + /*
> + * This will silently swallow a #GP from RDMSR. It may be worth
> + * changing that.
This probably isn't important.
David
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [hypervisor deadlock] Re: [PATCH v9 for Xen 4.7 1/4] xen: enable per-VCPU parameter for RTDS
On Mon, 2016-04-04 at 17:05 +0100, George Dunlap wrote:
> On 04/04/16 16:58, Chong Li wrote:
> > On Mon, Apr 4, 2016 at 10:14 AM, Andrew Cooper
> > wrote:
> > > On 01/04/16 05:59, Chong Li wrote:
> > > >
> > > > --- a/xen/common/sched_credit2.c
> > > > +++ b/xen/common/sched_credit2.c
> > > > @@ -1421,14 +1421,12 @@ csched2_dom_cntl(
> > > > * runq lock to update csvcs. */
> > > > spin_lock_irqsave(&prv->lock, flags);
> > > >
> > > > -if ( op->cmd == XEN_DOMCTL_SCHEDOP_getinfo )
> > > > +switch ( op->cmd )
> > > > {
> > > > +case XEN_DOMCTL_SCHEDOP_getinfo:
> > > > op->u.credit2.weight = sdom->weight;
> > > > -}
> > > > -else
> > > > -{
> > > > -ASSERT(op->cmd == XEN_DOMCTL_SCHEDOP_putinfo);
> > > > -
> > > > +break;
> > > > +case XEN_DOMCTL_SCHEDOP_putinfo:
> > > > if ( op->u.credit2.weight != 0 )
> > > > {
> > > > struct vcpu *v;
> > > > @@ -1457,6 +1455,9 @@ csched2_dom_cntl(
> > > > vcpu_schedule_unlock(lock, svc->vcpu);
> > > > }
> > > > }
> > > > +break;
> > > > +default:
> > > > +return -EINVAL;
> > > As does this.
> > >
> > > Please submit a bugfix ASAP. This will become a security
> > > vulnerability
> > > if Xen 4.7 is shipped without it being fixed.
> > >
> > > >
> > > > }
> > > >
> > > > spin_unlock_irqrestore(&prv->lock, flags);
> > Thanks for pointing this out.
> >
> > Dario, do you want to include this bugfix in your cleanup patch, or
> > let me submit this?
> If you're around and can test it, it's probably better if you can
> send a
> patch right a way.
>
Exactly. In fact:
- we don't fold bugfixes in clanups,
- I think I mentioned wanting to cleanup some code duplication in
libxl, this is in xen,
- cleanups are delayed to 4.8, while this must be fixed before
release (or the patch/the whole feature be reverted).
So, if you can't work out a fix today or, at most, tomorrow, let me
know and I'll do it myself.
Sorry for not catching this during review... :-/
Regards,
Dario
--
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
signature.asc
Description: This is a digitally signed message part
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 7/9] x86/paravirt: Add paravirt_{read, write}_msr
On Mon, Apr 4, 2016 at 9:33 AM, David Vrabel wrote:
> On 02/04/16 15:01, Andy Lutomirski wrote:
>> This adds paravirt hooks for unsafe MSR access. On native, they
>> call native_{read,write}_msr. On Xen, they use
>> xen_{read,write}_msr_safe.
>>
>> Nothing uses them yet for ease of bisection. The next patch will
>> use them in rdmsrl, wrmsrl, etc.
>>
>> I intentionally didn't make them warn on #GP on Xen. I think that
>> should be done separately by the Xen maintainers.
> ...
>> --- a/arch/x86/xen/enlighten.c
>> +++ b/arch/x86/xen/enlighten.c
>
> Reviewed-by: David Vrabel
>
>> @@ -1092,6 +1092,26 @@ static int xen_write_msr_safe(unsigned int msr,
>> unsigned low, unsigned high)
>> return ret;
>> }
>>
>> +static u64 xen_read_msr(unsigned int msr)
>> +{
>> + /*
>> + * This will silently swallow a #GP from RDMSR. It may be worth
>> + * changing that.
>
> This probably isn't important.
>
It might be nice to do a WARN_ON_ONCE like this series does for the
native case to help shake out latent bugs.
--Andy
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [hypervisor deadlock] Re: [PATCH v9 for Xen 4.7 1/4] xen: enable per-VCPU parameter for RTDS
On Mon, Apr 04, 2016 at 06:32:48PM +0200, Dario Faggioli wrote:
> On Mon, 2016-04-04 at 17:05 +0100, George Dunlap wrote:
> > On 04/04/16 16:58, Chong Li wrote:
> > > On Mon, Apr 4, 2016 at 10:14 AM, Andrew Cooper
> > > wrote:
> > > > On 01/04/16 05:59, Chong Li wrote:
> > > > >
> > > > > --- a/xen/common/sched_credit2.c
> > > > > +++ b/xen/common/sched_credit2.c
> > > > > @@ -1421,14 +1421,12 @@ csched2_dom_cntl(
> > > > > * runq lock to update csvcs. */
> > > > > spin_lock_irqsave(&prv->lock, flags);
> > > > >
> > > > > -if ( op->cmd == XEN_DOMCTL_SCHEDOP_getinfo )
> > > > > +switch ( op->cmd )
> > > > > {
> > > > > +case XEN_DOMCTL_SCHEDOP_getinfo:
> > > > > op->u.credit2.weight = sdom->weight;
> > > > > -}
> > > > > -else
> > > > > -{
> > > > > -ASSERT(op->cmd == XEN_DOMCTL_SCHEDOP_putinfo);
> > > > > -
> > > > > +break;
> > > > > +case XEN_DOMCTL_SCHEDOP_putinfo:
> > > > > if ( op->u.credit2.weight != 0 )
> > > > > {
> > > > > struct vcpu *v;
> > > > > @@ -1457,6 +1455,9 @@ csched2_dom_cntl(
> > > > > vcpu_schedule_unlock(lock, svc->vcpu);
> > > > > }
> > > > > }
> > > > > +break;
> > > > > +default:
> > > > > +return -EINVAL;
> > > > As does this.
> > > >
> > > > Please submit a bugfix ASAP. This will become a security
> > > > vulnerability
> > > > if Xen 4.7 is shipped without it being fixed.
> > > >
> > > > >
> > > > > }
> > > > >
> > > > > spin_unlock_irqrestore(&prv->lock, flags);
> > > Thanks for pointing this out.
> > >
> > > Dario, do you want to include this bugfix in your cleanup patch, or
> > > let me submit this?
> > If you're around and can test it, it's probably better if you can
> > send a
> > patch right a way.
> >
> Exactly. In fact:
> - we don't fold bugfixes in clanups,
> - I think I mentioned wanting to cleanup some code duplication in
> libxl, this is in xen,
> - cleanups are delayed to 4.8, while this must be fixed before
> release (or the patch/the whole feature be reverted).
>
> So, if you can't work out a fix today or, at most, tomorrow, let me
> know and I'll do it myself.
>
Yes, please fix this by tomorrow. I think it is quite straightforward to
fix anyway.
Wei.
> Sorry for not catching this during review... :-/
>
> Regards,
> Dario
> --
> <> (Raistlin Majere)
> -
> Dario Faggioli, Ph.D, http://about.me/dario.faggioli
> Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen: Add comment for missing FROZEN notifier transitions
On 04/04/2016 12:30 PM, David Vrabel wrote: On 04/04/16 17:21, Julien Grall wrote: (CC Stefano new e-mail address) Hello Anna-Maria, On 04/04/2016 13:32, Anna-Maria Gleixner wrote: Xen guests do not offline/online CPUs during suspend/resume and therefore FROZEN notifier transitions are not required. Add this explanation as a comment in the code to get not confused why CPU_TASKS_FROZEN masked transitions are not considered. Alternatively, these could be added even if they are not encountered. This might be more future-proof but the documentation might be clearer. Boris, Juergen, any opinion? Wouldn't the same comment need to be added to xen_hvm_cpu_notify()? -boris David>> --- a/drivers/xen/events/events_fifo.c +++ b/drivers/xen/events/events_fifo.c @@ -425,6 +425,12 @@ static int evtchn_fifo_cpu_notification( int cpu = (long)hcpu; int ret = 0; +/* + * Xen guests do not offline/online CPUs during + * suspend/resume, thus CPU_TASKS_FROZEN masked transitions + * are not considered. +*/ NIT: The '*' is not aligned with the others. If this doesn't need any other changes, I'll fix this on commit. David ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] Policy for force pushing smoke branch Was: Re: [xen-unstable-smoke test] 88656: regressions - FAIL [and 1 more messages]
Ian Jackson writes ("Policy for force pushing smoke branch Was: Re: [Xen-devel]
[xen-unstable-smoke test] 88656: regressions - FAIL"):
> Wei Liu writes ("Policy for force pushing smoke branch Was: Re: [Xen-devel]
> [xen-unstable-smoke test] 88656: regressions - FAIL"):
> > It would take some time for libvirt fix to land and propagate to our own
> > mirror.
>
> There is also a risk that the libvirt fix wouldn't pass osstest's push
> gate for the libvirt branch.
>
> > I would like to avoid holding backing xen.git push for too long
> > if possible. So I'm for force-pushing the smoke branch and subsequently
> > master branch if necessary.
>
> I concur. I will wait a bit for contrary opinions, though.
I have now pushed a0f793d82d5ec2d0b67c57d7130bf01c91396c60 to smoke,
apropos of:
osstest service owner writes ("[xen-unstable-smoke test] 88672: regressions -
FAIL"):
> flight 88672 xen-unstable-smoke real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/88672/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> build-amd64-libvirt 5 libvirt-build fail REGR. vs.
> 88144
>
> version targeted for testing:
> xen a0f793d82d5ec2d0b67c57d7130bf01c91396c60
I'll do a force push to xen.git#master if this is the only blocker,
too. Also, any necessary force push of the osstest tested libvirt
branch.
Thanks,
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v13 03/26] tools/libxl: Add back channel to allow migration target send data back
Olaf Hering writes ("Re: [Xen-devel] [PATCH v13 03/26] tools/libxl: Add back
channel to allow migration target send data back"):
> On Mon, Apr 04, Wei Liu wrote:
> > The fix is to patch libvirt. Looking at libvirt code I think I need to
> > patch Makefile.in to pass in an explicit LIBXL_API_VERSION number.
>
> That might be true.
>
> But shouldnt at the same time libxl.h get a change to recognize
> 0x040700? Perhaps this will be part of the release management.
It is on the release checklist. But perhaps we should do it now.
Patch welcome :-).
Thanks,
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 5/9] libxl: Rearrange qemu upstream disk argument code
George Dunlap writes ("Re: [PATCH v3 5/9] libxl: Rearrange qemu upstream disk
argument code"):
> I looked through the patch in the branch provided in your reply to 0/9
> [1], and it looks correct; morever, I tested it and it and the basic
> functionality (using the "dummy" block script) still works.
>
> Reviewed-by: George Dunlap
> Tested-by: George Dunlap
>
> [1] git://xenbits.xenproject.org/people/iwj/xen.git wip.gwd.hotplug-v3.1
Thanks, I have pushed it (rebased) to staging.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 5/9] libxl: Rearrange qemu upstream disk argument code
On 04/04/16 17:59, Ian Jackson wrote:
> George Dunlap writes ("Re: [PATCH v3 5/9] libxl: Rearrange qemu upstream disk
> argument code"):
>> I looked through the patch in the branch provided in your reply to 0/9
>> [1], and it looks correct; morever, I tested it and it and the basic
>> functionality (using the "dummy" block script) still works.
>>
>> Reviewed-by: George Dunlap
>> Tested-by: George Dunlap
>>
>> [1] git://xenbits.xenproject.org/people/iwj/xen.git wip.gwd.hotplug-v3.1
> Thanks, I have pushed it (rebased) to staging.
New build failure on CentOS 7
libxl_dm.c: In function 'libxl__build_device_model_args':
libxl_dm.c:1374:27: error: 'target_path' may be used uninitialized in
this function [-Werror=maybe-uninitialized]
drive = libxl__sprintf(gc, "%s,file=%s,format=%s",
^
libxl_dm.c:1310:25: note: 'target_path' was declared here
const char *target_path;
^
cc1: all warnings being treated as errors
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] XSM permissive by default.
Konrad Rzeszutek Wilk writes ("Re: [Xen-devel] XSM permissive by default."):
> I presume this patch would be to folks +1:
>
> From 3373a50f386b41eea6ecede4b430e4fa09b2fe7e Mon Sep 17 00:00:00 2001
> From: Konrad Rzeszutek Wilk
> Date: Thu, 10 Mar 2016 12:05:29 -0500
> Subject: [PATCH] flask: By default be in FLASK_BOOTPARAM_ENFORCING mode.
This has a Reviewed-by from Doug Goldstein and Andrew Cooper. And
then it was revised by Daniel. But AFAICT it has not yet been
committed. I think this is an important change that is in 4.7.
Is there some reason why this patch hasn't been committed ?
Thanks,
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 5/9] libxl: Rearrange qemu upstream disk argument code
On 04/04/16 18:11, Andrew Cooper wrote:
> On 04/04/16 17:59, Ian Jackson wrote:
>> George Dunlap writes ("Re: [PATCH v3 5/9] libxl: Rearrange qemu upstream
>> disk argument code"):
>>> I looked through the patch in the branch provided in your reply to 0/9
>>> [1], and it looks correct; morever, I tested it and it and the basic
>>> functionality (using the "dummy" block script) still works.
>>>
>>> Reviewed-by: George Dunlap
>>> Tested-by: George Dunlap
>>>
>>> [1] git://xenbits.xenproject.org/people/iwj/xen.git wip.gwd.hotplug-v3.1
>> Thanks, I have pushed it (rebased) to staging.
> New build failure on CentOS 7
>
> libxl_dm.c: In function 'libxl__build_device_model_args':
> libxl_dm.c:1374:27: error: 'target_path' may be used uninitialized in
> this function [-Werror=maybe-uninitialized]
> drive = libxl__sprintf(gc, "%s,file=%s,format=%s",
>^
> libxl_dm.c:1310:25: note: 'target_path' was declared here
> const char *target_path;
> ^
> cc1: all warnings being treated as errors
Sorry - sent too early. Specifically, target_path is genuinely
uninitialised in the case that there is an empty CDROM specified.
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [hypervisor deadlock] Re: [PATCH v9 for Xen 4.7 1/4] xen: enable per-VCPU parameter for RTDS
On Mon, Apr 4, 2016 at 11:47 AM, Wei Liu wrote:
> On Mon, Apr 04, 2016 at 06:32:48PM +0200, Dario Faggioli wrote:
>> On Mon, 2016-04-04 at 17:05 +0100, George Dunlap wrote:
>> > On 04/04/16 16:58, Chong Li wrote:
>> > > On Mon, Apr 4, 2016 at 10:14 AM, Andrew Cooper
>> > > wrote:
>> > > > On 01/04/16 05:59, Chong Li wrote:
>> > > > >
>> > > > > --- a/xen/common/sched_credit2.c
>> > > > > +++ b/xen/common/sched_credit2.c
>> > > > > @@ -1421,14 +1421,12 @@ csched2_dom_cntl(
>> > > > > * runq lock to update csvcs. */
>> > > > > spin_lock_irqsave(&prv->lock, flags);
>> > > > >
>> > > > > -if ( op->cmd == XEN_DOMCTL_SCHEDOP_getinfo )
>> > > > > +switch ( op->cmd )
>> > > > > {
>> > > > > +case XEN_DOMCTL_SCHEDOP_getinfo:
>> > > > > op->u.credit2.weight = sdom->weight;
>> > > > > -}
>> > > > > -else
>> > > > > -{
>> > > > > -ASSERT(op->cmd == XEN_DOMCTL_SCHEDOP_putinfo);
>> > > > > -
>> > > > > +break;
>> > > > > +case XEN_DOMCTL_SCHEDOP_putinfo:
>> > > > > if ( op->u.credit2.weight != 0 )
>> > > > > {
>> > > > > struct vcpu *v;
>> > > > > @@ -1457,6 +1455,9 @@ csched2_dom_cntl(
>> > > > > vcpu_schedule_unlock(lock, svc->vcpu);
>> > > > > }
>> > > > > }
>> > > > > +break;
>> > > > > +default:
>> > > > > +return -EINVAL;
>> > > > As does this.
>> > > >
>> > > > Please submit a bugfix ASAP. This will become a security
>> > > > vulnerability
>> > > > if Xen 4.7 is shipped without it being fixed.
>> > > >
>> > > > >
>> > > > > }
>> > > > >
>> > > > > spin_unlock_irqrestore(&prv->lock, flags);
>> > > Thanks for pointing this out.
>> > >
>> > > Dario, do you want to include this bugfix in your cleanup patch, or
>> > > let me submit this?
>> > If you're around and can test it, it's probably better if you can
>> > send a
>> > patch right a way.
>> >
>> Exactly. In fact:
>> - we don't fold bugfixes in clanups,
>> - I think I mentioned wanting to cleanup some code duplication in
>>libxl, this is in xen,
>> - cleanups are delayed to 4.8, while this must be fixed before
>>release (or the patch/the whole feature be reverted).
>>
>> So, if you can't work out a fix today or, at most, tomorrow, let me
>> know and I'll do it myself.
>>
>
> Yes, please fix this by tomorrow. I think it is quite straightforward to
> fix anyway.
>
> Wei.
>
Will do.
--
Chong Li
Department of Computer Science and Engineering
Washington University in St.louis
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 0/5] COLO fixes
Wei Liu (5): libxc: colo: don't leak pfns and iov in send_checkpoint_dirty_pfn_list libxl: colo: simplify colo_proxy_async_wait_for_checkpoint libxl: colo: add missing break in qemu_disk_scsi_drive_string libxl: colo: fix indentation of abort() libxl: colo: remove dead code in colo_save_setup_script_cb tools/libxc/xc_sr_restore.c | 2 ++ tools/libxl/libxl_colo_nic.c | 5 - tools/libxl/libxl_colo_save.c | 8 tools/libxl/libxl_dm.c| 3 ++- 4 files changed, 8 insertions(+), 10 deletions(-) -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 2/5] libxl: colo: simplify colo_proxy_async_wait_for_checkpoint
Signed-off-by: Wei Liu
---
tools/libxl/libxl_colo_save.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/tools/libxl/libxl_colo_save.c b/tools/libxl/libxl_colo_save.c
index e2fdc4b..26b3afd 100644
--- a/tools/libxl/libxl_colo_save.c
+++ b/tools/libxl/libxl_colo_save.c
@@ -533,11 +533,11 @@ static void
colo_proxy_async_wait_for_checkpoint(libxl__colo_save_state *css)
if (req < 0) {
/* some error happens */
_exit(1);
-} else if (!req) {
-/* no checkpoint is needed, do a checkpoint every 5s */
-_exit(0);
} else {
-/* net packets is not consistent, we need to start a checkpoint */
+/* req == 0: no checkpoint is needed, do a checkpoint every 5s */
+/* req > 0: net packets is not consistent, we need to start a
+ * checkpoint
+ */
_exit(0);
}
}
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
