Re: [Xen-devel] [PATCH] x86/EPT: defer enabling of A/D maintenance until PML get enabled
>>> On 15.10.15 at 08:42, wrote:
> Thanks for your comments Jan. Actually I am not happy with combining
> with EPT A/D bit update with PML enabling to single function. After
> thinking again, how about adding a separate vmx function (ex,
> vmx_domain_update_eptp) to update EPTP of VMCS of all vcpus of domain
> after p2m->ept.ept_ad is updated. Another good is this function can also
> be used in the future for other runtime updates to p2m->ept.
>
> What's your idea?
I don't mind, but that's really more of a question to the VMX maintainers.
> --- a/xen/arch/x86/mm/p2m-ept.c
> +++ b/xen/arch/x86/mm/p2m-ept.c
> @@ -1129,17 +1129,26 @@ void ept_sync_domain(struct p2m_domain *p2m)
>
> static void ept_enable_pml(struct p2m_domain *p2m)
> {
> /*
> - * No need to check if vmx_domain_enable_pml has succeeded or not, as
> + * No need to return if vmx_domain_enable_pml has succeeded or not, as
It seems to me that you'd better use "whether" instead of "if" now
(and then perhaps also drop the "or not").
>* ept_p2m_type_to_flags will do the check, and write protection will be
>* used if PML is not enabled.
>*/
> -vmx_domain_enable_pml(p2m->domain);
> +if ( vmx_domain_enable_pml(p2m->domain) )
> +return;
> +
> +p2m->ept.ept_ad = 1;
> +vmx_domain_update_eptp(p2m->domain);
Shouldn't you enable A/D _before_ enabling PML, at least without
having a domain-is-paused check here?
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [Xen-users] Purpose of mem-max command
On Wed, Oct 14, 2015 at 11:25 AM, David Vrabel wrote: > On 13/10/15 22:14, Daniel Kiper wrote: >> On Tue, Oct 13, 2015 at 11:55:09AM +0100, Ian Campbell wrote: >>> [CCing Daniel] >>> >>> Daniel, please could you advice on which Xen releases, guest types and >>> guest kernel versions are currently expected to work with memory hotplug. >> >> Well... It worked, regardless of guest type, when it was introduced first >> time. >> At that time xend was Xen toolstack. Than xl appeared on the scene and it >> stopped >> working. I tried to fix it but I was diverted to something more important. >> Last >> time David (CC-ed here) fixed some memory hotplug issues in Linux kernel >> (please >> check for-linus-4.4 branch in >> git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git >> for more details). I suppose that he manged to overcome some xl deficiencies >> and >> he will be able to shed some light what he did. If not or his work is not >> upstreamable >> then I leave this on my TODO list. I hope that I will be able to work on >> this next >> year. However, if somebody is up to this work I am able to mentor he/she or >> at >> least review relevant patch series. Here are my old patches for xl: >> http://lists.xen.org/archives/html/xen-devel/2013-04/msg03072.html This is >> really >> old but I think it could be good starting point for further work. > > I think I had to manually fiddle with xenstore keys to persuade xl to > allow mem-max to work as expected. > > David Dear all, Thank you very much for your replies. Basically, AFAIU, hotplug fully worked with the old xen toolstack while it only partially works with the xl toolstack. Spceifically, with the xl toolstack (at least with version 4.4.3), we are currently able to hotplug memory up and down with respect to the statically configured maximum value (property "maxmem"), but we are not able to dynamically increase/decrease the maximum value with "xl mem-max" command. Again, thank you very much for your help and your time. Best, Marco ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [Patch RFC 00/13] VT-d Asynchronous Device-TLB Flush for ATS Device
Jan Beulich wrote on 2015-10-15: On 15.10.15 at 03:03, wrote: >> Jan Beulich wrote on 2015-10-14: >>> As long as the multi-millisecond spins aren't going to go away by >>> other means, I think conversion to async mode is ultimately unavoidable. >> >> I am not fully agreed. I think the time to spin is important. To me, >> less than 1 ms is acceptable and if the hardware can guarantee it, >> then sync mode also is ok. > > Okay, let me put the condition slightly differently - any spin on the > order of what a WBINVD might take ought to be okay, provided both are >From the data we collected, the invalidation is completed within several us. >IMO, the time for WBINVD is varying due the size and different cache >hierarchies. And it may take more than several us in worst case. > equally (in)accessible to guests. The whole discussion is really about > limiting the impact misbehaving guests can have on the whole system. > (Obviously any spin time reaching the order of a scheduling time slice > is a problem.) The premise for a misbehaving guest to impact the system is that the IOMMU is buggy which takes long time to complete the invalidation. In other words, if all invalidations are able to complete within several us, what's the matter to do with the spin time? > >> I remember the origin motivation to handle ATS problem is due to: 1. >> ATS spec allow 60s timeout to completed the flush which Xen only >> allows 1s, and 2. spin loop for 1s is not reasonable since it will >> hurt the scheduler. For the former, as we discussed before, either >> disable ATS support or only support some specific ATS >> devices(complete the flush less than 10ms or 1ms) is acceptable. For >> the latter, if spin loop for 1s is not acceptable, we can reduce the >> timeout to 10ms or 1ms > to eliminate the performance impaction. > > If we really can, why has it been chosen to be 1s in the first place? What I can tell is 1s is just the value the original author chooses. It has no special means. I have double check with our hardware expert and he suggests us to use the value as small as possible. According his comment, 10ms is sufficiently large. > >> Yes, I'd agree it would be best solution if Xen has the async mode. >> But spin loop is used widely in iommu code: not only for >> invalidations, lots of DMAR operations are using spin to sync >> hardware's status. For those operations, it is hard to use async mode. >> Or, even it is possible to use async mode, I don't see the benefit >> considering the cost and complexity which means we either need a >> timer or a > softirq to do the check. > > Even if the cost is high, limited overall throughput by undue spinning > is worth it imo even outside of misbehaving guest considerations. I'm > surprised you're not getting similar pressure on this from the KVM > folks (assuming the use of spinning is similar there). Because no one observe such invalidation timeout issue so far. What we have discussed are only in theory. btw, I have told the issue to Linux IOMMU maintainer but he didn't say anything on it. Best regards, Yang ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Xen 4.6 released
>>> On 15.10.15 at 02:59, wrote: > Wei and Ian, > > Could we merge these following commits into xen-4.6.1? Please don't hijack other threads for backport requests, and please see ./MAINTAINERS of the respective branch for who to send such to. > commit 83215fba3a80c30b5191a4a1086dc510cca43069 > > libxl: introduce libxl__is_igd_vga_passthru > > commit 488508b49a65dda20cf6eb6d8f549e8d758e610f > > libxl: introduce gfx_passthru_kind > > Currently they're already in staging branch. > > I know we're going to sync qemu-upstream into qemu-xen in xen 4.7 to > support IGD passthrough with qemu-xen. But actually only these two > commits can make sure xen-4.6.x work out IGD passthrough with > qemu-upstream, instead of qemu-xen. I mean we can set something like this, > > device_model_version="qemu-xen" > device_model_override="//qemu-system-i386" All of this sounds more like a feature than a bug fix, which normally we wouldn't put into stable releases. Occasionally we make exceptions in x.y.1 releases, but I don't see this justified here so far. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v7 12/32] xen/x86: add bitmap of enabled emulated devices
>>> On 15.10.15 at 03:48, wrote:
> On 10/02/2015 11:48 AM, Roger Pau Monne wrote:
>> --- a/xen/include/public/arch-x86/xen.h
>> +++ b/xen/include/public/arch-x86/xen.h
>> @@ -268,7 +268,28 @@ typedef struct arch_shared_info arch_shared_info_t;
>>* XEN_DOMCTL_INTERFACE_VERSION.
>>*/
>> struct xen_arch_domainconfig {
>> -char dummy;
>> +#define _XEN_X86_EMU_LAPIC 0
>> +#define XEN_X86_EMU_LAPIC (1U<<_XEN_X86_EMU_LAPIC)
>> +#define _XEN_X86_EMU_HPET 1
>> +#define XEN_X86_EMU_HPET(1U<<_XEN_X86_EMU_HPET)
>> +#define _XEN_X86_EMU_PMTIMER2
>> +#define XEN_X86_EMU_PMTIMER (1U<<_XEN_X86_EMU_PMTIMER)
>> +#define _XEN_X86_EMU_RTC3
>> +#define XEN_X86_EMU_RTC (1U<<_XEN_X86_EMU_RTC)
>> +#define _XEN_X86_EMU_IOAPIC 4
>> +#define XEN_X86_EMU_IOAPIC (1U<<_XEN_X86_EMU_IOAPIC)
>> +#define _XEN_X86_EMU_PIC5
>> +#define XEN_X86_EMU_PIC (1U<<_XEN_X86_EMU_PIC)
>> +#define _XEN_X86_EMU_VGA6
>> +#define XEN_X86_EMU_VGA (1U<<_XEN_X86_EMU_VGA)
>> +#define _XEN_X86_EMU_IOMMU 7
>> +#define XEN_X86_EMU_IOMMU (1U<<_XEN_X86_EMU_IOMMU)
>
> What about PIT? Should we (initially) disable it as well?
Definitely - good that you spotted it missing.
Jan
> I (by mistake) enabled it in my guest and crashed the hypervisor due to
> unprotected access to vlapic in pt_update_irq(). I started fixing it but
> then realized that perhaps we shouldn't have PIT at all. Which did solve
> my problems.
>
> (Regardless of whether we have PIT we should probably guard
> vlapic_accept_pit_interrupt() in pit_irq_masked() with has_vlapic())
>
> -boris
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] x86/EPT: defer enabling of A/D maintenance until PML get enabled
On 10/15/2015 03:11 PM, Jan Beulich wrote:
On 15.10.15 at 08:42, wrote:
Thanks for your comments Jan. Actually I am not happy with combining
with EPT A/D bit update with PML enabling to single function. After
thinking again, how about adding a separate vmx function (ex,
vmx_domain_update_eptp) to update EPTP of VMCS of all vcpus of domain
after p2m->ept.ept_ad is updated. Another good is this function can also
be used in the future for other runtime updates to p2m->ept.
What's your idea?
I don't mind, but that's really more of a question to the VMX maintainers.
Then I would prefer this way.
Kevin,
Do you have any comments on this thread?
--- a/xen/arch/x86/mm/p2m-ept.c
+++ b/xen/arch/x86/mm/p2m-ept.c
@@ -1129,17 +1129,26 @@ void ept_sync_domain(struct p2m_domain *p2m)
static void ept_enable_pml(struct p2m_domain *p2m)
{
/*
- * No need to check if vmx_domain_enable_pml has succeeded or not, as
+ * No need to return if vmx_domain_enable_pml has succeeded or not, as
It seems to me that you'd better use "whether" instead of "if" now
(and then perhaps also drop the "or not").
OK. Thanks.
* ept_p2m_type_to_flags will do the check, and write protection will be
* used if PML is not enabled.
*/
-vmx_domain_enable_pml(p2m->domain);
+if ( vmx_domain_enable_pml(p2m->domain) )
+return;
+
+p2m->ept.ept_ad = 1;
+vmx_domain_update_eptp(p2m->domain);
Shouldn't you enable A/D _before_ enabling PML, at least without
having a domain-is-paused check here?
Looks we don't have such function. How about just add
ASSERT(atomic_read(&d->pause_count)), just the same as in
vmx_domain_enable_pml ?
Thanks,
-Kai
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] x86/EPT: defer enabling of A/D maintenance until PML get enabled
On 10/15/2015 03:35 PM, Kai Huang wrote:
On 10/15/2015 03:11 PM, Jan Beulich wrote:
On 15.10.15 at 08:42, wrote:
Thanks for your comments Jan. Actually I am not happy with combining
with EPT A/D bit update with PML enabling to single function. After
thinking again, how about adding a separate vmx function (ex,
vmx_domain_update_eptp) to update EPTP of VMCS of all vcpus of domain
after p2m->ept.ept_ad is updated. Another good is this function can
also
be used in the future for other runtime updates to p2m->ept.
What's your idea?
I don't mind, but that's really more of a question to the VMX
maintainers.
Then I would prefer this way.
Kevin,
Do you have any comments on this thread?
--- a/xen/arch/x86/mm/p2m-ept.c
+++ b/xen/arch/x86/mm/p2m-ept.c
@@ -1129,17 +1129,26 @@ void ept_sync_domain(struct p2m_domain *p2m)
static void ept_enable_pml(struct p2m_domain *p2m)
{
/*
- * No need to check if vmx_domain_enable_pml has succeeded or
not, as
+ * No need to return if vmx_domain_enable_pml has succeeded or
not, as
It seems to me that you'd better use "whether" instead of "if" now
(and then perhaps also drop the "or not").
OK. Thanks.
* ept_p2m_type_to_flags will do the check, and write
protection will be
* used if PML is not enabled.
*/
-vmx_domain_enable_pml(p2m->domain);
+if ( vmx_domain_enable_pml(p2m->domain) )
+return;
+
+p2m->ept.ept_ad = 1;
+vmx_domain_update_eptp(p2m->domain);
Shouldn't you enable A/D _before_ enabling PML, at least without
having a domain-is-paused check here?
Looks we don't have such function. How about just add
ASSERT(atomic_read(&d->pause_count)), just the same as in
vmx_domain_enable_pml ?
I mean we can enable A/D before enabling PML, but if so we need
additional code to clear A/D bit if vmx_domain_enable_pml failed. My
thinking is considering the function is called when domain is paused,
so there's no difference to enable A/D before or after enabling PML.
Thanks,
-Kai
Thanks,
-Kai
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] RFC: Survey on release cycle
>>> On 12.10.15 at 19:32, wrote: > # 6 months release cycle + current stable release scheme > > The same stable release scheme applies (18 months full support + 18 > months security fixes). Encourage more people to step up to share the > maintenance burden if necessary. Automate part of the workflow to > maintain stable releases. Write down guideline for maintainers. -1 (with a tendency towards 0 for the base proposal, i.e. willing to give it a try, but a tendency towards -2 for the sharing of the maintenance burden, as I don't expect much good to come from mixed maintainership of stable branches) > # 6 months release cycle + LTS scheme > > Pick LTS release every 4 releases. Announce LTS before hand. Non-LTS > releases receive shorter support. Encourage more people to step up to > share the maintenance burden if necessary. Automate part of the > workflow to maintain stable releases and LTS releases. Write down > guideline for maintainers. > > The length of support hasn't been discussed thoroughly -- but to make > LTS scheme stand out the length of support would be longer than what > we have now (18 + 18). -1 (with a tendency towards -2, foreseeing non-LTS branches to become "bad children") > # 9 months release cycle + current stable release scheme > > Don't change anything. +1 > # 6 months release cycle + extended security support > > The number of active stable branches remains constant (I think this is > currently 2, implying a reducing from 18 months to 12 months) but the > security support period is extended, such that the final cut off is the > same 36 months (18+18 in the current scheme). So this becomes 12 months of > full support + 24 months of security support. 0 (with a tendency towards -1 when taking on my SUSE hat, as a reduction from 18 to 12 months of ordinary support means an increased amount of patches the various distro versions will have to carry on top of the last stable release from the respective branch) Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [linux-4.1 test] 62963: regressions - FAIL
flight 62963 linux-4.1 real [real] http://logs.test-lab.xenproject.org/osstest/logs/62963/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 15 guest-localmigrate.2 fail in 62951 REGR. vs. 62318 Tests which are failing intermittently (not blocking): test-amd64-i386-rumpuserxen-i386 15 rumpuserxen-demo-xenstorels/xenstorels.repeat fail in 62951 pass in 62963 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 13 guest-localmigrate fail pass in 62951 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 15 guest-localmigrate.2 fail blocked in 62318 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 13 guest-localmigrate fail in 62951 like 62318 test-amd64-i386-libvirt-pair 21 guest-migrate/src_host/dst_host fail like 62256 test-amd64-amd64-libvirt-pair 21 guest-migrate/src_host/dst_host fail like 62256 test-amd64-amd64-rumpuserxen-amd64 15 rumpuserxen-demo-xenstorels/xenstorels.repeat fail like 62318 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 62318 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 62318 Tests which did not succeed, but are not blocking: test-armhf-armhf-xl-vhd 9 debian-di-installfail never pass test-armhf-armhf-libvirt-qcow2 9 debian-di-installfail never pass test-amd64-amd64-xl-pvh-intel 14 guest-saverestorefail never pass test-armhf-armhf-libvirt-raw 9 debian-di-installfail never pass test-amd64-amd64-xl-pvh-amd 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-amd64-libvirt-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-credit2 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail 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-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 12 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail 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-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass version targeted for testing: linux27f1b7fed9c305ef46f8708f1bdde9cdb5f166bd baseline version: linux36311a9ec4904c080bbdfcefc0f3d609ed508224 Last test of basis62318 2015-09-24 00:30:22 Z 21 days Failing since 62540 2015-09-29 17:44:52 Z 15 days 12 attempts Testing same since62659 2015-10-04 12:21:24 Z 10 days 10 attempts People who touched revisions under test: "Eric W. Biederman" Aaron Brown Adam Lee Adrien Schildknecht Alex Deucher Alexander Drozdov Alexander Duyck Alexandre Belloni Alexei Starovoitov Alexey Brodkin Alexey Brodkin Andrew Morton Andrew W Elble Andy Whitcroft Aneesh Kumar K.V Angga Anna Schumaker Ard Biesheuvel Ariel Nahum Atsushi Nemoto Bart Van Assche Benjamin Coddington Benjamin Herrenschmidt Benoit Parrot Bob Copeland Bob Liu Brenden Blanco Brian Starkey Carol L Soto Catali
Re: [Xen-devel] Xen 4.6 released
Tiejun, On 15/10/2015 08:32, "Jan Beulich" wrote: On 15.10.15 at 02:59, wrote: >> Wei and Ian, >> >> Could we merge these following commits into xen-4.6.1? > >Please don't hijack other threads for backport requests, and please >see ./MAINTAINERS of the respective branch for who to send such >to. I wanted to explain why hijacking threads is bad practice. In this example, you would normally start a new mail along the lines of "Please backport XYZ to ABC" and if somebody needed to check why a specific bug fix was back ported in for example 2 yeaqrs, such a mail will be easier to find. Also of course there is the risk that the right people won't read your mail if you hijack a thread. Regards Lars ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RFC 1/3] xen/save: pass a size paramter to the HVM compat functions
>>> On 14.10.15 at 18:24, wrote: > In order to cope with types having multiple compat versions pass a parameter > to the fixup function so we can identify which compat version Xen is dealing > with. Having peeked at patch 2, this won't help once another bit gets added to the tail of that structure. Also it doesn't seem logical that the previous compat handling got around without being passed the size explicitly. I.e. while perhaps more involved, I think the compat handling needs to be extended to allow for multiple versions. Or, since we have this under control going forward, don't even declare all the various compat structures in the public header (and only ever add to the tail). Then staying with the passing of size probably makes sense, but the fixup function then should use offsetof() instead of sizeof() (and validate unused tail bits are zero, so they can be used for something later on). Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RFC 2/3] xen/hvm: introduce a fpu_initialised filed to the CPU save record
>>> On 14.10.15 at 18:51, wrote:
> On 14/10/15 17:24, Roger Pau Monne wrote:
>> @@ -157,9 +158,121 @@ struct hvm_hw_cpu {
>> };
>> /* error code for pending event */
>> uint32_t error_code;
>> +/* is fpu initialised? */
>> +uint8_t fpu_initialised:1;
>
> Bitfields can't be used in the public ABI, and please don't leave
> trailing implicit padding.
>
> I would recommend uint32_t flags and specify that bit 0 indicates that
> fpu context is initialised.
Seconded, despite the bad precedent in the pending event sub-union.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [Patch RFC 00/13] VT-d Asynchronous Device-TLB Flush for ATS Device
>>> On 15.10.15 at 09:28, wrote: > Jan Beulich wrote on 2015-10-15: > On 15.10.15 at 03:03, wrote: >>> Jan Beulich wrote on 2015-10-14: As long as the multi-millisecond spins aren't going to go away by other means, I think conversion to async mode is ultimately unavoidable. >>> >>> I am not fully agreed. I think the time to spin is important. To me, >>> less than 1 ms is acceptable and if the hardware can guarantee it, >>> then sync mode also is ok. >> >> Okay, let me put the condition slightly differently - any spin on the >> order of what a WBINVD might take ought to be okay, provided both are > > From the data we collected, the invalidation is completed within several us. > IMO, the time for WBINVD is varying due the size and different cache > hierarchies. And it may take more than several us in worst case. Understood - hence the setting of the worst case latency of WBINVD as an upper bound for other (kind of similar) software operation. >> equally (in)accessible to guests. The whole discussion is really about >> limiting the impact misbehaving guests can have on the whole system. >> (Obviously any spin time reaching the order of a scheduling time slice >> is a problem.) > > The premise for a misbehaving guest to impact the system is that the IOMMU > is buggy which takes long time to complete the invalidation. In other words, > if all invalidations are able to complete within several us, what's the > matter to do with the spin time? The risk of exploits of such poorly behaving IOMMUs. I.e. if properly operating IOMMUs only require several us, why spin for several ms? >>> I remember the origin motivation to handle ATS problem is due to: 1. >>> ATS spec allow 60s timeout to completed the flush which Xen only >>> allows 1s, and 2. spin loop for 1s is not reasonable since it will >>> hurt the scheduler. For the former, as we discussed before, either >>> disable ATS support or only support some specific ATS >>> devices(complete the flush less than 10ms or 1ms) is acceptable. For >>> the latter, if spin loop for 1s is not acceptable, we can reduce the >>> timeout to 10ms or 1ms >> to eliminate the performance impaction. >> >> If we really can, why has it been chosen to be 1s in the first place? > > What I can tell is 1s is just the value the original author chooses. It has > no special means. I have double check with our hardware expert and he > suggests us to use the value as small as possible. According his comment, > 10ms is sufficiently large. So here you talk about milliseconds again, while above you talked about microsecond. Can we at least settle on an order of what is required? 10ms is 10 times the minimum time slice credit1 allows, i.e. awfully long. >>> Yes, I'd agree it would be best solution if Xen has the async mode. >>> But spin loop is used widely in iommu code: not only for >>> invalidations, lots of DMAR operations are using spin to sync >>> hardware's status. For those operations, it is hard to use async mode. >>> Or, even it is possible to use async mode, I don't see the benefit >>> considering the cost and complexity which means we either need a >>> timer or a >> softirq to do the check. >> >> Even if the cost is high, limited overall throughput by undue spinning >> is worth it imo even outside of misbehaving guest considerations. I'm >> surprised you're not getting similar pressure on this from the KVM >> folks (assuming the use of spinning is similar there). > > Because no one observe such invalidation timeout issue so far. What we have > discussed are only in theory. As is the case with many security related things. We shouldn't wait until someone exploits them. > btw, I have told the issue to Linux IOMMU maintainer but he didn't say > anything on it. Interesting - that may speak for itself (depending on how long this has been pending), but otoh is in line with experience I have with many (but not all) Linux maintainers. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 3/6] xen: sched: clarify use cases of schedule_cpu_switch()
On 10/14/2015 05:54 PM, Dario Faggioli wrote:
schedule_cpu_switch() is meant to be only used for moving
pCPUs from a cpupool to no cpupool, and from there back
to a cpupool, *not* to move them directly from one cpupool
to another.
This is something that is reflected in the way it is
implemented, and should be kept in mind when looking at
it. However, that is not that clear, by just the look of
it.
Make it more evident by adding commentary and ASSERT()s.
Signed-off-by: Dario Faggioli
---
Cc: George Dunlap
Cc: Juergen Gross
Cc: Jan Beulich
---
Changes from v1:
* new patch, was not there in v1.
---
xen/common/schedule.c | 28
1 file changed, 28 insertions(+)
diff --git a/xen/common/schedule.c b/xen/common/schedule.c
index 9aa209d..5ebfa33 100644
--- a/xen/common/schedule.c
+++ b/xen/common/schedule.c
@@ -1486,12 +1486,40 @@ void __init scheduler_init(void)
BUG();
}
+/*
+ * Move a pCPU outside of the influence of the scheduler of its current
+ * cpupool, or subject it to the scheduler of a new cpupool.
+ *
+ * For the pCPUs that are removed from their cpupool, their scheduler becomes
+ * &ops (the default scheduler, selected at boot, which also services the
+ * default cpupool). However, as these pCPUs are not really part of any pool,
+ * there won't be any scheduling event on them, not even from the default
+ * scheduler. Basically, they will just sit idle until they are explicitly
+ * added back to a cpupool.
+ */
int schedule_cpu_switch(unsigned int cpu, struct cpupool *c)
{
struct vcpu *idle;
void *ppriv, *ppriv_old, *vpriv, *vpriv_old;
struct scheduler *old_ops = per_cpu(scheduler, cpu);
struct scheduler *new_ops = (c == NULL) ? &ops : c->sched;
+struct cpupool *pool = per_cpu(cpupool, cpu);
+
+/*
+ * pCPUs only move from a valid cpupool to free (i.e., out of any pool),
+ * or from free to a valid cpupool. In the former case (which happens when
+ * c is NULL), we want the CPU to have been marked as free already, as
+ * well as to not be valid for the source pool any longer, when we get to
+ * here. In the latter case (which happens when c is a valid cpupool), we
+ * want the CPU to still be marked as free, as well as to not yet be valid
+ * for the destination pool.
+ * This all is because we do not want any scheduling activity on the CPU
+ * while, in here, we switch things over.
While this is correct I think you should mention that in the "adding to
a pool" case per_cpu(cpupool, cpu) already contains the new pool
pointer. So c == pool then and both are not NULL.
In fact pool is never NULL, c might be.
Maybe it would be a good idea to move setting of per_cpu(cpupool, cpu)
into schedule_cpu_switch(). Originally I didn't do that to avoid
spreading too much cpupool related actions outside of cpupool.c. But
with those ASSERT()s added hiding that action will cause more confusion
than having the modification of per_cpu(cpupool, cpu) here.
When doing the code movement the current behaviour regarding sequence
of changes must be kept, of course. So when adding the cpu to a pool
the cpupool information must be set _before_ taking the scheduler lock,
while when removing this must happen after release of the lock.
+ */
+ASSERT(c != NULL || pool != NULL);
+ASSERT(cpumask_test_cpu(cpu, &cpupool_free_cpus));
+ASSERT((c == NULL && !cpumask_test_cpu(cpu, pool->cpu_valid)) ||
+ (c != NULL && !cpumask_test_cpu(cpu, c->cpu_valid)));
if ( old_ops == new_ops )
return 0;
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] x86/EPT: defer enabling of A/D maintenance until PML get enabled
>>> On 15.10.15 at 09:35, wrote: > On 10/15/2015 03:11 PM, Jan Beulich wrote: > On 15.10.15 at 08:42, wrote: >>> * ept_p2m_type_to_flags will do the check, and write protection >>> will be >>> * used if PML is not enabled. >>> */ >>> -vmx_domain_enable_pml(p2m->domain); >>> +if ( vmx_domain_enable_pml(p2m->domain) ) >>> +return; >>> + >>> +p2m->ept.ept_ad = 1; >>> +vmx_domain_update_eptp(p2m->domain); >> Shouldn't you enable A/D _before_ enabling PML, at least without >> having a domain-is-paused check here? > Looks we don't have such function. How about just add > ASSERT(atomic_read(&d->pause_count)), just the same as in > vmx_domain_enable_pml ? Indeed that was one of the two possible solutions I meant to hint at. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] xen,arm: enable cpu_hotplug
On Thu, 2015-10-15 at 00:23 +0100, Julien Grall wrote: > My second point is related to how Xen is handling interrupt with vCPU. > When PSCI off is called, we will set the _VFP_down flag. This flag is > used in vgic_vcpu_inject_irq and when it's set the interrupt will be > ignored and stay active on the HW GIC forever. If the vCPU is coming > back online, this interrupt will never be received. AFAIU the spec, the > interrupt is expected to stay pending on the distributor side and will > be receive when the vCPU will come back or migrate to another vCPU. A > similar problem can happen when the vCPU is powered on again because we > clear all the interrupt state related to vCPU (see > vgic_clear_pending_irqs). Is there also an interaction with our implementation of ITARGETSR of picking the lowest set bit? e.g. if an IRQ has target 0x6 (targeting CPU 1 and CPU2) we will choose CPU 1. If CPU 1 is then unplugged, will we end up targeting CPU 2 or the now-offline CPU 1? In the latter case the lack of interrupts might be considered surprising? Or maybe the way CPU hotplug is arranged we never end up with holes in the online cpu space, i.e it is not possible to take down CPU1 and leave CPU2 up? Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [Patch RFC 00/13] VT-d Asynchronous Device-TLB Flush for ATS Device
Jan Beulich wrote on 2015-10-15: On 15.10.15 at 09:28, wrote: >> Jan Beulich wrote on 2015-10-15: >> On 15.10.15 at 03:03, wrote: Jan Beulich wrote on 2015-10-14: > As long as the multi-millisecond spins aren't going to go away by > other means, I think conversion to async mode is ultimately unavoidable. I am not fully agreed. I think the time to spin is important. To me, less than 1 ms is acceptable and if the hardware can guarantee it, then sync mode also is ok. >>> >>> Okay, let me put the condition slightly differently - any spin on >>> the order of what a WBINVD might take ought to be okay, provided >>> both are >> >> From the data we collected, the invalidation is completed within several us. >> IMO, the time for WBINVD is varying due the size and different cache >> hierarchies. And it may take more than several us in worst case. > > Understood - hence the setting of the worst case latency of WBINVD as > an upper bound for other (kind of similar) software operation. > >>> equally (in)accessible to guests. The whole discussion is really about >>> limiting the impact misbehaving guests can have on the whole system. >>> (Obviously any spin time reaching the order of a scheduling time slice >>> is a problem.) >> >> The premise for a misbehaving guest to impact the system is that the >> IOMMU is buggy which takes long time to complete the invalidation. >> In other words, if all invalidations are able to complete within >> several us, what's the matter to do with the spin time? > > The risk of exploits of such poorly behaving IOMMUs. I.e. if properly But this is not a software flaw. A guest has no way to know the underlying IOMMU is wrong and it cannot exploit it. > operating IOMMUs only require several us, why spin for several ms? 10ms is just my suggestion. I don't know whether future hardware will need more time to complete the invalidation. So I think we need to have a large enough timeout here. Meanwhile, doesn't impact the scheduling. > I remember the origin motivation to handle ATS problem is due to: 1. ATS spec allow 60s timeout to completed the flush which Xen only allows 1s, and 2. spin loop for 1s is not reasonable since it will hurt the scheduler. For the former, as we discussed before, either disable ATS support or only support some specific ATS devices(complete the flush less than 10ms or 1ms) is acceptable. For the latter, if spin loop for 1s is not acceptable, we can reduce the timeout to 10ms or 1ms >>> to eliminate the performance impaction. >>> >>> If we really can, why has it been chosen to be 1s in the first place? >> >> What I can tell is 1s is just the value the original author chooses. >> It has no special means. I have double check with our hardware >> expert and he suggests us to use the value as small as possible. >> According his comment, 10ms is sufficiently large. > > So here you talk about milliseconds again, while above you talked > about microsecond. Can we at least settle on an order of what is > required? 10ms is > 10 times the minimum time slice credit1 allows, i.e. > awfully long. We can use an appropriate value which you think reasonable which can cover most of invalidation cases. For left cases, the vcpu can yield the CPU to others until a timer fired. In callback function, hypervisor can check whether the invalidation is completed. If yes, schedule in the vcpu. Otherwise, kill the guest due to unpredictable invalidation timeout. Best regards, Yang ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 3/6] xen: sched: clarify use cases of schedule_cpu_switch()
On Thu, 2015-10-15 at 10:25 +0200, Juergen Gross wrote:
> On 10/14/2015 05:54 PM, Dario Faggioli wrote:
> > schedule_cpu_switch() is meant to be only used for moving
> > pCPUs from a cpupool to no cpupool, and from there back
> > to a cpupool, *not* to move them directly from one cpupool
> > to another.
> >
> > This is something that is reflected in the way it is
> > implemented, and should be kept in mind when looking at
> > it. However, that is not that clear, by just the look of
> > it.
> >
> > Make it more evident by adding commentary and ASSERT()s.
> >
> > Signed-off-by: Dario Faggioli
> > ---
> > Cc: George Dunlap
> > Cc: Juergen Gross
> > Cc: Jan Beulich
> > ---
> > Changes from v1:
> > * new patch, was not there in v1.
> > ---
> > xen/common/schedule.c | 28
> > 1 file changed, 28 insertions(+)
> >
> > diff --git a/xen/common/schedule.c b/xen/common/schedule.c
> > index 9aa209d..5ebfa33 100644
> > --- a/xen/common/schedule.c
> > +++ b/xen/common/schedule.c
> > @@ -1486,12 +1486,40 @@ void __init scheduler_init(void)
> > BUG();
> > }
> >
> > +/*
> > + * Move a pCPU outside of the influence of the scheduler of its
> > current
> > + * cpupool, or subject it to the scheduler of a new cpupool.
> > + *
> > + * For the pCPUs that are removed from their cpupool, their
> > scheduler becomes
> > + * &ops (the default scheduler, selected at boot, which also
> > services the
> > + * default cpupool). However, as these pCPUs are not really part
> > of any pool,
> > + * there won't be any scheduling event on them, not even from the
> > default
> > + * scheduler. Basically, they will just sit idle until they are
> > explicitly
> > + * added back to a cpupool.
> > + */
> > int schedule_cpu_switch(unsigned int cpu, struct cpupool *c)
> > {
> > struct vcpu *idle;
> > void *ppriv, *ppriv_old, *vpriv, *vpriv_old;
> > struct scheduler *old_ops = per_cpu(scheduler, cpu);
> > struct scheduler *new_ops = (c == NULL) ? &ops : c->sched;
> > +struct cpupool *pool = per_cpu(cpupool, cpu);
> > +
> > +/*
> > + * pCPUs only move from a valid cpupool to free (i.e., out of
> > any pool),
> > + * or from free to a valid cpupool. In the former case (which
> > happens when
> > + * c is NULL), we want the CPU to have been marked as free
> > already, as
> > + * well as to not be valid for the source pool any longer,
> > when we get to
> > + * here. In the latter case (which happens when c is a valid
> > cpupool), we
> > + * want the CPU to still be marked as free, as well as to not
> > yet be valid
> > + * for the destination pool.
> > + * This all is because we do not want any scheduling activity
> > on the CPU
> > + * while, in here, we switch things over.
>
> While this is correct I think you should mention that in the "adding
> to
> a pool" case per_cpu(cpupool, cpu) already contains the new pool
> pointer. So c == pool then and both are not NULL.
>
Eheh, I did have an ASSERT() for this too, but I eventually dropped it,
as it looked a bit too verbose. :-)
I can add it, but I like this suggestion of yours here below, so I
guess I'll try it first...
> Maybe it would be a good idea to move setting of per_cpu(cpupool,
> cpu)
> into schedule_cpu_switch(). Originally I didn't do that to avoid
> spreading too much cpupool related actions outside of cpupool.c. But
> with those ASSERT()s added hiding that action will cause more
> confusion
> than having the modification of per_cpu(cpupool, cpu) here.
>
Yep, as said, in principle, I like the idea. I'll try and see how the
code end up looking like.
> When doing the code movement the current behaviour regarding sequence
> of changes must be kept, of course. So when adding the cpu to a pool
> the cpupool information must be set _before_ taking the scheduler
> lock,
> while when removing this must happen after release of the lock.
>
I'm not entirely sure what you mean when you refer to "taking the
scheduler lock", but yes, I'll keep the ordering.
Thanks and 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
[Xen-devel] [linux-mingo-tip-master test] 62974: regressions - FAIL
flight 62974 linux-mingo-tip-master real [real] http://logs.test-lab.xenproject.org/osstest/logs/62974/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-pvops 5 kernel-build fail REGR. vs. 60684 build-i386-pvops 5 kernel-build fail REGR. vs. 60684 Tests which did not succeed, but are not blocking: 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-libvirt 1 build-check(1) blocked n/a test-amd64-i386-xl1 build-check(1) blocked n/a test-amd64-amd64-xl-pvh-amd 1 build-check(1) blocked n/a test-amd64-i386-xl-xsm1 build-check(1) blocked n/a test-amd64-amd64-xl-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-multivcpu 1 build-check(1) blocked n/a test-amd64-amd64-xl-credit2 1 build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-amd64-amd64-pvgrub 1 build-check(1) blocked n/a test-amd64-amd64-i386-pvgrub 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-qemut-debianhvm-amd64 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-qemuu-rhel6hvm-intel 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-debianhvm-amd64 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-xl-qemuu-ovmf-amd64 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-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-raw1 build-check(1) blocked n/a test-amd64-amd64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt 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-qemuu-debianhvm-amd64-xsm 1 build-check(1)blocked n/a test-amd64-i386-qemuu-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a test-amd64-i386-rumpuserxen-i386 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qcow2 1 build-check(1) blocked n/a test-amd64-amd64-rumpuserxen-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl 1 build-check(1) blocked n/a test-amd64-amd64-pygrub 1 build-check(1) blocked n/a test-amd64-amd64-xl-rtds 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-qemut-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-i386-freebsd10-i386 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-pair 1 build-check(1) blocked n/a test-amd64-amd64-pair 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-pair 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-winxpsp3 1 build-check(1) blocked n/a test-amd64-i386-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-vcpus1 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-winxpsp3-vcpus1 1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-winxpsp3 1 build-check(1) blocked n/a version targeted for testing: linux43fb12d95b71252cce4f2c243fb9729c0c31c267 baseline version: linux69f75ebe3b1d1e636c4ce0a0ee248edacc69cbe0 Last test of basis60684 2015-08-13 04:21:46 Z 63 days Failing since 60712 2015-08-15 18:33:48
[Xen-devel] struct paging_mode's {write, cmpxchg}_guest_entry and guest_{map, get_eff}_l1e
Tim, George, what's the reason that these aren't in struct shadow_paging_mode instead? They're only being used by shadow code, and I can't see an abstract reason why HAP would ever want to use them. Thanks, Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [distros-debian-wheezy test] 38170: all pass
flight 38170 distros-debian-wheezy real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/38170/ Perfect :-) All tests in this flight passed baseline version: flight 38137 jobs: build-amd64 pass build-armhf pass build-i386 pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-amd64-wheezy-netboot-pvgrub pass test-amd64-i386-i386-wheezy-netboot-pvgrub pass test-amd64-i386-amd64-wheezy-netboot-pygrub pass test-amd64-amd64-i386-wheezy-netboot-pygrub pass sg-report-flight on osstest.xs.citrite.net logs: /home/osstest/logs images: /home/osstest/images Logs, config files, etc. are available at http://osstest.xs.citrite.net/~osstest/testlogs/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Push not applicable. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] Error while installing xen tools
Hi, I am trying to install xen-tools on arm64 board(thunderx) with ubuntu. I got stuck with the following error. make[3]: Leaving directory `/home/ubuntu/xen_dev/xen/tools/pygrub' make[2]: Leaving directory `/home/ubuntu/xen_dev/xen/tools' make[2]: Entering directory `/home/ubuntu/xen_dev/xen/tools' make -C ocaml install make[3]: Entering directory `/home/ubuntu/xen_dev/xen/tools/ocaml' make[4]: Entering directory `/home/ubuntu/xen_dev/xen/tools/ocaml' make -C libs install make[5]: Entering directory `/home/ubuntu/xen_dev/xen/tools/ocaml/libs' make[6]: Entering directory `/home/ubuntu/xen_dev/xen/tools/ocaml/libs' make -C mmap install make[7]: Entering directory `/home/ubuntu/xen_dev/xen/tools/ocaml/libs/mmap' MLOPTxenmmap.cmx /bin/sh: 1: ocamlopt: not found make[7]: *** [xenmmap.cmx] Error 127 I have installed all the packages related to ocaml but still I am getting the same error.When I googled the error it says ocaml-native-compiler package is needed and for arm64 there is no support for this package. Can some one help me out with this. I am attaching the complete log file also with the mail. Thanks Suresh KN V xen_tools_log Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC] Results of Phase 1 of the Review Process study
On Wed, 2015-10-14 at 18:32 +0100, Lars Kurth wrote:
> C1) Only 60% percent of the reviews on the mailing list could be matched
> to commits. This can be improved going forward, but we felt that the
> dataset is big enough for statical analysis and didn't want to spend too
> much time to get the matching perfect at this stage. See "Coverage
> analysis" for more details
How strict or fuzzy is the matching?
Does it account for e.g. spelling, grammar and clarity changes and things
like adding a subsystem ("tools: libxc:") prefix, either upon commit or by
the author in vN+1 based on feedback?
I often both comment on such things during review and (with the authors
permission) tweak things upon commit.
If those changes are not being correlated then I expect that would skew the
figures of those for whom English is not their first language (and not a
small portion of native speakers even!) and newcomers who e.g. might not be
aware of the need to prefix things with the subsystem.
In a (smaller) number of cases a patch is abandoned in favour of a very
different approach, which I think would be essentially untrackable, at
least automatically.
>
[...]
> The log scale diagrams are more interesting (See LogScale.png for a
> legend).
The width of the box in these diagrams has no meaning, is that correct?
>
[...]
> == Backlog Analysis ==
> This section shows us the total of patch series reviews that could be
> modelled (60%) over the project's life-time
How does this interact with the 60% in caveat C1? Is it the same 60% or is
this 60% of that 60% (i.e. 36% overall)?
If it is the same 60% then how are stalled series distinguished from the
40% which are not mapped to a commit?
Separately, I suppose it is impossible to distinguish stalled from
abandoned (and perhaps in some senses they are the same thing so we don't
need to distinguish).
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] Error while installing xen tools
On Thu, 2015-10-15 at 14:28 +0530, suresh knv wrote: > Hi, > I am trying to install xen-tools on arm64 board(thunderx) with ubuntu. > I got stuck with the following error. > > > make[3]: Leaving directory `/home/ubuntu/xen_dev/xen/tools/pygrub' > make[2]: Leaving directory `/home/ubuntu/xen_dev/xen/tools' > make[2]: Entering directory `/home/ubuntu/xen_dev/xen/tools' > make -C ocaml install > make[3]: Entering directory `/home/ubuntu/xen_dev/xen/tools/ocaml' > make[4]: Entering directory `/home/ubuntu/xen_dev/xen/tools/ocaml' > make -C libs install > make[5]: Entering directory `/home/ubuntu/xen_dev/xen/tools/ocaml/libs' > make[6]: Entering directory `/home/ubuntu/xen_dev/xen/tools/ocaml/libs' > make -C mmap install > make[7]: Entering directory > `/home/ubuntu/xen_dev/xen/tools/ocaml/libs/mmap' > MLOPTxenmmap.cmx > /bin/sh: 1: ocamlopt: not found > make[7]: *** [xenmmap.cmx] Error 127 > > I have installed all the packages related to ocaml but still I am > getting the same error.When I googled the error it says > ocaml-native-compiler package is needed and for arm64 there is no > support for this package. > Can some one help me out with this. Try "./configure --disable-ocamltools"? There would seem to be a bug in the configure script if it is detecting ocaml when a required component (the ocamlopt native compiler) is not present. Ian. > > I am attaching the complete log file also with the mail. > > > Thanks > Suresh KN V > ___ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [ovmf test] 62971: all pass - PUSHED
flight 62971 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/62971/
Perfect :-)
All tests in this flight passed
version targeted for testing:
ovmf 84db9040cc8ba556faec61ad3480c774ca8b984c
baseline version:
ovmf 1e69581335354a7df3bc07b21e495b0b3c5909c0
Last test of basis62964 2015-10-14 13:17:08 Z0 days
Testing same since62971 2015-10-15 01:44:12 Z0 days1 attempts
People who touched revisions under test:
Eric Dong
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 pass
test-amd64-i386-xl-qemuu-ovmf-amd64 pass
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
Pushing revision :
+ branch=ovmf
+ revision=84db9040cc8ba556faec61ad3480c774ca8b984c
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push ovmf
84db9040cc8ba556faec61ad3480c774ca8b984c
+ branch=ovmf
+ revision=84db9040cc8ba556faec61ad3480c774ca8b984c
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=ovmf
+ xenbranch=xen-unstable
+ '[' xovmf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.6-testing
+ : tested/2.6.39.x
+ . ./ap-common
++ xenbranch_forqemu=xen-unstable
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
getconfig GitCacheProxy
perl -e '
use Osstest;
readglobalconfig();
print $c{"GitCacheProxy"} or die $!;
'
+++ local cache=git://cache:9419/
+++ '[' xgit://cache:9419/ '!=' x ']'
+++ echo
'git://cache:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ :
'git://cache:9419/https://github.com/rumpkernel
Re: [Xen-devel] [Patch RFC 00/13] VT-d Asynchronous Device-TLB Flush for ATS Device
>>> On 15.10.15 at 10:52, wrote: > Jan Beulich wrote on 2015-10-15: > On 15.10.15 at 09:28, wrote: >>> The premise for a misbehaving guest to impact the system is that the >>> IOMMU is buggy which takes long time to complete the invalidation. >>> In other words, if all invalidations are able to complete within >>> several us, what's the matter to do with the spin time? >> >> The risk of exploits of such poorly behaving IOMMUs. I.e. if properly > > But this is not a software flaw. A guest has no way to know the underlying > IOMMU is wrong and it cannot exploit it. A guest doesn't need to know what IOMMU is there in order to try some exploit. Plus - based other information it may be able to make an educated guess. >> operating IOMMUs only require several us, why spin for several ms? > > 10ms is just my suggestion. I don't know whether future hardware will need > more time to complete the invalidation. So I think we need to have a large > enough timeout here. Meanwhile, doesn't impact the scheduling. It does, as explained further down in my previous reply. > I remember the origin motivation to handle ATS problem is due to: 1. > ATS spec allow 60s timeout to completed the flush which Xen only > allows 1s, and 2. spin loop for 1s is not reasonable since it will > hurt the scheduler. For the former, as we discussed before, either > disable ATS support or only support some specific ATS > devices(complete the flush less than 10ms or 1ms) is acceptable. > For the latter, if spin loop for 1s is not acceptable, we can > reduce the timeout to 10ms or 1ms to eliminate the performance impaction. If we really can, why has it been chosen to be 1s in the first place? >>> >>> What I can tell is 1s is just the value the original author chooses. >>> It has no special means. I have double check with our hardware >>> expert and he suggests us to use the value as small as possible. >>> According his comment, 10ms is sufficiently large. >> >> So here you talk about milliseconds again, while above you talked >> about microsecond. Can we at least settle on an order of what is >> required? 10ms is >> 10 times the minimum time slice credit1 allows, i.e. >> awfully long. > > We can use an appropriate value which you think reasonable which can cover > most of invalidation cases. For left cases, the vcpu can yield the CPU to > others until a timer fired. In callback function, hypervisor can check > whether the invalidation is completed. If yes, schedule in the vcpu. > Otherwise, kill the guest due to unpredictable invalidation timeout. Using a timer implies you again think about pausing the vCPU until the invalidation completes. Which, as discussed before, has its own problems and, even worse, won't cover the domain's other vCPU-s or devices still possibly doing work involving the use of the being invalidated entries. Or did you have something else in mind? IOW - as soon as spinning time reaches the order of the scheduler time slice, I think the only sane model is async operation with proper refcounting. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC] Results of Phase 1 of the Review Process study
On Thu, 2015-10-15 at 10:06 +0100, Ian Campbell wrote:
> On Wed, 2015-10-14 at 18:32 +0100, Lars Kurth wrote:
> > C1) Only 60% percent of the reviews on the mailing list could be
> > matched
> > to commits. This can be improved going forward, but we felt that the
> > dataset is big enough for statical analysis and didn't want to spend
> > too
> > much time to get the matching perfect at this stage. See "Coverage
> > analysis" for more details
>
> How strict or fuzzy is the matching?
>
> Does it account for e.g. spelling, grammar and clarity changes and things
> like adding a subsystem ("tools: libxc:") prefix, either upon commit or
> by
> the author in vN+1 based on feedback?
>
> I often both comment on such things during review and (with the authors
> permission) tweak things upon commit.
>
> If those changes are not being correlated then I expect that would skew
> the
> figures of those for whom English is not their first language (and not a
> small portion of native speakers even!) and newcomers who e.g. might not
> be
> aware of the need to prefix things with the subsystem.
>
> In a (smaller) number of cases a patch is abandoned in favour of a very
> different approach, which I think would be essentially untrackable, at
> least automatically.
Looking at the stuff in [47] marked as last reviewed in 2014 it seems the
majority of them (at least the ones for which I am involved as a maintainer
etc) can be explained by one of these factors, just going from my memory of
things having been fixed in one way or another.
There also looks to be identical titles (e.g. "x86: Full support of PAT")
being listed there more than once.
Lastly there is at least one ("Introducing Xen PV block driver to OVMF")
which was against another project.
The same seems to be true of e.g. [49] too.
I'm afraid that on that basis I think C1 has skewed the conclusion that
there are 600 stalled series, possibly by a considerable factor.
Ian.
[...]
> [...]
> > == Backlog Analysis ==
> > This section shows us the total of patch series reviews that could be
> > modelled (60%) over the project's life-time
>
> How does this interact with the 60% in caveat C1? Is it the same 60% or
> is
> this 60% of that 60% (i.e. 36% overall)?
>
> If it is the same 60% then how are stalled series distinguished from the
> 40% which are not mapped to a commit?
>
> Separately, I suppose it is impossible to distinguish stalled from
> abandoned (and perhaps in some senses they are the same thing so we don't
> need to distinguish).
>
> Ian.
>
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [OSSTest Nested v12 03/21] Allow runvars to specify guest disk and ram size (turning previous values into defaults) [and 2 more messages]
> -Original Message-
> From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
> Sent: Tuesday, October 13, 2015 6:41 PM
> To: Hu, Robert
> Cc: xen-devel@lists.xen.org; ian.campb...@citrix.com; wei.l...@citrix.com;
> Jin, Gordon ; Zheng, Di ;
> xen-de...@lists.xenproject.org
> Subject: RE: [OSSTest Nested v12 03/21] Allow runvars to specify guest disk
> and ram size (turning previous values into defaults) [and 2 more messages]
>
> Hu, Robert writes ("RE: [OSSTest Nested v12 03/21] Allow runvars to specify
> guest disk and ram size (turning previous values into defaults)"):
> > And sorry I haven't got a chance to read your replies/patches until now.
> > So many test tasks almost crushed me.
>
> That's fine, of course. We all have other things we are doing.
>
> > I'm going to read your mails in the coming week.
>
> Thanks. I see Ian Campbell has replied to several already.
>
>
> Hu, Robert writes ("RE: [OSSTest Nested v12 16/21] Add PDU power method
> for nested L1 and L2 guest"):
> > Ian Jackson [mailto:ian.jack...@eu.citrix.com]:
> > > Robert Ho writes ("[OSSTest Nested v12 16/21] Add PDU power method
> for
> > > nested L1 and L2 guest"):
> > > > For nested host/guest, its power on/off method shall be
> > > > its host invoke $(toolstack)->create/destroy method.
> > >
> > > Thanks for this patch, which I have substantially edited for my v14.
> > >
> > > However, I notice that it was missing a signed-off-by. Can you please
> > > confirm that I should add your s-o-b ?
> >
> > Sorry I forgot to add my s-o-b. Yes, please add mine.
>
> Of course only one of us ought to be rebasing this series at once,
> because otherwise it will be difficult for us to merge our work.
>
> In my mail
> Subject: [OSSTEST PATCH v14 PART 2 10-26/26] Nested HVM testing
> Date: Fri, 25 Sep 2015 20:15:05 +0100
> I handed the series back to you.
>
> So I think it is you who need to add your own s-o-b to that patch.
Yes I planned to do so.
>
> (I don't imply any criticism of you with this detailed explanation. I
> just don't want any misunderstandings; nor do I want this minor work
> item to be dropped.)
>
>
> Likewise:
>
> > > From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
> > > Sent: Saturday, September 26, 2015 3:15 AM
> > > To: xen-de...@lists.xenproject.org
> > > Cc: Hu, Robert ; Ian Campbell
> > > ; Ian Jackson ;
> Ian
> > > Jackson
> > > Subject: [OSSTEST PATCH 15/26] DhcpWatch::leases: Fix a reporting
> message
> > >
> > > This talks about `guest_check_ip', but this code is now factored out
> > > into a method. Use the correct method name in reporting.
> ...
> > Ack.
>
> If you meant
> Acked-by: Robert Ho
> then it would be better if you wrote that explicitly.
Get it.
>
> And of course as current custodian of the branch, it is up to you to
> record your own ack in it. This may seem a little odd, but it is the
> standard approach when dealing with a series containing contributions
> from multiple people.
Yes, understand. I'm learning the upstream rules.
>
>
> I've read your other emails and Ian's replies and I think you should
> be unblocked now ? So I'm expecting more questions, bug reports,
> etc., and hopefully eventually a v15. Do not hesitate to ask again
> for help.
Yeah, I will report issues I found on each specific patch you posted.
>
>
> Regards,
> Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] RFC: Survey on release cycle
On Mon, 2015-10-12 at 18:32 +0100, Wei Liu wrote: > # 6 months release cycle + current stable release scheme # 6 months release cycle + extended security support +1 to either of these, but +2 for picking one of them. (not really sure how to express that in a vote, sorry). > # 6 months release cycle + LTS scheme +1 > # 9 months release cycle + current stable release scheme -1 Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] struct paging_mode's {write, cmpxchg}_guest_entry and guest_{map, get_eff}_l1e
At 02:56 -0600 on 15 Oct (144484), Jan Beulich wrote: > Tim, George, > > what's the reason that these aren't in struct shadow_paging_mode > instead? They're only being used by shadow code, and I can't see > an abstract reason why HAP would ever want to use them. That seems fair. In fact AFAICT they're only called for _translated-mode_ PV guests! So we should just refuse to enter a translated-but-not-external paging mode, since that's not maintained and almost certainly doesn't work, and then these hooks can go away entirely. Cheers, Tim. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [OSSTEST PATCH 26/26] ts-xen-install: networking: Rename `nodhcp' to `ensurebridge'
> -Original Message-
> From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
> Sent: Saturday, September 26, 2015 3:15 AM
> To: xen-de...@lists.xenproject.org
> Cc: Hu, Robert ; Ian Campbell
> ; Ian Jackson ; Ian
> Jackson
> Subject: [OSSTEST PATCH 26/26] ts-xen-install: networking: Rename `nodhcp'
> to `ensurebridge'
>
> This function does not (now) always undo the DHCP configuration.
> Sometimes it leaves it. Its main function is to ensure that we have
> a bridge for use by guests.
>
> So rename the function.
>
> Signed-off-by: Ian Jackson
> ---
> v14: This patch was previously 4/4 of a miniature series containing
> a different way of dealing with the Nested HVM L1 DHCP problem.
> ---
> ts-xen-install |4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/ts-xen-install b/ts-xen-install
> index d9aa694..3d0f394 100755
> --- a/ts-xen-install
> +++ b/ts-xen-install
> @@ -247,7 +247,7 @@ sub hosts () {
> });
> }
>
> -sub nodhcp () {
> +sub ensurebridge () {
> target_editfile_root($ho, "/etc/network/interfaces",
> "etc-network-interfaces", sub {
> my $physif= get_host_property($ho,'interface force',undef);
> @@ -370,6 +370,6 @@ if ($checkmode) {
> adjustconfig();
> setupboot();
> setupinitd();
> -nodhcp();
> +ensurebridge();
> hosts();
> }
[Hu, Robert]
Not sure if it is caused by this patch, but after Xen installed in L1, after L1
reboot,
it boots fail.
Here is log dumped in L0:
(d53) drive 0x000f6330: PCHS=16383/16/63 translation=lba LCHS=1024/255/63
s=2048
(d53) drive 0x000f6360: PCHS=0/0/0 translation=lba LCHS=1024/255/63 s=4096
(d53) Space available for UMB: ca800-ee800, f5d80-f62d0
(d53) Returned 258048 bytes of ZoneHigh
(d53) e820 map has 6 items:
(d53) 0: - 0009fc00 = 1 RAM
(d53) 1: 0009fc00 - 000a = 2 RESERVED
(d53) 2: 000f - 0010 = 2 RESERVED
(d53) 3: 0010 - bf7ff000 = 1 RAM
(d53) 4: bf7ff000 - bf80 = 2 RESERVED
(d53) 5: fc00 - 0001 = 2 RESERVED
(d53) enter handle_19:
(d53) NULL
(d53) Booting from DVD/CD...
(d53) Boot failed: Could not read from CDROM (code 0004)
(d53) enter handle_18:
(d53) NULL
(d53) Booting from Hard Disk...
(d53) Booting from :7c00
(XEN) irq.c:275: Dom53 PCI link 0 changed 5 -> 0
(XEN) irq.c:275: Dom53 PCI link 1 changed 10 -> 0
(XEN) irq.c:275: Dom53 PCI link 2 changed 11 -> 0
(XEN) irq.c:275: Dom53 PCI link 3 changed 5 -> 0
(XEN) traps.c:3287: GPF (): 82d0801ea213 -> 82d080244f4b
(XEN) traps.c:3287: GPF (): 82d0801ea213 -> 82d080244f4b
> --
> 1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RFC 1/3] xen/save: pass a size paramter to the HVM compat functions
El 15/10/15 a les 10.12, Jan Beulich ha escrit: On 14.10.15 at 18:24, wrote: >> In order to cope with types having multiple compat versions pass a parameter >> to the fixup function so we can identify which compat version Xen is dealing >> with. > > Having peeked at patch 2, this won't help once another bit gets added > to the tail of that structure. Also it doesn't seem logical that the > previous compat handling got around without being passed the size > explicitly. I.e. while perhaps more involved, I think the compat > handling needs to be extended to allow for multiple versions. Yes, patch #2 needs to be fixed by making fpu_initialised an uint32_t. Adding versions would be the best option IMHO, but I don't think I have enough time to do that myself right now. > Or, since we have this under control going forward, don't even declare > all the various compat structures in the public header (and only ever > add to the tail). Then staying with the passing of size probably makes > sense, but the fixup function then should use offsetof() instead of > sizeof() (and validate unused tail bits are zero, so they can be used for > something later on). Since we use hvm_load_entry_zeroextend I think we can assert that all new tail bits are going to be 0, but I'm not sure I follow you regarding the usage of offsetof instead of sizeof. What are we going to compare with offsetof? Also, we already have a compat version of hvm_hw_cpu that didn't add the new field to the end. Roger. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [Patch RFC 00/13] VT-d Asynchronous Device-TLB Flush for ATS Device
Jan Beulich wrote on 2015-10-15: On 15.10.15 at 10:52, wrote: >> Jan Beulich wrote on 2015-10-15: >> On 15.10.15 at 09:28, wrote: The premise for a misbehaving guest to impact the system is that the IOMMU is buggy which takes long time to complete the invalidation. In other words, if all invalidations are able to complete within several us, what's the matter to do with the spin time? >>> >>> The risk of exploits of such poorly behaving IOMMUs. I.e. if >>> properly >> >> But this is not a software flaw. A guest has no way to know the >> underlying IOMMU is wrong and it cannot exploit it. > > A guest doesn't need to know what IOMMU is there in order to try some > exploit. Plus - based other information it may be able to make an > educated guess. As I said before, the premise is the IOMMU is buggy. > >>> operating IOMMUs only require several us, why spin for several ms? >> >> 10ms is just my suggestion. I don't know whether future hardware >> will need more time to complete the invalidation. So I think we need >> to have a large enough timeout here. Meanwhile, doesn't impact the > scheduling. > > It does, as explained further down in my previous reply. > >> I remember the origin motivation to handle ATS problem is due to: 1. >> ATS spec allow 60s timeout to completed the flush which Xen only >> allows 1s, and 2. spin loop for 1s is not reasonable since it >> will hurt the scheduler. For the former, as we discussed before, >> either disable ATS support or only support some specific ATS >> devices(complete the flush less than 10ms or 1ms) is acceptable. >> For the latter, if spin loop for 1s is not acceptable, we can >> reduce the timeout to 10ms or 1ms > to eliminate the performance impaction. > > If we really can, why has it been chosen to be 1s in the first place? What I can tell is 1s is just the value the original author chooses. It has no special means. I have double check with our hardware expert and he suggests us to use the value as small as possible. According his comment, 10ms is sufficiently large. >>> >>> So here you talk about milliseconds again, while above you talked >>> about microsecond. Can we at least settle on an order of what is >>> required? 10ms is >>> 10 times the minimum time slice credit1 allows, i.e. >>> awfully long. >> >> We can use an appropriate value which you think reasonable which can >> cover most of invalidation cases. For left cases, the vcpu can yield >> the CPU to others until a timer fired. In callback function, hypervisor >> can check whether the invalidation is completed. If yes, schedule in >> the vcpu. Otherwise, kill the guest due to unpredictable invalidation >> timeout. > > Using a timer implies you again think about pausing the vCPU until the > invalidation completes. Which, as discussed before, has its own > problems and, even worse, won't cover the domain's other vCPU-s or > devices still possibly doing work involving the use of the being > invalidated entries. Or did you have something else in mind? Why not pause the whole domain? Based on Quan's data, all the invalidations in his experiment are completed within 3us. So perhaps 10us is enough to cover all invalidations in today's IOMMU.(I need to check with hardware expert to get the exact data). The timer mechanism is a backup which only for the extreme case which exists in theory. So the probability for a guest trigger the timer mechanism can be ignored. Even it happens, it only affect guest itself. > > IOW - as soon as spinning time reaches the order of the scheduler time > slice, I think the only sane model is async operation with proper refcounting. > > Jan Best regards, Yang ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RFC 2/3] xen/hvm: introduce a fpu_initialised filed to the CPU save record
El 14/10/15 a les 18.51, Andrew Cooper ha escrit:
> On 14/10/15 17:24, Roger Pau Monne wrote:
>> Introduce a new filed to signal if the FPU has been initialised or not. Xen
>
> "field", I am guessing?
Yes.
>> diff --git a/xen/include/public/arch-x86/hvm/save.h
>> b/xen/include/public/arch-x86/hvm/save.h
>> index c7560f2..c4863be 100644
>> --- a/xen/include/public/arch-x86/hvm/save.h
>> +++ b/xen/include/public/arch-x86/hvm/save.h
>> @@ -47,7 +47,8 @@ DECLARE_HVM_SAVE_TYPE(HEADER, 1, struct hvm_save_header);
>> /*
>> * Processor
>> *
>> - * Compat: Pre-3.4 didn't have msr_tsc_aux
>> + * Compat2: Pre-4.7 didn't have fpu_initialised
>> + * Compat1: Pre-3.4 didn't have msr_tsc_aux
>
> I would suggest reversing the Compat1 and 2 lines, to match chronology.
OK, that's fine.
>> */
>>
>> struct hvm_hw_cpu {
>> @@ -157,9 +158,121 @@ struct hvm_hw_cpu {
>> };
>> /* error code for pending event */
>> uint32_t error_code;
>> +/* is fpu initialised? */
>> +uint8_t fpu_initialised:1;
>
> Bitfields can't be used in the public ABI, and please don't leave
> trailing implicit padding.
Sadly we already have quite a lot of bitfields in the same file (see
hvm_hw_vpic) but I understand why they shouldn't be used, specially if
we do the versioning based on the size of the structure.
> I would recommend uint32_t flags and specify that bit 0 indicates that
> fpu context is initialised.
Right.
Roger.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [OSSTEST PATCH 26/26] ts-xen-install: networking: Rename `nodhcp' to `ensurebridge'
> -Original Message-
> From: Hu, Robert
> Sent: Thursday, October 15, 2015 5:39 PM
> To: 'Ian Jackson' ;
> xen-de...@lists.xenproject.org
> Cc: Ian Campbell
> Subject: RE: [OSSTEST PATCH 26/26] ts-xen-install: networking: Rename
> `nodhcp' to `ensurebridge'
>
> > -Original Message-
> > From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
> > Sent: Saturday, September 26, 2015 3:15 AM
> > To: xen-de...@lists.xenproject.org
> > Cc: Hu, Robert ; Ian Campbell
> > ; Ian Jackson ; Ian
> > Jackson
> > Subject: [OSSTEST PATCH 26/26] ts-xen-install: networking: Rename
> `nodhcp'
> > to `ensurebridge'
> >
> > This function does not (now) always undo the DHCP configuration.
> > Sometimes it leaves it. Its main function is to ensure that we have
> > a bridge for use by guests.
> >
> > So rename the function.
> >
> > Signed-off-by: Ian Jackson
> > ---
> > v14: This patch was previously 4/4 of a miniature series containing
> > a different way of dealing with the Nested HVM L1 DHCP problem.
> > ---
> > ts-xen-install |4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/ts-xen-install b/ts-xen-install
> > index d9aa694..3d0f394 100755
> > --- a/ts-xen-install
> > +++ b/ts-xen-install
> > @@ -247,7 +247,7 @@ sub hosts () {
> > });
> > }
> >
> > -sub nodhcp () {
> > +sub ensurebridge () {
> > target_editfile_root($ho, "/etc/network/interfaces",
> > "etc-network-interfaces", sub {
> > my $physif= get_host_property($ho,'interface force',undef);
> > @@ -370,6 +370,6 @@ if ($checkmode) {
> > adjustconfig();
> > setupboot();
> > setupinitd();
> > -nodhcp();
> > +ensurebridge();
> > hosts();
> > }
> [Hu, Robert]
> Not sure if it is caused by this patch, but after Xen installed in L1, after
> L1
> reboot,
> it boots fail.
>
> Here is log dumped in L0:
> (d53) drive 0x000f6330: PCHS=16383/16/63 translation=lba
> LCHS=1024/255/63 s=2048
> (d53) drive 0x000f6360: PCHS=0/0/0 translation=lba LCHS=1024/255/63
> s=4096
> (d53) Space available for UMB: ca800-ee800, f5d80-f62d0
> (d53) Returned 258048 bytes of ZoneHigh
> (d53) e820 map has 6 items:
> (d53) 0: - 0009fc00 = 1 RAM
> (d53) 1: 0009fc00 - 000a = 2 RESERVED
> (d53) 2: 000f - 0010 = 2 RESERVED
> (d53) 3: 0010 - bf7ff000 = 1 RAM
> (d53) 4: bf7ff000 - bf80 = 2 RESERVED
> (d53) 5: fc00 - 0001 = 2 RESERVED
> (d53) enter handle_19:
> (d53) NULL
> (d53) Booting from DVD/CD...
> (d53) Boot failed: Could not read from CDROM (code 0004)
> (d53) enter handle_18:
> (d53) NULL
> (d53) Booting from Hard Disk...
> (d53) Booting from :7c00
> (XEN) irq.c:275: Dom53 PCI link 0 changed 5 -> 0
> (XEN) irq.c:275: Dom53 PCI link 1 changed 10 -> 0
> (XEN) irq.c:275: Dom53 PCI link 2 changed 11 -> 0
> (XEN) irq.c:275: Dom53 PCI link 3 changed 5 -> 0
> (XEN) traps.c:3287: GPF (): 82d0801ea213 -> 82d080244f4b
> (XEN) traps.c:3287: GPF (): 82d0801ea213 -> 82d080244f4b
>
I'm using latest xen.git master. Will try again with Xen 4.6 release which we
have
tested.
>
> > --
> > 1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] xen,arm: enable cpu_hotplug
Hi Ian, On 15/10/15 09:39, Ian Campbell wrote: > On Thu, 2015-10-15 at 00:23 +0100, Julien Grall wrote: >> My second point is related to how Xen is handling interrupt with vCPU. >> When PSCI off is called, we will set the _VFP_down flag. This flag is >> used in vgic_vcpu_inject_irq and when it's set the interrupt will be >> ignored and stay active on the HW GIC forever. If the vCPU is coming >> back online, this interrupt will never be received. AFAIU the spec, the >> interrupt is expected to stay pending on the distributor side and will >> be receive when the vCPU will come back or migrate to another vCPU. A >> similar problem can happen when the vCPU is powered on again because we >> clear all the interrupt state related to vCPU (see >> vgic_clear_pending_irqs). > > Is there also an interaction with our implementation of ITARGETSR of > picking the lowest set bit? e.g. if an IRQ has target 0x6 (targeting CPU 1 > and CPU2) we will choose CPU 1. If CPU 1 is then unplugged, will we end up > targeting CPU 2 or the now-offline CPU 1? In the latter case the lack of > interrupts might be considered surprising? I though about it when I wrote the mail yesterday night. From the spec section 1.4.3 (ARM IHI 0048B.b): "The ARM GIC architecture does not guarantee that a 1-N interrupt is presented to: — all processors listed in the target processor list — an enabled interface, where at least one interface is enabled." AFAIU this paragraph, it means that there is no guarantee to receive an interrupt if the target mask contain a vCPU offline. > Or maybe the way CPU hotplug is arranged we never end up with holes in the > online cpu space, i.e it is not possible to take down CPU1 and leave CPU2 > up? A kernel is allowed to hotplug any vCPU. Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RFC 1/3] xen/save: pass a size paramter to the HVM compat functions
>>> On 15.10.15 at 11:49, wrote: > El 15/10/15 a les 10.12, Jan Beulich ha escrit: > On 14.10.15 at 18:24, wrote: >>> In order to cope with types having multiple compat versions pass a parameter >>> to the fixup function so we can identify which compat version Xen is dealing >>> with. >> >> Having peeked at patch 2, this won't help once another bit gets added >> to the tail of that structure. Also it doesn't seem logical that the >> previous compat handling got around without being passed the size >> explicitly. I.e. while perhaps more involved, I think the compat >> handling needs to be extended to allow for multiple versions. > > Yes, patch #2 needs to be fixed by making fpu_initialised an uint32_t. > Adding versions would be the best option IMHO, but I don't think I have > enough time to do that myself right now. Understood. An I don't think we really need versioning here. >> Or, since we have this under control going forward, don't even declare >> all the various compat structures in the public header (and only ever >> add to the tail). Then staying with the passing of size probably makes >> sense, but the fixup function then should use offsetof() instead of >> sizeof() (and validate unused tail bits are zero, so they can be used for >> something later on). > > Since we use hvm_load_entry_zeroextend I think we can assert that all > new tail bits are going to be 0, but I'm not sure I follow you regarding > the usage of offsetof instead of sizeof. What are we going to compare > with offsetof? Instead of introducing compat1 and compat2 structures, just add the new field to the existing structure, and use offsetof() to compare the passed in size with the that of the structure in its original state. > Also, we already have a compat version of hvm_hw_cpu that didn't add the > new field to the end. Right, but we can avoid making the same mistake again. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] xen,arm: enable cpu_hotplug
On 15/10/15 10:57, Julien Grall wrote: > Hi Ian, > > On 15/10/15 09:39, Ian Campbell wrote: >> On Thu, 2015-10-15 at 00:23 +0100, Julien Grall wrote: >>> My second point is related to how Xen is handling interrupt with vCPU. >>> When PSCI off is called, we will set the _VFP_down flag. This flag is >>> used in vgic_vcpu_inject_irq and when it's set the interrupt will be >>> ignored and stay active on the HW GIC forever. If the vCPU is coming >>> back online, this interrupt will never be received. AFAIU the spec, the >>> interrupt is expected to stay pending on the distributor side and will >>> be receive when the vCPU will come back or migrate to another vCPU. A >>> similar problem can happen when the vCPU is powered on again because we >>> clear all the interrupt state related to vCPU (see >>> vgic_clear_pending_irqs). >> >> Is there also an interaction with our implementation of ITARGETSR of >> picking the lowest set bit? e.g. if an IRQ has target 0x6 (targeting CPU 1 >> and CPU2) we will choose CPU 1. If CPU 1 is then unplugged, will we end up >> targeting CPU 2 or the now-offline CPU 1? In the latter case the lack of >> interrupts might be considered surprising? > > I though about it when I wrote the mail yesterday night. > > From the spec section 1.4.3 (ARM IHI 0048B.b): > > "The ARM GIC architecture does not guarantee that a 1-N interrupt is > presented to: > — all processors listed in the target processor list > — an enabled interface, where at least one interface is enabled." > > AFAIU this paragraph, it means that there is no guarantee to receive an > interrupt if the target mask contain a vCPU offline. Hmmm I may not have been clear here. I meant that the interrupt will stay pending in the distributor but not received by the guest. -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 75/79] include/uapi/xen/privcmd.h: fix compilation in userspace
Hi Mikko, [auto build test ERROR on drm/drm-next -- if it's inappropriate base, please suggest rules for selecting the more suitable base] url: https://github.com/0day-ci/linux/commits/Mikko-Rapeli/Userspace-compile-test-and-fixes-for-exported-uapi-header-files/20151015-150653 config: arm64-allmodconfig (attached as .config) reproduce: wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree make.cross ARCH=arm64 All errors (new ones prefixed by >>): In file included from drivers/xen/privcmd.c:33:0: >> include/uapi/xen/privcmd.h:48:23: error: conflicting types for 'xen_pfn_t' typedef unsigned long xen_pfn_t; ^ In file included from arch/arm64/include/asm/xen/interface.h:1:0, from include/xen/interface/xen.h:30, from include/xen/xen.h:23, from arch/arm64/include/asm/io.h:35, from include/linux/bio.h:30, from include/linux/writeback.h:192, from include/linux/memcontrol.h:30, from include/linux/swap.h:8, from drivers/xen/privcmd.c:20: arch/arm64/include/../../arm/include/asm/xen/interface.h:39:15: note: previous declaration of 'xen_pfn_t' was here typedef __u64 xen_pfn_t; ^ vim +/xen_pfn_t +48 include/uapi/xen/privcmd.h 42 #endif /* domid_t */ 43 44 #ifndef xen_pfn_t 45 #if (defined __ARMEL__ || defined __ARMEB__) 46 typedef __u64 xen_pfn_t; 47 #else > 48 typedef unsigned long xen_pfn_t; 49 #endif /* (defined __ARMEL__ || defined __ARMEB__) */ 50 #endif /* xen_pfn_t */ 51 --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 75/79] include/uapi/xen/privcmd.h: fix compilation in userspace
On 15/10/15 06:56, Mikko Rapeli wrote: > xen/interface/xen.h is not exported from kernel headers so remove the > dependency and provide needed defines for domid_t and xen_pfn_t if they > are not already defined by some other e.g. Xen specific headers. > > Suggested by Andrew Cooper on lkml message > <5569f9c9.8000...@citrix.com>. > > The ifdef for ARM is ugly but did not find better solutions for it. > > Fixes userspace compilation error: > > xen/privcmd.h:38:31: fatal error: xen/interface/xen.h: No such file or > directory [...] > --- a/include/uapi/xen/privcmd.h > +++ b/include/uapi/xen/privcmd.h > @@ -35,7 +35,19 @@ > > #include > #include > -#include > + > +/* Might be defined by Xen specific headers, but if not */ > +#ifndef domid_t > +typedef __u16 domid_t; > +#endif /* domid_t */ As the kbuild bot points out, this does not work since the existence of a typedef cannot be checked with #ifdef. I'm not really sure what problem you're trying to solve. A user space program making use of this interface gets the domid_t and xen_pfn_t etc typedefs from the headers provided as part of the libxenctrl library. David ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RFC 1/3] xen/save: pass a size paramter to the HVM compat functions
On 15/10/15 10:59, Jan Beulich wrote: On 15.10.15 at 11:49, wrote: >> El 15/10/15 a les 10.12, Jan Beulich ha escrit: >> On 14.10.15 at 18:24, wrote: In order to cope with types having multiple compat versions pass a parameter to the fixup function so we can identify which compat version Xen is dealing with. >>> Having peeked at patch 2, this won't help once another bit gets added >>> to the tail of that structure. Also it doesn't seem logical that the >>> previous compat handling got around without being passed the size >>> explicitly. I.e. while perhaps more involved, I think the compat >>> handling needs to be extended to allow for multiple versions. >> Yes, patch #2 needs to be fixed by making fpu_initialised an uint32_t. >> Adding versions would be the best option IMHO, but I don't think I have >> enough time to do that myself right now. > Understood. An I don't think we really need versioning here. > >>> Or, since we have this under control going forward, don't even declare >>> all the various compat structures in the public header (and only ever >>> add to the tail). Then staying with the passing of size probably makes >>> sense, but the fixup function then should use offsetof() instead of >>> sizeof() (and validate unused tail bits are zero, so they can be used for >>> something later on). >> Since we use hvm_load_entry_zeroextend I think we can assert that all >> new tail bits are going to be 0, but I'm not sure I follow you regarding >> the usage of offsetof instead of sizeof. What are we going to compare >> with offsetof? > Instead of introducing compat1 and compat2 structures, just add > the new field to the existing structure, and use offsetof() to compare > the passed in size with the that of the structure in its original state. > >> Also, we already have a compat version of hvm_hw_cpu that didn't add the >> new field to the end. > Right, but we can avoid making the same mistake again. Please be aware that, in due course, I will be replacing all of this, migration v2 style, as a prerequisite of getting cpuid policies functioning correctly during migrate. While we shouldn't paint ourselves into a corner, I wouldn't worry too much about their longevity. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 29/79] gntalloc.h: use __u16, __u32 and __u64 from linux/types.h
On 15/10/15 06:56, Mikko Rapeli wrote: > Fixes userspace compilation errors like: > > xen/gntalloc.h:22:2: error: unknown type name ‘uint16_t’ Applied to for-linus-4.4, thanks. David ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 30/79] gntdev.h: use __u32 and __u64 from linux/types.h
On 15/10/15 06:56, Mikko Rapeli wrote: > Fixes userspace compilation errors like: > > xen/gntdev.h:38:2: error: unknown type name ‘uint32_t’ Applied to for-linus-4.4, thanks. David ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 75/79] include/uapi/xen/privcmd.h: fix compilation in userspace
On Thu, Oct 15, 2015 at 11:29:12AM +0100, David Vrabel wrote: > On 15/10/15 06:56, Mikko Rapeli wrote: > > xen/interface/xen.h is not exported from kernel headers so remove the > > dependency and provide needed defines for domid_t and xen_pfn_t if they > > are not already defined by some other e.g. Xen specific headers. > > > > Suggested by Andrew Cooper on lkml message > > <5569f9c9.8000...@citrix.com>. > > > > The ifdef for ARM is ugly but did not find better solutions for it. > > > > Fixes userspace compilation error: > > > > xen/privcmd.h:38:31: fatal error: xen/interface/xen.h: No such file or > > directory > [...] > > --- a/include/uapi/xen/privcmd.h > > +++ b/include/uapi/xen/privcmd.h > > @@ -35,7 +35,19 @@ > > > > #include > > #include > > -#include > > + > > +/* Might be defined by Xen specific headers, but if not */ > > +#ifndef domid_t > > +typedef __u16 domid_t; > > +#endif /* domid_t */ > > As the kbuild bot points out, this does not work since the existence of > a typedef cannot be checked with #ifdef. Yeah, this hack doesn't cut it. Sorry. Tried to implement these changes: http://www.spinics.net/lists/linux-api/msg11048.html > I'm not really sure what problem you're trying to solve. A user space > program making use of this interface gets the domid_t and xen_pfn_t etc > typedefs from the headers provided as part of the libxenctrl library. I'm trying to make sure that kernel headers in userspace compile with minimal dependencies which are gcc and libc. For me it is clear by now that many Linux API's and ABI's like Xen parts do not live in the uapi header files and instead there's a separate userspace library with needed headers and defines which have embedded copies of the needed API and ABI definitions, like header files. So how could this file be changed so that it compiles in userspace without definitions from libxenctrl? I guess I could copy the needed definitions for domid_t and xen_pfn_t from xen/interface/xen.h of libxenctrl. That I should have done to begin with instead of trying to hack something on my own. -Mikko ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH QEMU-XEN v3 5/8] xen: Switch uses of xc_map_foreign_bulk to use libxenforeignmemory API.
On Wed, 2015-10-14 at 18:17 +0100, Stefano Stabellini wrote:
> On Wed, 14 Oct 2015, Ian Campbell wrote:
> > On Wed, 2015-10-14 at 17:29 +0100, Stefano Stabellini wrote:
> >
> > > > Obviously the call to xen_be_unbind_evtchn is not useful as is, but
> > > > I do
> > > > wonder where the evtchn which the primary console must have
> > > > somewhere
> > > > actually is then...
> > >
> > > Actually I think that xen_be_unbind_evtchn might be useful too, I
> > > think
> > > that is the primary console evtchn. I wonder what specific bug I was
> > > trying to fix when I introduced that if (!xendev->dev) check.
> >
> > I misread xen_be_unbind_evtchn(&con->xendev) as taking xendev->dev
> > instead,
> > which would be NULL and hence pointless... But given that it isn't then
> > yes
> > it seems like it would be worth calling.
> >
> > Is it not the case that &con->xendev == xendev here, leading to another
> > potential cleanup?
>
> Yes, it is the same
I ended up with this at the head of the queue. I've not tested yet, how
would I, AFAIK this code is mainly to do with the PV guest console, which
would normally be handled by xenconsoled and not qemu at all. Can I force
this to run for HVM guests or can I force a PV guest not to use xenconsoled
(hacky ways are fine)?
Ian.
commit cbb9efe66938e44cc9ecca5a4c15cecced7f1385
Author: Ian Campbell
Date: Wed Oct 14 16:49:25 2015 +0100
xen_console: correctly cleanup primary console on teardown.
All of the work in con_disconnect applies to the primary console case
(when xendev->dev is NULL). Therefore remove the early check and bail
and allow it to fall through. All of the existing code is correctly
conditional already.
The ->dev and ->gnttabdev handles are either both set or neither. For
consistency with con_initialise() with to the former here too.
With this con_initialise and con_disconnect now mirror each other.
Fix up a hard tab in the function while editing.
Signed-off-by: Ian Campbell
---
v4: New patch based on feedback to "xen: Switch uses of
xc_map_foreign_bulk to use libxenforeignmemory API."
diff --git a/hw/char/xen_console.c b/hw/char/xen_console.c
index eb7f450..63ade33 100644
--- a/hw/char/xen_console.c
+++ b/hw/char/xen_console.c
@@ -265,9 +265,6 @@ static void con_disconnect(struct XenDevice *xendev)
{
struct XenConsole *con = container_of(xendev, struct XenConsole, xendev);
-if (!xendev->dev) {
-return;
-}
if (con->chr) {
qemu_chr_add_handlers(con->chr, NULL, NULL, NULL, NULL);
qemu_chr_fe_release(con->chr);
@@ -275,12 +272,12 @@ static void con_disconnect(struct XenDevice *xendev)
xen_be_unbind_evtchn(&con->xendev);
if (con->sring) {
-if (!xendev->gnttabdev) {
+if (!xendev->dev) {
munmap(con->sring, XC_PAGE_SIZE);
} else {
xc_gnttab_munmap(xendev->gnttabdev, con->sring, 1);
}
- con->sring = NULL;
+con->sring = NULL;
}
}
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 75/79] include/uapi/xen/privcmd.h: fix compilation in userspace
On 15/10/15 12:18, Mikko Rapeli wrote: > On Thu, Oct 15, 2015 at 11:29:12AM +0100, David Vrabel wrote: >> On 15/10/15 06:56, Mikko Rapeli wrote: >>> xen/interface/xen.h is not exported from kernel headers so remove the >>> dependency and provide needed defines for domid_t and xen_pfn_t if they >>> are not already defined by some other e.g. Xen specific headers. >>> >>> Suggested by Andrew Cooper on lkml message >>> <5569f9c9.8000...@citrix.com>. >>> >>> The ifdef for ARM is ugly but did not find better solutions for it. >>> >>> Fixes userspace compilation error: >>> >>> xen/privcmd.h:38:31: fatal error: xen/interface/xen.h: No such file or >>> directory >> [...] >>> --- a/include/uapi/xen/privcmd.h >>> +++ b/include/uapi/xen/privcmd.h >>> @@ -35,7 +35,19 @@ >>> >>> #include >>> #include >>> -#include >>> + >>> +/* Might be defined by Xen specific headers, but if not */ >>> +#ifndef domid_t >>> +typedef __u16 domid_t; >>> +#endif /* domid_t */ >> >> As the kbuild bot points out, this does not work since the existence of >> a typedef cannot be checked with #ifdef. > > Yeah, this hack doesn't cut it. Sorry. Tried to implement these changes: > http://www.spinics.net/lists/linux-api/msg11048.html > >> I'm not really sure what problem you're trying to solve. A user space >> program making use of this interface gets the domid_t and xen_pfn_t etc >> typedefs from the headers provided as part of the libxenctrl library. > > I'm trying to make sure that kernel headers in userspace compile with minimal > dependencies which are gcc and libc. > > For me it is clear by now that many Linux API's and ABI's like Xen parts do > not live in the uapi header files and instead there's a separate userspace > library with needed headers and defines which have embedded copies of > the needed API and ABI definitions, like header files. > > So how could this file be changed so that it compiles in userspace without > definitions from libxenctrl? I don't think anything needs to be changed. Instead I would make your compilation check of this header dependent on the existence of the xen/interface/xen.h header. Or you may exclude the check of this header entirely. > I guess I could copy the needed definitions for domid_t and xen_pfn_t from > xen/interface/xen.h of libxenctrl. That I should have done to begin with > instead of trying to hack something on my own. I do not want definitions duplicated/copied from the hypervisor ABI headers. This causes problems when support for new architectures is added (for example). David ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v7 23/32] xen/x86: make sure the HVM callback vector is correctly set
> -Original Message- > From: xen-devel-boun...@lists.xen.org [mailto:xen-devel- > boun...@lists.xen.org] On Behalf Of Andrew Cooper > Sent: 14 October 2015 17:02 > To: Jan Beulich; Roger Pau Monne > Cc: xen-de...@lists.xenproject.org > Subject: Re: [Xen-devel] [PATCH v7 23/32] xen/x86: make sure the HVM > callback vector is correctly set > > On 14/10/15 16:54, Jan Beulich wrote: > On 02.10.15 at 17:48, wrote: > >> --- a/xen/arch/x86/hvm/irq.c > >> +++ b/xen/arch/x86/hvm/irq.c > >> @@ -330,6 +330,10 @@ void hvm_set_callback_via(struct domain *d, > uint64_t > >> via) > >> (via_type > HVMIRQ_callback_vector) ) > >> via_type = HVMIRQ_callback_none; > >> > >> +if ( via_type != HVMIRQ_callback_vector && > >> + (!has_vlapic(d) || !has_vioapic(d) || !has_vpic(d)) ) > >> +return; > > Why are both IO-APIC and PIC required? Doesn't one suffice, or > > can't MSI-like interrupts even get delivered without either? > > In real hardware, MSI-like interrupts have no interaction with the > IO-APIC or PIC. > > In fact, the purpose of the IO-APIC is to turn legacy line interrupts > into MSI interrupts. The PICs were from the pre-MSI days where it > asserted the #INTR pin on the processor. > > Our virtual interrupt infrastructure should behave in a consistent manor. > IIRC both the intx and gsi variants of the callback via go in at the vioapic level. Paul > ~Andrew > > ___ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 75/79] include/uapi/xen/privcmd.h: fix compilation in userspace
On Thu, Oct 15, 2015 at 12:24:39PM +0100, David Vrabel wrote: > On 15/10/15 12:18, Mikko Rapeli wrote: > > On Thu, Oct 15, 2015 at 11:29:12AM +0100, David Vrabel wrote: > >> On 15/10/15 06:56, Mikko Rapeli wrote: > >>> xen/interface/xen.h is not exported from kernel headers so remove the > >>> dependency and provide needed defines for domid_t and xen_pfn_t if they > >>> are not already defined by some other e.g. Xen specific headers. > >>> > >>> Suggested by Andrew Cooper on lkml message > >>> <5569f9c9.8000...@citrix.com>. > >>> > >>> The ifdef for ARM is ugly but did not find better solutions for it. > >>> > >>> Fixes userspace compilation error: > >>> > >>> xen/privcmd.h:38:31: fatal error: xen/interface/xen.h: No such file or > >>> directory > >> [...] > >>> --- a/include/uapi/xen/privcmd.h > >>> +++ b/include/uapi/xen/privcmd.h > >>> @@ -35,7 +35,19 @@ > >>> > >>> #include > >>> #include > >>> -#include > >>> + > >>> +/* Might be defined by Xen specific headers, but if not */ > >>> +#ifndef domid_t > >>> +typedef __u16 domid_t; > >>> +#endif /* domid_t */ > >> > >> As the kbuild bot points out, this does not work since the existence of > >> a typedef cannot be checked with #ifdef. > > > > Yeah, this hack doesn't cut it. Sorry. Tried to implement these changes: > > http://www.spinics.net/lists/linux-api/msg11048.html > > > >> I'm not really sure what problem you're trying to solve. A user space > >> program making use of this interface gets the domid_t and xen_pfn_t etc > >> typedefs from the headers provided as part of the libxenctrl library. > > > > I'm trying to make sure that kernel headers in userspace compile with > > minimal > > dependencies which are gcc and libc. > > > > For me it is clear by now that many Linux API's and ABI's like Xen parts do > > not live in the uapi header files and instead there's a separate userspace > > library with needed headers and defines which have embedded copies of > > the needed API and ABI definitions, like header files. > > > > So how could this file be changed so that it compiles in userspace without > > definitions from libxenctrl? > > I don't think anything needs to be changed. > > Instead I would make your compilation check of this header dependent on > the existence of the xen/interface/xen.h header. Or you may exclude the > check of this header entirely. There are not many headers in uapi which require additional userspace headers to compile (I'm not saying that uapi headers represent the full API's/ABI's, it's clear they don't). If there are ~700 headers and just a single one needs an exception and additional dependencies, I would try to make it work without the dependency. I just need some advice and guidance from maintainers how to do this. Or we should start tracking these userspace library dependencies too, at least at linux-headers package levels in distributions. This might be a good idea anyway, but then we might as well move headers like this directly to the userspace library and out of include/uapi. Both would solve the non-compiling uapi header problem. > > I guess I could copy the needed definitions for domid_t and xen_pfn_t from > > xen/interface/xen.h of libxenctrl. That I should have done to begin with > > instead of trying to hack something on my own. > > I do not want definitions duplicated/copied from the hypervisor ABI > headers. This causes problems when support for new architectures is > added (for example). Understood. -Mikko > David ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC] Results of Phase 1 of the Review Process study
On Wed, Oct 14, 2015 at 06:32:37PM +0100, Lars Kurth wrote: [...] > > == Cycle Time [27] to [29] == > This is not quite obvious from the definition in 1. For the cycle time, we > basically ignore the mapping to a patch or patch series and just look at the > cycle times between review iterations *regardless* of which series it belongs > to. > > For example [29] then tells us that the median cycle of any code review has > been fairly static around 5 days from 2012. > > == Backlog Analysis == > This section shows us the total of patch series reviews that could be > modelled (60%) over the project's life-time > > Complete: 5641 > Active (aka activity in the last 7 days) : 78 > Ongoing (aka activity in the last 12 months): 403 > Stalled (no activity for 12 months): 600 Do note that this category covers several things: patches no longer needed, patches superseded by newer version but with different titles, patches to be upstreamed but lost momentum, so I wouldn't use this as primary index for how bad the community functions. In fact I think it shouldn't be given the same importance as the other two. > > This is an area where time based diagrams would help, such that we understand > whether things have become much worse than in the past. On the face of it, > the figures are *worrying*: in particular if you consider we historically > have handled an average of 513 patch series a year, we have the equivalent of > - a year's worth of backlog which is active > - a bit more than a year's backlog which is stalled - there is no way to > identify abandoned reviews > I notice that you noticed the same thing. :-) Wei. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [ovmf baseline-only test] 38171: regressions - FAIL
This run is configured for baseline tests only. flight 38171 ovmf real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/38171/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-ovmf-amd64 19 guest-start/debianhvm.repeat fail REGR. vs. 38169 version targeted for testing: ovmf 84db9040cc8ba556faec61ad3480c774ca8b984c baseline version: ovmf 1e69581335354a7df3bc07b21e495b0b3c5909c0 Last test of basis38169 2015-10-15 01:49:07 Z0 days Testing same since38171 2015-10-15 09:18:48 Z0 days1 attempts People who touched revisions under test: Eric Dong 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 pass test-amd64-i386-xl-qemuu-ovmf-amd64 fail sg-report-flight on osstest.xs.citrite.net logs: /home/osstest/logs images: /home/osstest/images Logs, config files, etc. are available at http://osstest.xs.citrite.net/~osstest/testlogs/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Push not applicable. commit 84db9040cc8ba556faec61ad3480c774ca8b984c Author: Eric Dong Date: Thu Oct 15 00:57:45 2015 + IntelFrameworkModulePkg BdsDxe: Use PcdSet##S to replace PcdSet## PcdSet## has no error status returned, then the caller has no idea about whether the set operation is successful or not. PcdSet##S were added to return error status and PcdSet## APIs were put in ifndef DISABLE_NEW_DEPRECATED_INTERFACES condition. To adopt PcdSet##S and further code development with DISABLE_NEW_DEPRECATED_INTERFACES defined, we need to Replace PcdSet## usage with PcdSet##S. Normally, DynamicDefault PCD set is expected to be success, but DynamicHii PCD set failure is a legal case. So for DynamicDefault, we add assert when set failure. For DynamicHii, we add logic to handle it. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Eric Dong Reviewed-by: Star Zeng git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18605 6f19259b-4bc3-4df7-8a09-765794883524 commit 291422d78bd810b33e7a49733a84d8ea6f6588f4 Author: Eric Dong Date: Thu Oct 15 00:57:20 2015 + Update register hot key logic, return EFI_ALREADY_START status if same hot key already existed. In current case, if one key was requested to register twice, browser will override old hot key with new one. This behavior is not user friendly. Now update the logic, return EFI_ALREADY_STARTED for this case. If user still want to override it, he must unregistered it first. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Eric Dong Reviewed-by: Liming Gao git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18604 6f19259b-4bc3-4df7-8a09-765794883524 commit 377680ae64bd6f702bfac7c98e65f73019b7d285 Author: Eric Dong Date: Thu Oct 15 00:56:41 2015 + MdeModulePkg: Use PcdSet##S to replace PcdSet## PcdSet## has no error status returned, then the caller has no idea about whether the set operation is successful or not. PcdSet##S were added to return error status and PcdSet## APIs were put in ifndef DISABLE_NEW_DEPRECATED_INTERFACES condition. To adopt PcdSet##S and further code development with DISABLE_NEW_DEPRECATED_INTERFACES defined, we need to Replace PcdSet## usage with PcdSet##S. Normally, DynamicDefault PCD set is expected to be success, but DynamicHii PCD set failure is a legal case. So for DynamicDefault, we add assert when set failure. For DynamicHii, we add logic to handle it. Cc: Star Zeng Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Eric Dong Reviewed-by: Star Zeng git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18603 6f19259b-4bc3-4df7-8a09-765794883524 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen/arm: correct comment in enlighten.c
David or Stefano,
On 09/14/2015 03:39 PM, Stefano Stabellini wrote:
On Mon, 14 Sep 2015, Juergen Gross wrote:
Correct a comment in arch/arm/xen/enlighten.c referencing a wrong
source file.
Signed-off-by: Juergen Gross
Acked-by: Stefano Stabellini
does one of you plan to take this patch?
Juergen
arch/arm/xen/enlighten.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index eeeab07..5421706 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -284,7 +284,7 @@ void xen_arch_resume(void) { }
void xen_arch_suspend(void) { }
-/* In the hypervisor.S file. */
+/* In the hypercall.S file. */
EXPORT_SYMBOL_GPL(HYPERVISOR_event_channel_op);
EXPORT_SYMBOL_GPL(HYPERVISOR_grant_table_op);
EXPORT_SYMBOL_GPL(HYPERVISOR_xen_version);
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH] smpboot: Add smpboot state variables instead of reusing CPU hotplug states
The cpu hotplug state machine in smpboot.c is reusing the states from
cpu.h. That is confusing when it comes to the CPU_DEAD_FROZEN usage.
Paul explained to me that he was in need of an additional state
for destinguishing between a CPU error states. For this he just
picked CPU_DEAD_FROZEN.
8038dad7e888581266c76df15d70ca457a3c5910 smpboot: Add common code for
notification from dying CPU
2a442c9c6453d3d043dfd89f2e03a1deff8a6f06 x86: Use common
outgoing-CPU-notification code
Instead of reusing the states, let's add new definition inside
the smpboot.c file with explenation what those states
mean. Thanks Paul for providing them.
Signed-off-by: Daniel Wagner
Cc: Thomas Gleixner
Cc: "Paul E. McKenney"
Cc: Peter Zijlstra
Cc: xen-de...@lists.xenproject.org
Cc: linux-ker...@vger.kernel.org
---
arch/x86/xen/smp.c | 4 +--
include/linux/cpu.h | 3 +-
kernel/smpboot.c| 82 -
3 files changed, 67 insertions(+), 22 deletions(-)
diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
index 3f4ebf0..804bf5c 100644
--- a/arch/x86/xen/smp.c
+++ b/arch/x86/xen/smp.c
@@ -495,7 +495,7 @@ static int xen_cpu_up(unsigned int cpu, struct task_struct
*idle)
rc = HYPERVISOR_vcpu_op(VCPUOP_up, cpu, NULL);
BUG_ON(rc);
- while (cpu_report_state(cpu) != CPU_ONLINE)
+ while (!cpu_check_online(cpu))
HYPERVISOR_sched_op(SCHEDOP_yield, NULL);
return 0;
@@ -767,7 +767,7 @@ static int xen_hvm_cpu_up(unsigned int cpu, struct
task_struct *tidle)
* This can happen if CPU was offlined earlier and
* offlining timed out in common_cpu_die().
*/
- if (cpu_report_state(cpu) == CPU_DEAD_FROZEN) {
+ if (cpu_check_timeout(cpu)) {
xen_smp_intr_free(cpu);
xen_uninit_lock_cpu(cpu);
}
diff --git a/include/linux/cpu.h b/include/linux/cpu.h
index 23c30bd..f78ab46 100644
--- a/include/linux/cpu.h
+++ b/include/linux/cpu.h
@@ -284,7 +284,8 @@ void arch_cpu_idle_dead(void);
DECLARE_PER_CPU(bool, cpu_dead_idle);
-int cpu_report_state(int cpu);
+int cpu_check_online(int cpu);
+int cpu_check_timeout(int cpu);
int cpu_check_up_prepare(int cpu);
void cpu_set_state_online(int cpu);
#ifdef CONFIG_HOTPLUG_CPU
diff --git a/kernel/smpboot.c b/kernel/smpboot.c
index a818cbc..75e5724 100644
--- a/kernel/smpboot.c
+++ b/kernel/smpboot.c
@@ -371,19 +371,63 @@ int smpboot_update_cpumask_percpu_thread(struct
smp_hotplug_thread *plug_thread,
}
EXPORT_SYMBOL_GPL(smpboot_update_cpumask_percpu_thread);
+/* The CPU is offline, and its last offline operation was
+ * successful and proceeded normally. (Or, alternatively, the
+ * CPU never has come online, as this is the initial state.)
+ */
+#define CPUHP_POST_DEAD0x01
+
+/* The CPU is in the process of coming online.
+ * Simple architectures can skip this state, and just invoke
+ * cpu_set_state_online() unconditionally instead.
+ */
+#define CPUHP_UP_PREPARE 0x02
+
+/* The CPU is now online. Simple architectures can skip this
+ * state, and just invoke cpu_wait_death() and cpu_report_death()
+ * unconditionally instead.
+ */
+#define CPUHP_ONLINE 0x03
+
+/* The CPU has gone offline, so that it may now be safely
+ * powered off (or whatever the architecture needs to do to it).
+ */
+#define CPUHP_DEAD 0x04
+
+/* The CPU did not go offline in a timely fashion, if at all,
+ * so it might need special processing at the next online (for
+ * example, simply refusing to bring it online).
+ */
+#define CPUHP_BROKEN 0x05
+
+/* The CPU eventually did go offline, but not in a timely
+ * fashion. If some sort of reset operation is required before it
+ * can be brought online, that reset operation needs to be carried
+ * out at online time. (Or, again, the architecture might simply
+ * refuse to bring it online.)
+ */
+#define CPUHP_TIMEOUT 0x06
+
static DEFINE_PER_CPU(atomic_t, cpu_hotplug_state) =
ATOMIC_INIT(CPU_POST_DEAD);
/*
* Called to poll specified CPU's state, for example, when waiting for
* a CPU to come online.
*/
-int cpu_report_state(int cpu)
+int cpu_check_online(int cpu)
+{
+ return atomic_read(&per_cpu(cpu_hotplug_state, cpu)) ==
+ CPUHP_ONLINE;
+}
+
+int cpu_check_timeout(int cpu)
{
- return atomic_read(&per_cpu(cpu_hotplug_state, cpu));
+ return atomic_read(&per_cpu(cpu_hotplug_state, cpu)) ==
+ CPUHP_TIMEOUT;
}
/*
- * If CPU has died properly, set its state to CPU_UP_PREPARE and
+ * If CPU has died properly, set its state to CPUHP_UP_PREPARE and
* return success. Otherwise, return -EBUSY if the CPU died after
* cpu_wait_death() timed out. And yet otherwise again, return -EAGAIN
* if cpu_wait_death() timed out and the CPU still hasn't gotten around
@@ -397,19 +441,19 @@ int cpu_report_state(int cpu)
int cpu_check_up_prepare(int cpu)
{
if (!IS_ENABLED(C
Re: [Xen-devel] RFC: Survey on release cycle
On Thu, Oct 15, Ian Campbell wrote: > On Mon, 2015-10-12 at 18:32 +0100, Wei Liu wrote: > > > # 6 months release cycle + current stable release scheme > # 6 months release cycle + extended security support > > +1 to either of these, but +2 for picking one of them. +1, as Ian said. > (not really sure how to express that in a vote, sorry). > > > # 6 months release cycle + LTS scheme 0 > > # 9 months release cycle + current stable release scheme 0 Olaf ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen/arm: correct comment in enlighten.c
On 14/09/15 14:20, Juergen Gross wrote: > Correct a comment in arch/arm/xen/enlighten.c referencing a wrong > source file. Applied to for-linus-4.4, thanks. Sorry for the delay. David ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [libvirt test] 62973: tolerable FAIL - PUSHED
flight 62973 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/62973/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt-raw 9 debian-di-installfail never pass
test-armhf-armhf-libvirt-qcow2 9 debian-di-installfail never pass
test-amd64-amd64-libvirt 12 migrate-support-checkfail 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-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-i386-libvirt 12 migrate-support-checkfail never pass
test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass
test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass
test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass
version targeted for testing:
libvirt 897c972a96c304c36bb515235f4b1552d7a5337b
baseline version:
libvirt 1059c48180ae888a6c64fd851bdb1ca031fc5502
Last test of basis62955 2015-10-14 04:20:15 Z1 days
Testing same since62973 2015-10-15 05:43:35 Z0 days1 attempts
People who touched revisions under test:
Andrea Bolognani
John Ferlan
Wei Jiangang
jobs:
build-amd64-xsm pass
build-armhf-xsm pass
build-i386-xsm pass
build-amd64 pass
build-armhf pass
build-i386 pass
build-amd64-libvirt pass
build-armhf-libvirt pass
build-i386-libvirt pass
build-amd64-pvopspass
build-armhf-pvopspass
build-i386-pvops pass
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
test-amd64-amd64-libvirt-xsm pass
test-armhf-armhf-libvirt-xsm fail
test-amd64-i386-libvirt-xsm pass
test-amd64-amd64-libvirt pass
test-armhf-armhf-libvirt fail
test-amd64-i386-libvirt pass
test-amd64-amd64-libvirt-pairpass
test-amd64-i386-libvirt-pair pass
test-armhf-armhf-libvirt-qcow2 fail
test-armhf-armhf-libvirt-raw fail
test-amd64-amd64-libvirt-vhd pass
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
Pushing revision :
+ branch=libvirt
+ revision=897c972a96c304c36bb515235f4b1552d7a5337b
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push libvirt
897c972a96c304c36bb515235f4b1552d7a5337b
+ branch=libvirt
+ revision=897c972a96c304c36bb515235f4b1552d7a5337b
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
getconfig Repos
perl
[Xen-devel] scripts/git-checkout.sh fails in some cases
I already saw scripts/git-checkout.sh fails many times changing repo and/or tag for my tests, for example today: GIT=git /mnt/vm/source/xen/Xen/tools/firmware/../../scripts/git-checkout.sh git://xenbits.xen.org/osstest/ovmf.git xen-tested-master ovmf-dir Cloning into 'ovmf-dir-remote.tmp'... remote: Counting objects: 203149, done. remote: Compressing objects: 100% (49944/49944), done. remote: Total 203149 (delta 153028), reused 196420 (delta 146807) Ricezione degli oggetti: 100% (203149/203149), 194.95 MiB | 527.00 KiB/s, done. Risoluzione dei delta: 100% (153028/153028), done. Checking connectivity... fatto. warning: l'HEAD remoto si riferisce ad un ref inesistente, impossibile eseguire il checkout. fatal: Cannot update paths and switch to branch 'dummy' at the same time. Did you intend to checkout 'xen-tested-master' which can not be resolved as commit? Makefile:23: set di istruzioni per l'obiettivo "ovmf-dir" non riuscito make[3]: *** [ovmf-dir] Errore 128 I not understand why use a dummy branch even if directory is a "temp." I tried a very fast change and worked: #!/bin/sh if test $# -lt 3; then echo "Usage: $0 " exit 1 fi TREE=$1 TAG=$2 DIR=$3 set -e if test \! -d $DIR-remote; then rm -rf $DIR-remote $DIR-remote.tmp mkdir -p $DIR-remote.tmp; rmdir $DIR-remote.tmp if test "$TAG" ; then $GIT clone -b $TAG $TREE $DIR-remote.tmp else $GIT clone $TREE $DIR-remote.tmp fi mv $DIR-remote.tmp $DIR-remote fi rm -f $DIR ln -sf $DIR-remote $DIR But probably a better improvement/solution is needed for a good script working with any branch (its head) or tag. Thanks for any reply and sorry for my bad english. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] Dom0 kernel for Xen4.6 on R-Car H2 (LAGER)
Hi! I just managed to get Xen 4.6.0 on my R-Car H2 LAGER board to show up boot messages, as appended. But it refuses my intended Dom0 kernel - some Yocto/Poky built with meta-renesas configuration. Is there a known-good Dom0 kernel for this board? Hopefully one that I may re-create with something like bitbake? What about an automotive solution? Thank you very much in advance! Max Ferger - 8< - Starting kernel ... - UART enabled - - CPU booting - - Xen starting in Hyp mode - - Zero BSS - - Setting up control registers - - Turning on paging - - Ready - (XEN) Checking for initrd in /chosen (XEN) RAM: 4000 - 7fff (XEN) RAM: 00014000 - 0001 (XEN) (XEN) MODULE[0]: 407f3000 - 407fd000 Device Tree (XEN) RESVD[0]: 70f0 - 70f0a000 (XEN) RESVD[1]: 7ff9a000 - 7ff9a120 (XEN) RESVD[2]: 407f3000 - 407fd000 (XEN) (XEN) Command line: (XEN) Placing Xen at 0x7fc0-0x7fe0 (XEN) Update BOOTMOD_XEN from 9000-9011b701 => 7fc0-7fd1b701 (XEN) Xen heap: 0001f800-0002 (32768 pages) (XEN) Dom heap: 1015808 pages (XEN) Domain heap initialised (XEN) Platform: Renesas R-Car Gen2 (XEN) No dtuart path configured (XEN) Bad console= option 'dtuart' __ ___ ______ \ \/ /___ _ __ | || | / /_ / _ \ \ // _ \ '_ \ | || |_| '_ \| | | | / \ __/ | | | |__ _| (_) | |_| | /_/\_\___|_| |_||_|(_)___(_)___/ (XEN) Xen version 4.6.0 (aen@) (arm-linux-gnueabihf-gcc (Ubuntu/Linaro 4.8.2-16ubuntu4) 4.8.2) debug=y Thu Oct 15 15:17:47 CEST 2015 (XEN) Latest ChangeSet: Mon Oct 5 15:33:39 2015 +0100 git:b24ad7b (XEN) Processor: 413fc0f2: "ARM Limited", variant: 0x3, part 0xc0f, rev 0x2 (XEN) 32-bit Execution: (XEN) Processor Features: 1131:00011011 (XEN) Instruction Sets: AArch32 A32 Thumb Thumb-2 ThumbEE Jazelle (XEN) Extensions: GenericTimer Security (XEN) Debug Features: 02010555 (XEN) Auxiliary Features: (XEN) Memory Model Features: 10201105 4000 0124 02102211 (XEN) ISA Features: 02101110 13112111 21232041 2131 10011142 (XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27 Freq: 1 KHz (XEN) GICv2 initialization: (XEN) gic_dist_addr=f1001000 (XEN) gic_cpu_addr=f1002000 (XEN) gic_hyp_addr=f1004000 (XEN) gic_vcpu_addr=f1006000 (XEN) gic_maintenance_irq=25 (XEN) GICv2: 416 lines, 8 cpus, secure (IID 0200043b). (XEN) XSM Framework v1.0.0 initialized (XEN) Flask: Access controls disabled until policy is loaded. (XEN) Using scheduler: SMP Credit Scheduler (credit) (XEN) Allocated console ring of 64 KiB. (XEN) VFP implementer 0x41 architecture 4 part 0x30 variant 0xf rev 0x0 (XEN) Bringing up CPU1 (XEN) CPU1 never came online (XEN) Failed to bring up CPU 1 (error -5) (XEN) Bringing up CPU2 (XEN) CPU2 never came online (XEN) Failed to bring up CPU 2 (error -5) (XEN) Bringing up CPU3 (XEN) CPU3 never came online (XEN) Failed to bring up CPU 3 (error -5) (XEN) Bringing up CPU4 (XEN) CPU4 never came online (XEN) Failed to bring up CPU 4 (error -5) (XEN) Bringing up CPU5 (XEN) CPU5 never came online (XEN) Failed to bring up CPU 5 (error -5) (XEN) Bringing up CPU6 (XEN) CPU6 never came online (XEN) Failed to bring up CPU 6 (error -5) (XEN) Bringing up CPU7 (XEN) CPU7 never came online (XEN) Failed to bring up CPU 7 (error -5) (XEN) Brought up 1 CPUs (XEN) P2M: 40-bit IPA (XEN) P2M: 3 levels with order-1 root, VTCR 0x80003558 (XEN) I/O virtualisation disabled (XEN) *** LOADING DOMAIN 0 *** (XEN) Missing kernel boot module? (XEN) (XEN) (XEN) Panic on CPU 0: (XEN) Could not set up DOM0 guest OS (XEN) (XEN) (XEN) Reboot in five seconds... [Nothing happens any more] - 8< - Leopold KOSTAL GmbH & Co. KG - Sitz Lüdenscheid, Registergericht Iserlohn HRA 2854, phG Kostal Verwaltungsgesellschaft mbH, Registergericht Iserlohn HRB 4061 - USt-Id-Nr./Vat No.: DE 125800885 Post- und Werksanschrift: An der Bellmerei 10, D-58513 Lüdenscheid * Telefon: +49 2351 16-0 * Telefax: +49 2351 16-2400 Bellmerei Geschäftsführung: Dipl.-Oec. Andreas Kostal (Vorsitzender), Dipl.-Kfm. Helmut Kostal, Dipl.-Ing. Marwin Kinzl, Dr.-Ing. Ludger Laufenberg, Dipl.-Kfm. Ulrich Zimmermann ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH QEMU-XEN v3 6/8] xen: Use stable library interfaces when they are available.
On Wed, 2015-10-14 at 15:52 +0100, Stefano Stabellini wrote: > > + # These libraries were all introduced in the same release, to > > + # simplify things we therefore assume its either all or nothing and > > + # treat any other mix as an error > > + case $xenevtchn$xengnttab$xenforeignmemory in > > + yesyesyes) xenstablelibs=yes;; > > + nonono)xenstablelibs=no;; > > + *) error_exit "Inconsistent set of xen libraries found" > > + ;; > > + esac > > I would remove all this and introduce a xen_stable_libs for the Xen 4.7 > and beyond case: > > xen_stable_libs="-lxenforeignmemory -lxengnttab -lxenevtchn" This and all the consequences which followed make sense and should simplify a bunch of stuff, so will do. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] scripts/git-checkout.sh fails in some cases
On Thu, Oct 15, 2015 at 03:40:36PM +0200, Fabio Fantoni wrote: > I already saw scripts/git-checkout.sh fails many times changing repo and/or > tag for my tests, for example today: > >GIT=git > >/mnt/vm/source/xen/Xen/tools/firmware/../../scripts/git-checkout.sh > >git://xenbits.xen.org/osstest/ovmf.git xen-tested-master ovmf-dir > >Cloning into 'ovmf-dir-remote.tmp'... > >remote: Counting objects: 203149, done. > >remote: Compressing objects: 100% (49944/49944), done. > >remote: Total 203149 (delta 153028), reused 196420 (delta 146807) > >Ricezione degli oggetti: 100% (203149/203149), 194.95 MiB | 527.00 KiB/s, > >done. > >Risoluzione dei delta: 100% (153028/153028), done. > >Checking connectivity... fatto. > >warning: l'HEAD remoto si riferisce ad un ref inesistente, impossibile > >eseguire il checkout. > >fatal: Cannot update paths and switch to branch 'dummy' at the same time. > >Did you intend to checkout 'xen-tested-master' which can not be resolved > >as commit? > >Makefile:23: set di istruzioni per l'obiettivo "ovmf-dir" non riuscito > >make[3]: *** [ovmf-dir] Errore 128 > > I not understand why use a dummy branch even if directory is a "temp." > I tried a very fast change and worked: > >#!/bin/sh > > > >if test $# -lt 3; then > >echo "Usage: $0 " > >exit 1 > >fi > > > >TREE=$1 > >TAG=$2 > >DIR=$3 > > > >set -e > > > >if test \! -d $DIR-remote; then > >rm -rf $DIR-remote $DIR-remote.tmp > >mkdir -p $DIR-remote.tmp; rmdir $DIR-remote.tmp > >if test "$TAG" ; then > >$GIT clone -b $TAG $TREE $DIR-remote.tmp > >else > >$GIT clone $TREE $DIR-remote.tmp > >fi > >mv $DIR-remote.tmp $DIR-remote > >fi > >rm -f $DIR > >ln -sf $DIR-remote $DIR > > But probably a better improvement/solution is needed for a good script > working with any branch (its head) or tag. > > Thanks for any reply and sorry for my bad english. It's just because your local copy doesn't have xen-tested-master -- there is no such local branch. We either put a commit id or tag in Config.mk. If you want to put a branch in Config.mk in your case, use origin/xen-tested-master. I don't think it is a problem in git-checkout.sh because I don't think we should make it "smart" enough to second guess what the user wants. Wei. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Dom0 kernel for Xen4.6 on R-Car H2 (LAGER)
On Thu, 2015-10-15 at 14:17 +, Ferger, Max wrote: > > I just managed to get Xen 4.6.0 on my R-Car H2 LAGER board to show up > boot messages, as appended. > But it refuses my intended Dom0 kernel – some Yocto/Poky built with meta > -renesas configuration. > > Is there a known-good Dom0 kernel for this board? > Hopefully one that I may re-create with something like bitbake? > What about an automotive solution? > > Thank you very much in advance! > > Max Ferger [...] > (XEN) RAM: 4000 - 7fff > (XEN) RAM: 00014000 - 0001 > (XEN) > (XEN) MODULE[0]: 407f3000 - 407fd000 Device Tree > (XEN) RESVD[0]: 70f0 - 70f0a000 > (XEN) RESVD[1]: 7ff9a000 - 7ff9a120 > (XEN) RESVD[2]: 407f3000 - 407fd000 > [...] > (XEN) *** LOADING DOMAIN 0 *** > (XEN) Missing kernel boot module? You don't appear to have passed a dom0 kernel to Xen. e.g. it is not listed as a MODULE[N]. See http://wiki.xen.org/wiki/Xen_ARM_with_Virtualization_Extensions#Booting_Xen which describes how to setup the DTB to reference the kernel boot module etc. It would also be useful if you would post your complete boot script. Also, I'm CCing the original contributors of the Lager support, since we don't have much knowledge of this specific platform or where to get kernels from etc. Ian. > (XEN) > (XEN) > (XEN) Panic on CPU 0: > (XEN) Could not set up DOM0 guest OS > (XEN) > (XEN) > (XEN) Reboot in five seconds... > [Nothing happens any more] > - 8< - > > > > Leopold KOSTAL GmbH & Co. KG - Sitz Lüdenscheid, Registergericht Iserlohn > HRA 2854, phG Kostal Verwaltungsgesellschaft mbH, Registergericht > Iserlohn HRB 4061 - USt-Id-Nr./Vat No.: DE 125800885 > Post- und Werksanschrift: An der Bellmerei 10, D-58513 Lüdenscheid * > Telefon: +49 2351 16-0 * Telefax: +49 2351 16-2400 Bellmerei > Geschäftsführung: Dipl.-Oec. Andreas Kostal (Vorsitzender), Dipl.-Kfm. > Helmut Kostal, Dipl.-Ing. Marwin Kinzl, Dr.-Ing. Ludger Laufenberg, Dipl. > -Kfm. Ulrich Zimmermann > > ___ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] scripts/git-checkout.sh fails in some cases
Il 15/10/2015 16:22, Wei Liu ha scritto: On Thu, Oct 15, 2015 at 03:40:36PM +0200, Fabio Fantoni wrote: I already saw scripts/git-checkout.sh fails many times changing repo and/or tag for my tests, for example today: GIT=git /mnt/vm/source/xen/Xen/tools/firmware/../../scripts/git-checkout.sh git://xenbits.xen.org/osstest/ovmf.git xen-tested-master ovmf-dir Cloning into 'ovmf-dir-remote.tmp'... remote: Counting objects: 203149, done. remote: Compressing objects: 100% (49944/49944), done. remote: Total 203149 (delta 153028), reused 196420 (delta 146807) Ricezione degli oggetti: 100% (203149/203149), 194.95 MiB | 527.00 KiB/s, done. Risoluzione dei delta: 100% (153028/153028), done. Checking connectivity... fatto. warning: l'HEAD remoto si riferisce ad un ref inesistente, impossibile eseguire il checkout. fatal: Cannot update paths and switch to branch 'dummy' at the same time. Did you intend to checkout 'xen-tested-master' which can not be resolved as commit? Makefile:23: set di istruzioni per l'obiettivo "ovmf-dir" non riuscito make[3]: *** [ovmf-dir] Errore 128 I not understand why use a dummy branch even if directory is a "temp." I tried a very fast change and worked: #!/bin/sh if test $# -lt 3; then echo "Usage: $0 " exit 1 fi TREE=$1 TAG=$2 DIR=$3 set -e if test \! -d $DIR-remote; then rm -rf $DIR-remote $DIR-remote.tmp mkdir -p $DIR-remote.tmp; rmdir $DIR-remote.tmp if test "$TAG" ; then $GIT clone -b $TAG $TREE $DIR-remote.tmp else $GIT clone $TREE $DIR-remote.tmp fi mv $DIR-remote.tmp $DIR-remote fi rm -f $DIR ln -sf $DIR-remote $DIR But probably a better improvement/solution is needed for a good script working with any branch (its head) or tag. Thanks for any reply and sorry for my bad english. It's just because your local copy doesn't have xen-tested-master -- there is no such local branch. We either put a commit id or tag in Config.mk. If you want to put a branch in Config.mk in your case, use origin/xen-tested-master. I don't think it is a problem in git-checkout.sh because I don't think we should make it "smart" enough to second guess what the user wants. Wei. Thanks for your reply, I'll try with origin next tests. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen/arm: correct comment in enlighten.c
On Thu, 15 Oct 2015, David Vrabel wrote: > On 14/09/15 14:20, Juergen Gross wrote: > > Correct a comment in arch/arm/xen/enlighten.c referencing a wrong > > source file. > > Applied to for-linus-4.4, thanks. > > Sorry for the delay. Thanks David ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH] libxc: Initialize vcpu context for 64-bit PVH VCPUs
Commit 5b921b49f08 ("libxc: rework BSP initialization") forgot to call
xc_vcpu_setcontext() for 64-bit PVH VCPUs.
Signed-off-by: Boris Ostrovsky
---
Once again, with correctly spelled list address.
tools/libxc/xc_dom_x86.c | 24
1 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/tools/libxc/xc_dom_x86.c b/tools/libxc/xc_dom_x86.c
index 034abe0..4c4182f 100644
--- a/tools/libxc/xc_dom_x86.c
+++ b/tools/libxc/xc_dom_x86.c
@@ -810,18 +810,18 @@ static int vcpu_x86_64(struct xc_dom_image *dom)
DOMPRINTF("%s: cr3: pfn 0x%" PRIpfn " mfn 0x%" PRIpfn "",
__FUNCTION__, dom->pgtables_seg.pfn, cr3_pfn);
-if ( dom->pvh_enabled )
-return 0;
-
-ctxt->user_regs.ds = FLAT_KERNEL_DS_X86_64;
-ctxt->user_regs.es = FLAT_KERNEL_DS_X86_64;
-ctxt->user_regs.fs = FLAT_KERNEL_DS_X86_64;
-ctxt->user_regs.gs = FLAT_KERNEL_DS_X86_64;
-ctxt->user_regs.ss = FLAT_KERNEL_SS_X86_64;
-ctxt->user_regs.cs = FLAT_KERNEL_CS_X86_64;
+if ( !dom->pvh_enabled )
+{
+ctxt->user_regs.ds = FLAT_KERNEL_DS_X86_64;
+ctxt->user_regs.es = FLAT_KERNEL_DS_X86_64;
+ctxt->user_regs.fs = FLAT_KERNEL_DS_X86_64;
+ctxt->user_regs.gs = FLAT_KERNEL_DS_X86_64;
+ctxt->user_regs.ss = FLAT_KERNEL_SS_X86_64;
+ctxt->user_regs.cs = FLAT_KERNEL_CS_X86_64;
-ctxt->kernel_ss = ctxt->user_regs.ss;
-ctxt->kernel_sp = ctxt->user_regs.esp;
+ctxt->kernel_ss = ctxt->user_regs.ss;
+ctxt->kernel_sp = ctxt->user_regs.esp;
+}
rc = xc_vcpu_setcontext(dom->xch, dom->guest_domid, 0, &any_ctx);
if ( rc != 0 )
--
1.7.1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] libxc: Initialize vcpu context for 64-bit PVH VCPUs
El 15/10/15 a les 16.44, Boris Ostrovsky ha escrit:
> Commit 5b921b49f08 ("libxc: rework BSP initialization") forgot to call
> xc_vcpu_setcontext() for 64-bit PVH VCPUs.
>
> Signed-off-by: Boris Ostrovsky
Ouch, my bad:
Acked-by: Roger Pau Monné
32bit seem to be fine though.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable test] 62968: regressions - FAIL
flight 62968 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/62968/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail REGR. vs. 62711 Regressions which are regarded as allowable (not blocking): test-amd64-i386-libvirt-pair 21 guest-migrate/src_host/dst_host fail REGR. vs. 62711 test-armhf-armhf-xl-rtds 11 guest-start fail REGR. vs. 62711 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail like 62711 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 13 guest-localmigrate fail like 62711 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 62711 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 62711 Tests which did not succeed, but are not blocking: 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-raw 9 debian-di-installfail never pass test-armhf-armhf-libvirt-qcow2 9 debian-di-installfail 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-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-xsm 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-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-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 9 debian-di-installfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail 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-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass version targeted for testing: xen ee653b97ce369decfdd4d18979fd9f6aec0073c2 baseline version: xen a23ce429779011de127e8ff6c9bf3486d87154d5 Last test of basis62711 2015-10-07 10:34:21 Z8 days Failing since 62733 2015-10-08 22:34:06 Z6 days7 attempts Testing same since62968 2015-10-14 22:11:34 Z0 days1 attempts People who touched revisions under test: Andrew Cooper Brijesh Singh Daniel Kiper Dario Faggioli Fabio Fantoni George Dunlap He Chen Ian Campbell Ian Jackson Jan Beulich Juergen Gross Julien Grall Mike Latimer Roger Pau Monne Roger Pau Monné Sander Eikelenboom Tamas K Lengyel Tim Deegan Wei Liu Wei Wang Yang Zhang jobs: build-amd64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-prev pass build-i386-prev
Re: [Xen-devel] [PATCH] libxc: Initialize vcpu context for 64-bit PVH VCPUs
On Thu, Oct 15, 2015 at 10:44:26AM -0400, Boris Ostrovsky wrote:
> Commit 5b921b49f08 ("libxc: rework BSP initialization") forgot to call
> xc_vcpu_setcontext() for 64-bit PVH VCPUs.
>
> Signed-off-by: Boris Ostrovsky
Acked-by: Wei Liu
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH QEMU-XEN v3 5/8] xen: Switch uses of xc_map_foreign_bulk to use libxenforeignmemory API.
On Thu, 15 Oct 2015, Ian Campbell wrote:
> On Wed, 2015-10-14 at 18:17 +0100, Stefano Stabellini wrote:
> > On Wed, 14 Oct 2015, Ian Campbell wrote:
> > > On Wed, 2015-10-14 at 17:29 +0100, Stefano Stabellini wrote:
> > >
> > > > > Obviously the call to xen_be_unbind_evtchn is not useful as is, but
> > > > > I do
> > > > > wonder where the evtchn which the primary console must have
> > > > > somewhere
> > > > > actually is then...
> > > >
> > > > Actually I think that xen_be_unbind_evtchn might be useful too, I
> > > > think
> > > > that is the primary console evtchn. I wonder what specific bug I was
> > > > trying to fix when I introduced that if (!xendev->dev) check.
> > >
> > > I misread xen_be_unbind_evtchn(&con->xendev) as taking xendev->dev
> > > instead,
> > > which would be NULL and hence pointless... But given that it isn't then
> > > yes
> > > it seems like it would be worth calling.
> > >
> > > Is it not the case that &con->xendev == xendev here, leading to another
> > > potential cleanup?
> >
> > Yes, it is the same
>
> I ended up with this at the head of the queue. I've not tested yet, how
> would I, AFAIK this code is mainly to do with the PV guest console, which
> would normally be handled by xenconsoled and not qemu at all. Can I force
> this to run for HVM guests or can I force a PV guest not to use xenconsoled
> (hacky ways are fine)?
Yes, you just need to set consback to LIBXL__CONSOLE_BACKEND_IOEMU.
Replacing LIBXL__CONSOLE_BACKEND_XENCONSOLED with
LIBXL__CONSOLE_BACKEND_IOEMU in init_console_info is probably enough.
> commit cbb9efe66938e44cc9ecca5a4c15cecced7f1385
> Author: Ian Campbell
> Date: Wed Oct 14 16:49:25 2015 +0100
>
> xen_console: correctly cleanup primary console on teardown.
>
> All of the work in con_disconnect applies to the primary console case
> (when xendev->dev is NULL). Therefore remove the early check and bail
> and allow it to fall through. All of the existing code is correctly
> conditional already.
>
> The ->dev and ->gnttabdev handles are either both set or neither. For
> consistency with con_initialise() with to the former here too.
>
> With this con_initialise and con_disconnect now mirror each other.
>
> Fix up a hard tab in the function while editing.
>
> Signed-off-by: Ian Campbell
I think it's good.
> ---
> v4: New patch based on feedback to "xen: Switch uses of
> xc_map_foreign_bulk to use libxenforeignmemory API."
>
> diff --git a/hw/char/xen_console.c b/hw/char/xen_console.c
> index eb7f450..63ade33 100644
> --- a/hw/char/xen_console.c
> +++ b/hw/char/xen_console.c
> @@ -265,9 +265,6 @@ static void con_disconnect(struct XenDevice *xendev)
> {
> struct XenConsole *con = container_of(xendev, struct XenConsole, xendev);
>
> -if (!xendev->dev) {
> -return;
> -}
> if (con->chr) {
> qemu_chr_add_handlers(con->chr, NULL, NULL, NULL, NULL);
> qemu_chr_fe_release(con->chr);
> @@ -275,12 +272,12 @@ static void con_disconnect(struct XenDevice *xendev)
> xen_be_unbind_evtchn(&con->xendev);
>
> if (con->sring) {
> -if (!xendev->gnttabdev) {
> +if (!xendev->dev) {
> munmap(con->sring, XC_PAGE_SIZE);
> } else {
> xc_gnttab_munmap(xendev->gnttabdev, con->sring, 1);
> }
> - con->sring = NULL;
> +con->sring = NULL;
> }
> }
>
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] libxc: Initialize vcpu context for 64-bit PVH VCPUs
On 10/15/2015 10:45 AM, Roger Pau Monné wrote:
El 15/10/15 a les 16.44, Boris Ostrovsky ha escrit:
Commit 5b921b49f08 ("libxc: rework BSP initialization") forgot to call
xc_vcpu_setcontext() for 64-bit PVH VCPUs.
Signed-off-by: Boris Ostrovsky
Ouch, my bad:
Acked-by: Roger Pau Monné
32bit seem to be fine though.
I haven't tested it but it does look OK.
-boris
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v7 2/3] x86: add domctl cmd to set/get CDP code/data CBM
On Tue, Oct 13, He Chen wrote:
> +int psr_set_l3_cbm(struct domain *d, unsigned int socket,
> + uint64_t cbm, enum cbm_type type)
> {
> +uint64_t cbm_data, cbm_code;
> +switch ( type )
> {
> +case PSR_CBM_TYPE_L3:
> +cbm_code = cbm;
> +break;
> +case PSR_CBM_TYPE_L3_CODE:
> +cbm_code = cbm;
> +break;
> +case PSR_CBM_TYPE_L3_DATA:
> +cbm_code = map[old_cos].code;
> +break;
> +
> +default:
> +ASSERT_UNREACHABLE();
> +cos = find_cos(map, cos_max, cbm_code, cbm_data, cdp_enabled);
gcc5 does not like ASSERT_UNREACHABLE(), whatever is in staging fails:
[ 2144s] psr.c: In function 'psr_set_l3_cbm':
[ 2144s] psr.c:381:25: error: 'cbm_code' may be used uninitialized in this
function [-Werror=maybe-uninitialized]
[ 2144s] struct cos_cbm_info info =
[ 2144s] ^
[ 2144s] psr.c:442:24: note: 'cbm_code' was declared here
[ 2144s] uint64_t cbm_data, cbm_code;
[ 2144s] ^
[ 2144s] psr.c:513:27: error: 'cbm_data' may be used uninitialized in this
function [-Werror=maybe-uninitialized]
[ 2144s] map[cos].data = cbm_data;
[ 2144s]^
[ 2145s] cc1: all warnings being treated as errors
[ 2145s] /home/abuild/rpmbuild/BUILD/xen-4.7.31795/non-dbg/xen/Rules.mk:174:
recipe for target 'psr.o' failed
[ 2145s] make[4]: *** [psr.o] Error 1
Havent checked if there is already a fix in-flight.
Olaf
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v7 2/3] x86: add domctl cmd to set/get CDP code/data CBM
On Thu, Oct 15, 2015 at 04:57:16PM +0200, Olaf Hering wrote:
> On Tue, Oct 13, He Chen wrote:
>
> > +int psr_set_l3_cbm(struct domain *d, unsigned int socket,
> > + uint64_t cbm, enum cbm_type type)
> > {
>
> > +uint64_t cbm_data, cbm_code;
>
> > +switch ( type )
> > {
>
> > +case PSR_CBM_TYPE_L3:
> > +cbm_code = cbm;
> > +break;
>
> > +case PSR_CBM_TYPE_L3_CODE:
> > +cbm_code = cbm;
> > +break;
>
> > +case PSR_CBM_TYPE_L3_DATA:
> > +cbm_code = map[old_cos].code;
> > +break;
> > +
> > +default:
> > +ASSERT_UNREACHABLE();
>
> > +cos = find_cos(map, cos_max, cbm_code, cbm_data, cdp_enabled);
>
> gcc5 does not like ASSERT_UNREACHABLE(), whatever is in staging fails:
>
> [ 2144s] psr.c: In function 'psr_set_l3_cbm':
> [ 2144s] psr.c:381:25: error: 'cbm_code' may be used uninitialized in this
> function [-Werror=maybe-uninitialized]
> [ 2144s] struct cos_cbm_info info =
> [ 2144s] ^
> [ 2144s] psr.c:442:24: note: 'cbm_code' was declared here
> [ 2144s] uint64_t cbm_data, cbm_code;
> [ 2144s] ^
> [ 2144s] psr.c:513:27: error: 'cbm_data' may be used uninitialized in this
> function [-Werror=maybe-uninitialized]
> [ 2144s] map[cos].data = cbm_data;
> [ 2144s]^
> [ 2145s] cc1: all warnings being treated as errors
> [ 2145s] /home/abuild/rpmbuild/BUILD/xen-4.7.31795/non-dbg/xen/Rules.mk:174:
> recipe for target 'psr.o' failed
> [ 2145s] make[4]: *** [psr.o] Error 1
>
Is it because in non-debug build ASSERT_UNREACHABLE is nop?
> Havent checked if there is already a fix in-flight.
>
> Olaf
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [xen-unstable test] 62968: regressions - FAIL
On Thu, Oct 15, 2015 at 02:45:47PM +, osstest service owner wrote: > flight 62968 xen-unstable real [real] > http://logs.test-lab.xenproject.org/osstest/logs/62968/ > > Regressions :-( > > Tests which did not succeed and are blocking, > including tests which could not be run: > test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail REGR. > vs. 62711 Oct 15 02:59:53.981151 (d1) [0.00] console [tty0] enabled Oct 15 02:59:53.981213 (d1) [0.00] console [hvc0] enabled Oct 15 02:59:53.989101 (d1) [0.00] bootconsole [xenboot0] disabled Oct 15 02:59:53.989168 (XEN) traps.c:3287: GPF (): 82d080195e22 -> 82d080244d91 Don't know what to make of this. Wei. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v7 2/3] x86: add domctl cmd to set/get CDP code/data CBM
On Thu, Oct 15, Wei Liu wrote: > On Thu, Oct 15, 2015 at 04:57:16PM +0200, Olaf Hering wrote: > > gcc5 does not like ASSERT_UNREACHABLE(), whatever is in staging fails: > Is it because in non-debug build ASSERT_UNREACHABLE is nop? That might explain it. Does the staging build test catch this bug anyway? Olaf ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [xen-unstable test] 62968: regressions - FAIL
On Thu, Oct 15, 2015 at 04:21:02PM +0100, Wei Liu wrote: > On Thu, Oct 15, 2015 at 02:45:47PM +, osstest service owner wrote: > > flight 62968 xen-unstable real [real] > > http://logs.test-lab.xenproject.org/osstest/logs/62968/ > > > > Regressions :-( > > > > Tests which did not succeed and are blocking, > > including tests which could not be run: > > test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail > > REGR. vs. 62711 > > Oct 15 02:59:53.981151 (d1) [0.00] console [tty0] enabled > Oct 15 02:59:53.981213 (d1) [0.00] console [hvc0] enabled > Oct 15 02:59:53.989101 (d1) [0.00] bootconsole [xenboot0] disabled > Oct 15 02:59:53.989168 (XEN) traps.c:3287: GPF (): 82d080195e22 -> > 82d080244d91 > > Don't know what to make of this. > According to http://logs.test-lab.xenproject.org/osstest/results/history/test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm/xen-unstable This failure is the first of its kind in xen-unstable flight. According to http://logs.test-lab.xenproject.org/osstest/results/history/test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm/ALL There were similar errors in other branches, but the actual symptom is different -- there was no sign of GP fault. Wei. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v7 2/3] x86: add domctl cmd to set/get CDP code/data CBM
On Thu, Oct 15, 2015 at 05:22:39PM +0200, Olaf Hering wrote: > On Thu, Oct 15, Wei Liu wrote: > > > On Thu, Oct 15, 2015 at 04:57:16PM +0200, Olaf Hering wrote: > > > gcc5 does not like ASSERT_UNREACHABLE(), whatever is in staging fails: > > Is it because in non-debug build ASSERT_UNREACHABLE is nop? > > That might explain it. > Does the staging build test catch this bug anyway? > No, because 1) staging is not using GCC5, 2) staging has debug=y. Wei. > Olaf ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] libxc: Initialize vcpu context for 64-bit PVH VCPUs
On Thu, 2015-10-15 at 15:46 +0100, Wei Liu wrote:
> On Thu, Oct 15, 2015 at 10:44:26AM -0400, Boris Ostrovsky wrote:
> > Commit 5b921b49f08 ("libxc: rework BSP initialization") forgot to call
> > xc_vcpu_setcontext() for 64-bit PVH VCPUs.
> >
> > Signed-off-by: Boris Ostrovsky
>
> Acked-by: Wei Liu
Applied w/ this + Roger's ack.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v7 2/3] x86: add domctl cmd to set/get CDP code/data CBM
On Thu, Oct 15, 2015 at 04:26:47PM +0100, Wei Liu wrote: > On Thu, Oct 15, 2015 at 05:22:39PM +0200, Olaf Hering wrote: > > On Thu, Oct 15, Wei Liu wrote: > > > > > On Thu, Oct 15, 2015 at 04:57:16PM +0200, Olaf Hering wrote: > > > > gcc5 does not like ASSERT_UNREACHABLE(), whatever is in staging fails: > > > Is it because in non-debug build ASSERT_UNREACHABLE is nop? > > > > That might explain it. > > Does the staging build test catch this bug anyway? > > > > No, because 1) staging is not using GCC5, 2) staging has debug=y. > > Wei. > OK. I can confirm staging fails with non-debug build with the same symptom with gcc 4.9 in Debian Jessie. Wei. > > Olaf ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v7 2/3] x86: add domctl cmd to set/get CDP code/data CBM
>>> On 15.10.15 at 17:10, wrote:
> On Thu, Oct 15, 2015 at 04:57:16PM +0200, Olaf Hering wrote:
>> On Tue, Oct 13, He Chen wrote:
>>
>> > +int psr_set_l3_cbm(struct domain *d, unsigned int socket,
>> > + uint64_t cbm, enum cbm_type type)
>> > {
>>
>> > +uint64_t cbm_data, cbm_code;
>>
>> > +switch ( type )
>> > {
>>
>> > +case PSR_CBM_TYPE_L3:
>> > +cbm_code = cbm;
>> > +break;
>>
>> > +case PSR_CBM_TYPE_L3_CODE:
>> > +cbm_code = cbm;
>> > +break;
>>
>> > +case PSR_CBM_TYPE_L3_DATA:
>> > +cbm_code = map[old_cos].code;
>> > +break;
>> > +
>> > +default:
>> > +ASSERT_UNREACHABLE();
>>
>> > +cos = find_cos(map, cos_max, cbm_code, cbm_data, cdp_enabled);
>>
>> gcc5 does not like ASSERT_UNREACHABLE(), whatever is in staging fails:
>>
>> [ 2144s] psr.c: In function 'psr_set_l3_cbm':
>> [ 2144s] psr.c:381:25: error: 'cbm_code' may be used uninitialized in this
>> function [-Werror=maybe-uninitialized]
>> [ 2144s] struct cos_cbm_info info =
>> [ 2144s] ^
>> [ 2144s] psr.c:442:24: note: 'cbm_code' was declared here
>> [ 2144s] uint64_t cbm_data, cbm_code;
>> [ 2144s] ^
>> [ 2144s] psr.c:513:27: error: 'cbm_data' may be used uninitialized in this
>> function [-Werror=maybe-uninitialized]
>> [ 2144s] map[cos].data = cbm_data;
>> [ 2144s]^
>> [ 2145s] cc1: all warnings being treated as errors
>> [ 2145s] /home/abuild/rpmbuild/BUILD/xen-4.7.31795/non-dbg/xen/Rules.mk:174:
>> recipe for target 'psr.o' failed
>> [ 2145s] make[4]: *** [psr.o] Error 1
>>
>
> Is it because in non-debug build ASSERT_UNREACHABLE is nop?
Ah, yes, in cases like this it should always be followed by return
(or whatever else is suitable). Sorry for not having spotted this
during review.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [xen-unstable test] 62968: regressions - FAIL
On 15/10/15 16:26, Wei Liu wrote: > On Thu, Oct 15, 2015 at 04:21:02PM +0100, Wei Liu wrote: >> On Thu, Oct 15, 2015 at 02:45:47PM +, osstest service owner wrote: >>> flight 62968 xen-unstable real [real] >>> http://logs.test-lab.xenproject.org/osstest/logs/62968/ >>> >>> Regressions :-( >>> >>> Tests which did not succeed and are blocking, >>> including tests which could not be run: >>> test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail >>> REGR. vs. 62711 >> Oct 15 02:59:53.981151 (d1) [0.00] console [tty0] enabled >> Oct 15 02:59:53.981213 (d1) [0.00] console [hvc0] enabled >> Oct 15 02:59:53.989101 (d1) [0.00] bootconsole [xenboot0] disabled >> Oct 15 02:59:53.989168 (XEN) traps.c:3287: GPF (): 82d080195e22 -> >> 82d080244d91 >> >> Don't know what to make of this. >> > According to > http://logs.test-lab.xenproject.org/osstest/results/history/test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm/xen-unstable > > This failure is the first of its kind in xen-unstable flight. > > According to > http://logs.test-lab.xenproject.org/osstest/results/history/test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm/ALL > > There were similar errors in other branches, but the actual symptom is > different -- there was no sign of GP fault. Do you have the debug hypervisor to hand? `addr2line -e xen-syms 82d080195e22` will give you some clues. This was a #GP fault which had a extable entry for it, which means it was expected to possibly fault. At a complete guess, possibly an rdmsr emulation for a PV guest. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [xen-unstable test] 62968: regressions - FAIL
On Thu, Oct 15, 2015 at 04:52:07PM +0100, Andrew Cooper wrote: > On 15/10/15 16:26, Wei Liu wrote: > > On Thu, Oct 15, 2015 at 04:21:02PM +0100, Wei Liu wrote: > >> On Thu, Oct 15, 2015 at 02:45:47PM +, osstest service owner wrote: > >>> flight 62968 xen-unstable real [real] > >>> http://logs.test-lab.xenproject.org/osstest/logs/62968/ > >>> > >>> Regressions :-( > >>> > >>> Tests which did not succeed and are blocking, > >>> including tests which could not be run: > >>> test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail > >>> REGR. vs. 62711 > >> Oct 15 02:59:53.981151 (d1) [0.00] console [tty0] enabled > >> Oct 15 02:59:53.981213 (d1) [0.00] console [hvc0] enabled > >> Oct 15 02:59:53.989101 (d1) [0.00] bootconsole [xenboot0] disabled > >> Oct 15 02:59:53.989168 (XEN) traps.c:3287: GPF (): 82d080195e22 -> > >> 82d080244d91 > >> > >> Don't know what to make of this. > >> > > According to > > http://logs.test-lab.xenproject.org/osstest/results/history/test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm/xen-unstable > > > > This failure is the first of its kind in xen-unstable flight. > > > > According to > > http://logs.test-lab.xenproject.org/osstest/results/history/test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm/ALL > > > > There were similar errors in other branches, but the actual symptom is > > different -- there was no sign of GP fault. > > Do you have the debug hypervisor to hand? `addr2line -e xen-syms > 82d080195e22` will give you some clues. > > This was a #GP fault which had a extable entry for it, which means it > was expected to possibly fault. At a complete guess, possibly an rdmsr > emulation for a PV guest. > The current conclusion is that this is actually a toolstack bug that manifests later. I will look into it. Wei. > ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 1/2] x86/mem-sharing: Bulk mem-sharing entire domains
On Mon, Oct 12, 2015 at 12:42 AM, Jan Beulich wrote:
> >>> On 09.10.15 at 19:55, wrote:
> > On Fri, Oct 9, 2015 at 1:51 AM, Jan Beulich wrote:
> >
> >> >>> On 08.10.15 at 22:57, wrote:
> >> > --- a/xen/arch/x86/mm/mem_sharing.c
> >> > +++ b/xen/arch/x86/mm/mem_sharing.c
> >> > @@ -1293,6 +1293,37 @@ int relinquish_shared_pages(struct domain *d)
> >> > return rc;
> >> > }
> >> >
> >> > +static int bulk_share(struct domain *d, struct domain *cd, unsigned
> >> long max,
> >> > + struct mem_sharing_op_bulk_share *bulk)
> >> > +{
> >> > +int rc = 0;
> >> > +shr_handle_t sh, ch;
> >> > +
> >> > +while( bulk->start <= max )
> >> > +{
> >> > +if ( mem_sharing_nominate_page(d, bulk->start, 0, &sh) != 0 )
> >> > +goto next;
> >> > +
> >> > +if ( mem_sharing_nominate_page(cd, bulk->start, 0, &ch) != 0
> )
> >> > +goto next;
> >> > +
> >> > +if ( !mem_sharing_share_pages(d, bulk->start, sh, cd,
> >> bulk->start, ch) )
> >> > +++(bulk->shared);
> >>
> >> Pointless parentheses.
> >>
> >>
> > Pointless but harmless and I like this style better.
>
> Well, it's code you're the maintainer for, so you know, but generally
> I think parentheses should be used to clarify things, not to make
> code harder to read (the effect is minimal here, but extended to a
> more complex expression this may well matter).
>
It might just be me but that's exactly what the parentheses do here. I tend
to read operation from left-to-right and the ++ on the left actually is the
last operation which will be performed after the pointer dereference. The
parentheses make that explicit.
>
> >> > +++(bulk->start);
> >> > +
> >> > +/* Check for continuation if it's not the last iteration. */
> >> > +if ( bulk->start < max && hypercall_preempt_check() )
> >> > +{
> >> > +rc = 1;
> >> > +break;
> >>
> >> This could simple be a return statement, avoiding the need for a
> >> local variable (the type of which would need to be changed, see
> >> below).
> >
> > It's reused in the caller to indicate where the mso copyback happens and
> rc
> > is of type int in the caller.
>
> But you're actually abusing the int nature of rc in the caller to store
> a boolean value. I'd really like to see this be done consistently -
> either use another variable (or, as suggested, no intermediate
> variable in the caller at all), or (also taking into consideration Andrew's
> comments) propagate an actual -E value from here (along with not
> losing errors).
>
So the way we return >0 values is copied from the hypercall continuation
handler of mem_access - there it returns the GFN value which was the same
approach I used in the first version of this patch. Now since we store the
gfn value in the mso struct itself, this just returns an indicator that
there is more work to be done. Otherwise the logic and setup is the same. I
rather not mix these as long as mem_access does it similarly (returning a
positive value indicating more work is to be done).
>
> >> > +rc = xsm_mem_sharing_op(XSM_DM_PRIV, d, cd, mso.op);
> >> > +if ( rc )
> >> > +{
> >> > +rcu_unlock_domain(cd);
> >> > +goto out;
> >> > +}
> >> > +
> >> > +if ( !mem_sharing_enabled(cd) )
> >> > +{
> >> > +rcu_unlock_domain(cd);
> >> > +rc = -EINVAL;
> >> > +goto out;
> >> > +}
> >> > +
> >> > +max_sgfn = domain_get_maximum_gpfn(d);
> >> > +max_cgfn = domain_get_maximum_gpfn(cd);
> >> > +
> >> > +if ( max_sgfn != max_cgfn || max_sgfn < mso.u.bulk.start
> )
> >>
> >> Are both domains required to be paused for this operation? If so,
> >> shouldn't you enforce this? If not, by the time you reach the if()
> >> the values are stale.
> >
> > It's expected that the user has exclusive tool-side lock on the domains
> > before issuing this hypercall and that the domains are paused already.
>
> As said - in that case, please enforce this (by bailing if not so).
>
Ack.
> >> > --- a/xen/include/public/memory.h
> >> > +++ b/xen/include/public/memory.h
> >> > @@ -447,6 +447,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_mem_access_op_t);
> >> > #define XENMEM_sharing_op_debug_gref5
> >> > #define XENMEM_sharing_op_add_physmap 6
> >> > #define XENMEM_sharing_op_audit 7
> >> > +#define XENMEM_sharing_op_bulk_share8
> >> >
> >> > #define XENMEM_SHARING_OP_S_HANDLE_INVALID (-10)
> >> > #define XENMEM_SHARING_OP_C_HANDLE_INVALID (-9)
> >> > @@ -482,7 +483,13 @@ struct xen_mem_sharing_op {
> >> > uint64_aligned_t client_gfn;/* IN: the client gfn */
> >> > uint64_aligned_t client_handle; /* IN: handle to the
> client
> >> page */
> >> > domid_t client_domain; /* IN: the client domain id */
> >> > -} share;
[Xen-devel] [linux-linus test] 62972: regressions - FAIL
flight 62972 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/62972/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 13 guest-localmigrate fail in 62958 REGR. vs. 59254 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 15 guest-localmigrate.2 fail in 62958 REGR. vs. 59254 Tests which are failing intermittently (not blocking): test-amd64-amd64-rumpuserxen-amd64 10 guest-start fail in 62958 pass in 62972 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail pass in 62958 test-armhf-armhf-xl-rtds 11 guest-start fail pass in 62958 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 13 guest-localmigrate fail pass in 62958 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-libvirt-pair 21 guest-migrate/src_host/dst_host fail baseline untested test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail in 62958 like 59254 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 59254 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 59254 Tests which did not succeed, but are not blocking: test-armhf-armhf-xl-rtds 13 saverestore-support-check fail in 62958 never pass test-armhf-armhf-xl-rtds 12 migrate-support-check fail in 62958 never pass test-amd64-amd64-xl-pvh-intel 14 guest-saverestorefail never pass test-armhf-armhf-libvirt-qcow2 9 debian-di-installfail never pass test-armhf-armhf-xl-vhd 9 debian-di-installfail never pass test-amd64-amd64-xl-pvh-amd 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-amd64-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-xsm 12 migrate-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-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 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-libvirt-raw 9 debian-di-installfail 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-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail 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-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass version targeted for testing: linux5b5f1455272e23f4e7889cec37228802d8d01adf baseline version: linux45820c294fe1b1a9df495d57f40585ef2d069a39 Last test of basis59254 2015-07-09 04:20:48 Z 98 days Failing since 59348 2015-07-10 04:24:05 Z 97 days 58 attempts Testing same since62958 2015-10-14 09:03:19 Z1 days2 attempts 2437 people touched revisions under test, not listing them all jobs: build-amd64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt
Re: [Xen-devel] [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu
Il 14/10/2015 13:06, Stefano Stabellini ha scritto: On Wed, 14 Oct 2015, Kevin Wolf wrote: [ CC qemu-block ] Am 13.10.2015 um 19:10 hat Stefano Stabellini geschrieben: On Tue, 13 Oct 2015, John Snow wrote: On 10/13/2015 11:55 AM, Fabio Fantoni wrote: I added ahci disk support in libxl and using it for week seems that was ok, after a reply of Stefano Stabellini seems that xen disk unplug support only ide disks: http://git.qemu.org/?p=qemu.git;a=commitdiff;h=679f4f8b178e7c66fbc2f39c905374ee8663d5d8 Today Paul Durrant told me that even if pv disk is ok also with ahci and the emulated one is offline can be a risk: http://lists.xenproject.org/archives/html/win-pv-devel/2015-10/msg00021.html I tried to take a fast look in qemu code but I not understand the needed thing for add the xen disk unplug support also for ahci, can someone do it or tell me useful information for do it please? Thanks for any reply and sorry for my bad english. I'm not entirely sure what features you need AHCI to support in order for Xen to be happy. I'd guess hotplugging, but where I get confused is that IDE disks don't support hotplugging either, so I guess I'm not sure sure what you need. Stefano, can you help bridge my Xen knowledge gap? Hi John, we need something like hw/i386/xen/xen_platform.c:unplug_disks but that can unplug AHCI disk. And by unplug, I mean "make disappear" like pci_piix3_xen_ide_unplug does for ide. Maybe this would be the right time to stop the craziness with your hybrid IDE/xendisk setup. It's a horrible thing that would never happen on real hardware. I would be quite happy to stop (or even get rid of) the craziness. Can't you just teach SeaBIOS how to deal with your PV disks and then only add that to your VM and forget about IDE/AHCI? I mean, that's how it's done for virtio-blk, and it doesn't involve any insanities like ripping out non-hotpluggable devices. Teaching SeaBIOS to deal with PV disks can be done, in fact we already support PV disks in OVMF. It is possible to boot Windows with OVMF without any IDE disks (patch pending for libxl to create a VM without emulated IDE disks). However we have to be honest that implementing PV disk support in SeaBIOS is a different magnitude of effort compared to implementing AHCI "unplug". I would suggest Fabio to avoid AHCI disks altogether and just use OVMF with PV disks only and Anthony's patch to libxl to avoid creating any IDE disks: http://marc.info/?l=xen-devel&m=144482080812353. Would that work for you? Thanks for the advice, I tried it: https://github.com/Fantu/Xen/commits/rebase/m2r-testing-4.6 I installed W10 pro 64 bit with ide disk, installed the win pv drivers and after changed to xvdX instead hdX, is the only change needed, right? Initial boot is ok (ovmf part about pv disks seems ok) but windows boot fails with problem with pv drivers. In attachment full qemu log with xen_platform trace and domU's xl cfg. Someone have windows domUs with ovmf and pv disks only working? If yes can tell me the difference to understand what can be the problem please? Hm... How does a reboot of a machine that had its IDE already removed actually work? Do you restart the qemu process on reboot? Restart QEMU, yes. main_channel_link: add main channel client main_channel_handle_parsed: net test: latency 8.258000 ms, bitrate 727789623 bps (694.074271 Mbps) inputs_connect: inputs channel client create red_dispatcher_set_cursor_peer: xen_platform_log xen platform: XEN|DllInitialize: 8.2.0 (80) (17.09.2015) xen_platform_log xen platform: XEN|AcpiFindRsdp: 0x000EA020 xen_platform_log xen platform: XEN|SystemGetStartOptions: TESTSIGNING NOEXECUTE=OPTIN NOVGA xen_platform_log xen platform: XEN|SystemGetVersionInformation: KERNEL: 10.0 (BUILD 10240) PLATFORM WIN32_NT (x64) xen_platform_log xen platform: XEN|SystemGetVersionInformation: SUITES: xen_platform_log xen platform: XEN|SystemGetVersionInformation: - TERMINAL xen_platform_log xen platform: XEN|SystemGetVersionInformation: - SINGLEUSERTS xen_platform_log xen platform: XEN|SystemGetVersionInformation: TYPE: WORKSTATION xen_platform_log xen platform: XEN|SystemGetMemoryInformation: RANGE[0] .1000 - .0009efff xen_platform_log xen platform: XEN|SystemGetMemoryInformation: RANGE[1] .0010 - .eed94fff xen_platform_log xen platform: XEN|SystemGetMemoryInformation: RANGE[2] .eee12000 - .efe91fff xen_platform_log xen platform: XEN|SystemGetMemoryInformation: RANGE[3] .efef6000 - .effc xen_platform_log xen platform: XEN|SystemGetMemoryInformation: RANGE[4] .efff - .efff xen_platform_log xen platform: XEN|SystemGetMemoryInformation: RANGE[5] 0001. - 0001.07eaafff xen_platform_log xen platform: XEN|AcpiGetXsdt: 0xFC012BA0 xen_platform_log xen platform: XEN|SystemProcessorInformation: > (0:0) xen_platform_log xen platform: XEN|SystemProcessorInformation:
[Xen-devel] [PATCH] xen-netback: corretly check failed allocation
Since vzalloc can be failed in memory pressure,
return value should be checked and return ENOMEM.
Signed-off-by: Insu Yun
---
drivers/net/xen-netback/xenbus.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c
index 929a6e7..e288246 100644
--- a/drivers/net/xen-netback/xenbus.c
+++ b/drivers/net/xen-netback/xenbus.c
@@ -788,6 +788,11 @@ static void connect(struct backend_info *be)
/* Use the number of queues requested by the frontend */
be->vif->queues = vzalloc(requested_num_queues *
sizeof(struct xenvif_queue));
+ if (!be->vif->queues) {
+xenbus_dev_fatal(dev, -ENOMEM, "allocating queues");
+return;
+ }
+
be->vif->num_queues = requested_num_queues;
be->vif->stalled_queues = requested_num_queues;
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH] libxc: fix the types used in xc_dom_image to build HVM guests
Fix the types used to store the memory parameters of an HVM guest,
previously they defaulted to unsigned long on 32bit toolstack builds, which
is wrong because a 32bit value cannot hold a 64bit memory address that
crosses the 4GB boundary.
Signed-off-by: Roger Pau Monné
Cc: Ian Jackson
Cc: Ian Campbell
Cc: Wei Liu
---
I don't have a 32bit Dom0 at hand, so if someone can try to create a HVM
guests using a 32bit toolstack with more than 4GB of RAM it would be
helpful.
---
tools/libxc/include/xc_dom.h | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
index e52b023..eb3e355 100644
--- a/tools/libxc/include/xc_dom.h
+++ b/tools/libxc/include/xc_dom.h
@@ -186,11 +186,11 @@ struct xc_dom_image {
} container_type;
/* HVM specific fields. */
-xen_pfn_t target_pages;
-xen_pfn_t mmio_start;
-xen_pfn_t mmio_size;
-xen_pfn_t lowmem_end;
-xen_pfn_t highmem_end;
+unsigned long target_pages;
+unsigned long long mmio_start;
+unsigned long long mmio_size;
+unsigned long lowmem_end;
+unsigned long long highmem_end;
/* Extra ACPI tables passed to HVMLOADER */
struct xc_hvm_firmware_module acpi_module;
--
1.9.5 (Apple Git-50.3)
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] libxc: fix the types used in xc_dom_image to build HVM guests
On 10/15/2015 06:30 PM, Roger Pau Monne wrote:
Fix the types used to store the memory parameters of an HVM guest,
previously they defaulted to unsigned long on 32bit toolstack builds, which
is wrong because a 32bit value cannot hold a 64bit memory address that
crosses the 4GB boundary.
Signed-off-by: Roger Pau Monné
Cc: Ian Jackson
Cc: Ian Campbell
Cc: Wei Liu
---
I don't have a 32bit Dom0 at hand, so if someone can try to create a HVM
guests using a 32bit toolstack with more than 4GB of RAM it would be
helpful.
---
tools/libxc/include/xc_dom.h | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
index e52b023..eb3e355 100644
--- a/tools/libxc/include/xc_dom.h
+++ b/tools/libxc/include/xc_dom.h
@@ -186,11 +186,11 @@ struct xc_dom_image {
} container_type;
/* HVM specific fields. */
-xen_pfn_t target_pages;
-xen_pfn_t mmio_start;
-xen_pfn_t mmio_size;
-xen_pfn_t lowmem_end;
-xen_pfn_t highmem_end;
+unsigned long target_pages;
+unsigned long long mmio_start;
I'd prefer xen_paddr_t.
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] libxc: fix the types used in xc_dom_image to build HVM guests
On Thu, 2015-10-15 at 18:30 +0200, Roger Pau Monne wrote:
> Fix the types used to store the memory parameters of an HVM guest,
> previously they defaulted to unsigned long on 32bit toolstack builds, which
> is wrong because a 32bit value cannot hold a 64bit memory address that
> crosses the 4GB boundary.
This header includes a xen_paddr_t in it which looks like the appropriate
type for most of these.
The ones which have units of pages which you've changed from xen_pfn_t to
unsigned long (not long long) should surely remain xen_pfn_t? At least
target_pages should IMHO.
lowmem_end doesn't strictly need to be 64-bit, but xen_paddr_t seems like
the appropriate type semantically nonetheless.
>
> Signed-off-by: Roger Pau Monné
> Cc: Ian Jackson
> Cc: Ian Campbell
> Cc: Wei Liu
> ---
> I don't have a 32bit Dom0 at hand, so if someone can try to create a HVM
> guests using a 32bit toolstack with more than 4GB of RAM it would be
> helpful.
> ---
> tools/libxc/include/xc_dom.h | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
> index e52b023..eb3e355 100644
> --- a/tools/libxc/include/xc_dom.h
> +++ b/tools/libxc/include/xc_dom.h
> @@ -186,11 +186,11 @@ struct xc_dom_image {
> } container_type;
>
> /* HVM specific fields. */
> -xen_pfn_t target_pages;
> -xen_pfn_t mmio_start;
> -xen_pfn_t mmio_size;
> -xen_pfn_t lowmem_end;
> -xen_pfn_t highmem_end;
> +unsigned long target_pages;
> +unsigned long long mmio_start;
> +unsigned long long mmio_size;
> +unsigned long lowmem_end;
> +unsigned long long highmem_end;
>
> /* Extra ACPI tables passed to HVMLOADER */
> struct xc_hvm_firmware_module acpi_module;
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] RFC: Survey on release cycle
On 10/12/2015 07:32 PM, Wei Liu wrote: Please express your preference with -2 (strongly argue against), -1 (not happy but not against), +1 (happy but won't argue for) and +2 (happy and argue for). # 6 months release cycle + current stable release scheme 0 # 6 months release cycle + LTS scheme -1 # 9 months release cycle + current stable release scheme +1 Juergen ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen-netback: corretly check failed allocation
On Thu, 2015-10-15 at 12:26 -0400, Insu Yun wrote:
> Since vzalloc can be failed in memory pressure,
> return value should be checked and return ENOMEM.
>
> Signed-off-by: Insu Yun
> ---
> drivers/net/xen-netback/xenbus.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen
> -netback/xenbus.c
> index 929a6e7..e288246 100644
> --- a/drivers/net/xen-netback/xenbus.c
> +++ b/drivers/net/xen-netback/xenbus.c
> @@ -788,6 +788,11 @@ static void connect(struct backend_info *be)
> /* Use the number of queues requested by the frontend */
> be->vif->queues = vzalloc(requested_num_queues *
> sizeof(struct xenvif_queue));
> + if (!be->vif->queues) {
> +xenbus_dev_fatal(dev, -ENOMEM, "allocating queues");
> +return;
> + }
Please fix the coding style, perhaps using checkpatch.pl or by observing
the surrounding code.
Ian.
> +
> be->vif->num_queues = requested_num_queues;
> be->vif->stalled_queues = requested_num_queues;
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] libxc: fix the types used in xc_dom_image to build HVM guests
El 15/10/15 a les 18.41, Ian Campbell ha escrit: > On Thu, 2015-10-15 at 18:30 +0200, Roger Pau Monne wrote: >> Fix the types used to store the memory parameters of an HVM guest, >> previously they defaulted to unsigned long on 32bit toolstack builds, which >> is wrong because a 32bit value cannot hold a 64bit memory address that >> crosses the 4GB boundary. > > This header includes a xen_paddr_t in it which looks like the appropriate > type for most of these. > > The ones which have units of pages which you've changed from xen_pfn_t to > unsigned long (not long long) should surely remain xen_pfn_t? At least > target_pages should IMHO. > > lowmem_end doesn't strictly need to be 64-bit, but xen_paddr_t seems like > the appropriate type semantically nonetheless. Right, I didn't realize we had a xen_paddr_t type, thanks to Juergen and you for pointing it out. mmio_size is not a paddr, so I'm going to leave it as unsigned long long. Roger. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 1/2] x86/mem-sharing: Bulk mem-sharing entire domains
>
>
> >> > +rc = xsm_mem_sharing_op(XSM_DM_PRIV, d, cd, mso.op);
> >> > +if ( rc )
> >> > +{
> >> > +rcu_unlock_domain(cd);
> >> > +goto out;
> >> > +}
> >> > +
> >> > +if ( !mem_sharing_enabled(cd) )
> >> > +{
> >> > +rcu_unlock_domain(cd);
> >> > +rc = -EINVAL;
> >> > +goto out;
> >> > +}
> >> > +
> >> > +max_sgfn = domain_get_maximum_gpfn(d);
> >> > +max_cgfn = domain_get_maximum_gpfn(cd);
> >> > +
> >> > +if ( max_sgfn != max_cgfn || max_sgfn < mso.u.bulk.start
> )
> >>
> >> Are both domains required to be paused for this operation? If so,
> >> shouldn't you enforce this? If not, by the time you reach the if()
> >> the values are stale.
> >
> > It's expected that the user has exclusive tool-side lock on the domains
> > before issuing this hypercall and that the domains are paused already.
>
> As said - in that case, please enforce this (by bailing if not so).
>
Is there a convenient way to check if a domain is already paused? I can't
seem to find anything of that effect.
Thanks,
Tamas
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen-netback: corretly check failed allocation
On Thu, Oct 15, 2015 at 12:26:16PM -0400, Insu Yun wrote:
> Since vzalloc can be failed in memory pressure,
> return value should be checked and return ENOMEM.
This function doesn't return ENOMEM, instead it writes to xenstore to
indicate error. The commit log needs to be updated.
>
> Signed-off-by: Insu Yun
> ---
> drivers/net/xen-netback/xenbus.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/net/xen-netback/xenbus.c
> b/drivers/net/xen-netback/xenbus.c
> index 929a6e7..e288246 100644
> --- a/drivers/net/xen-netback/xenbus.c
> +++ b/drivers/net/xen-netback/xenbus.c
> @@ -788,6 +788,11 @@ static void connect(struct backend_info *be)
> /* Use the number of queues requested by the frontend */
> be->vif->queues = vzalloc(requested_num_queues *
> sizeof(struct xenvif_queue));
> + if (!be->vif->queues) {
> +xenbus_dev_fatal(dev, -ENOMEM, "allocating queues");
> +return;
> + }
> +
The indentation is wrong. Please configure your email client properly.
And please use "goto err" for error handling -- yes, I understand there
is existing code that returns directly but IMHO that should be fixed
too.
We.
> be->vif->num_queues = requested_num_queues;
> be->vif->stalled_queues = requested_num_queues;
>
> --
> 1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] libxc: fix the types used in xc_dom_image to build HVM guests
On Thu, 2015-10-15 at 18:52 +0200, Roger Pau Monné wrote: > El 15/10/15 a les 18.41, Ian Campbell ha escrit: > > On Thu, 2015-10-15 at 18:30 +0200, Roger Pau Monne wrote: > >> Fix the types used to store the memory parameters of an HVM guest, > >> previously they defaulted to unsigned long on 32bit toolstack > builds, which > >> is wrong because a 32bit value cannot hold a 64bit memory address > that > >> crosses the 4GB boundary. > > > > This header includes a xen_paddr_t in it which looks like the > appropriate > > type for most of these. > > > > The ones which have units of pages which you've changed from > xen_pfn_t to > > unsigned long (not long long) should surely remain xen_pfn_t? At > least > > target_pages should IMHO. > > > > lowmem_end doesn't strictly need to be 64-bit, but xen_paddr_t > seems like > > the appropriate type semantically nonetheless. > > Right, I didn't realize we had a xen_paddr_t type, thanks to Juergen > and > you for pointing it out. mmio_size is not a paddr, so I'm going to > leave > it as unsigned long long. The size of a paddr region can be considered to be a paddr from my PoV. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] libxc: fix the types used in xc_dom_image to build HVM guests
On 15/10/15 18:16, Ian Campbell wrote: > On Thu, 2015-10-15 at 18:52 +0200, Roger Pau Monné wrote: >> El 15/10/15 a les 18.41, Ian Campbell ha escrit: >>> On Thu, 2015-10-15 at 18:30 +0200, Roger Pau Monne wrote: Fix the types used to store the memory parameters of an HVM guest, previously they defaulted to unsigned long on 32bit toolstack >> builds, which is wrong because a 32bit value cannot hold a 64bit memory address >> that crosses the 4GB boundary. >>> This header includes a xen_paddr_t in it which looks like the >> appropriate >>> type for most of these. >>> >>> The ones which have units of pages which you've changed from >> xen_pfn_t to >>> unsigned long (not long long) should surely remain xen_pfn_t? At >> least >>> target_pages should IMHO. >>> >>> lowmem_end doesn't strictly need to be 64-bit, but xen_paddr_t >> seems like >>> the appropriate type semantically nonetheless. >> Right, I didn't realize we had a xen_paddr_t type, thanks to Juergen >> and >> you for pointing it out. mmio_size is not a paddr, so I'm going to >> leave >> it as unsigned long long. > The size of a paddr region can be considered to be a paddr from my PoV. +1. Better to use xen_paddr_t across the board than to mix and match. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2] libxc: fix the types used in xc_dom_image to build HVM guests
Fix the types used to store the memory parameters of an HVM guest,
previously they defaulted to unsigned long on 32bit toolstack builds, which
is wrong because a 32bit value cannot hold a 64bit memory address that
crosses the 4GB boundary.
Signed-off-by: Roger Pau Monné
Cc: Ian Jackson
Cc: Ian Campbell
Cc: Wei Liu
---
I don't have a 32bit Dom0 at hand, so if someone can try to create a HVM
guests using a 32bit toolstack with more than 4GB of RAM it would be
helpful.
---
Changes since v1:
- Use xen_paddr_t for all the physical address related fields.
- Use xen_pfn_t for target_pages.
---
tools/libxc/include/xc_dom.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
index e52b023..7cb6b0c 100644
--- a/tools/libxc/include/xc_dom.h
+++ b/tools/libxc/include/xc_dom.h
@@ -187,10 +187,10 @@ struct xc_dom_image {
/* HVM specific fields. */
xen_pfn_t target_pages;
-xen_pfn_t mmio_start;
-xen_pfn_t mmio_size;
-xen_pfn_t lowmem_end;
-xen_pfn_t highmem_end;
+xen_paddr_t mmio_start;
+xen_paddr_t mmio_size;
+xen_paddr_t lowmem_end;
+xen_paddr_t highmem_end;
/* Extra ACPI tables passed to HVMLOADER */
struct xc_hvm_firmware_module acpi_module;
--
1.9.5 (Apple Git-50.3)
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [ovmf test] 62978: all pass - PUSHED
flight 62978 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/62978/
Perfect :-)
All tests in this flight passed
version targeted for testing:
ovmf bf9f7cea98616e7b780946e61068bd345e454915
baseline version:
ovmf 84db9040cc8ba556faec61ad3480c774ca8b984c
Last test of basis62971 2015-10-15 01:44:12 Z0 days
Testing same since62978 2015-10-15 09:13:57 Z0 days1 attempts
People who touched revisions under test:
Eric Dong
Felix Poludov
Fu Siyuan
Oleksiy Yakovlev
Qiu Shumin
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 pass
test-amd64-i386-xl-qemuu-ovmf-amd64 pass
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
Pushing revision :
+ branch=ovmf
+ revision=bf9f7cea98616e7b780946e61068bd345e454915
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push ovmf
bf9f7cea98616e7b780946e61068bd345e454915
+ branch=ovmf
+ revision=bf9f7cea98616e7b780946e61068bd345e454915
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=ovmf
+ xenbranch=xen-unstable
+ '[' xovmf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.6-testing
+ : tested/2.6.39.x
+ . ./ap-common
++ xenbranch_forqemu=xen-unstable
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
getconfig GitCacheProxy
perl -e '
use Osstest;
readglobalconfig();
print $c{"GitCacheProxy"} or die $!;
'
+++ local cache=git://cache:9419/
+++ '[' xgit://cache:9419/ '!=' x ']'
+++ echo
'git://cache:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[f
Re: [Xen-devel] [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu
On Thu, Oct 15, 2015 at 06:27:17PM +0200, Fabio Fantoni wrote: > Il 14/10/2015 13:06, Stefano Stabellini ha scritto: > >I would suggest Fabio to avoid AHCI disks altogether and just use OVMF > >with PV disks only and Anthony's patch to libxl to avoid creating any > >IDE disks: http://marc.info/?l=xen-devel&m=144482080812353. > > > >Would that work for you? > > Thanks for the advice, I tried it: > https://github.com/Fantu/Xen/commits/rebase/m2r-testing-4.6 > > I installed W10 pro 64 bit with ide disk, installed the win pv drivers and > after changed to xvdX instead hdX, is the only change needed, right? > Initial boot is ok (ovmf part about pv disks seems ok) but windows boot > fails with problem with pv drivers. > In attachment full qemu log with xen_platform trace and domU's xl cfg. > > Someone have windows domUs with ovmf and pv disks only working? If yes can > tell me the difference to understand what can be the problem please? When I worked on the PV disk implementation in OVMF, I was able to boot a Windows 8 with pv disk only. I don't have access to the guest configuration I was using, but I think one difference would be the viridian setting, I'm pretty sure I did not set it. -- Anthony PERARD ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v3 2/2] tests/mem-sharing: Add bulk option to memshrtool
Add the bulk option to the test tool to perform complete deduplication
between domains.
Signed-off-by: Tamas K Lengyel
Cc: Ian Jackson
Cc: Stefano Stabellini
Cc: Ian Campbell
Cc: Wei Liu
Acked-by: Wei Liu
---
tools/tests/mem-sharing/memshrtool.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/tools/tests/mem-sharing/memshrtool.c
b/tools/tests/mem-sharing/memshrtool.c
index 6454bc3..c5e5cb8 100644
--- a/tools/tests/mem-sharing/memshrtool.c
+++ b/tools/tests/mem-sharing/memshrtool.c
@@ -23,6 +23,8 @@ static int usage(const char* prog)
printf(" nominate- Nominate a page for sharing.\n");
printf(" share
\n");
printf(" - Share two pages.\n");
+printf(" bulk \n");
+printf(" - Share all pages between domains.\n");
printf(" unshare - Unshare a page by grabbing a writable
map.\n");
printf(" add-to-physmap
\n");
printf(" - Populate a page in a domain with a
shared page.\n");
@@ -179,6 +181,26 @@ int main(int argc, const char** argv)
}
printf("Audit returned %d errors.\n", rc);
}
+else if( !strcasecmp(cmd, "bulk") )
+{
+domid_t sdomid, cdomid;
+int rc;
+unsigned long shared;
+
+if( argc != 4 )
+return usage(argv[0]);
+
+sdomid = strtol(argv[2], NULL, 0);
+cdomid = strtol(argv[3], NULL, 0);
+rc = xc_memshr_bulk_share(xch, sdomid, cdomid, &shared);
+if ( rc < 0 )
+{
+printf("error executing xc_memshr_bulk_dedup: %s\n",
strerror(errno));
+return rc;
+}
+
+printf("Successfully shared %lu pages between the domains\n", shared);
+}
return 0;
}
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v3 1/2] x86/mem-sharing: Bulk mem-sharing entire domains
Currently mem-sharing can be performed on a page-by-page base from the control
domain. However, when completely deduplicating (cloning) a VM, this requires
at least 3 hypercalls per page. As the user has to loop through all pages up
to max_gpfn, this process is very slow and wasteful.
This patch introduces a new mem_sharing memop for bulk deduplication where
the user doesn't have to separately nominate each page in both the source and
destination domain, and the looping over all pages happen in the hypervisor.
This significantly reduces the overhead of completely deduplicating entire
domains.
Signed-off-by: Tamas K Lengyel
Cc: Ian Jackson
Cc: Stefano Stabellini
Cc: Ian Campbell
Cc: Wei Liu
Cc: George Dunlap
Cc: Keir Fraser
Cc: Jan Beulich
Cc: Andrew Cooper
Acked-by: Wei Liu
---
v3: Bail if domains are not paused
Rename bulk_share struct to just bulk
Return -ENOMEM error if nomination fails
Return total number of shared pages (not keeping separate count)
v2: Stash hypercall continuation start point in xen_mem_sharing_op_t
Return number of successfully shared pages in xen_mem_sharing_op_t
---
tools/libxc/include/xenctrl.h | 15 +++
tools/libxc/xc_memshr.c | 19 +
xen/arch/x86/mm/mem_sharing.c | 99 +++
xen/include/public/memory.h | 12 +-
4 files changed, 144 insertions(+), 1 deletion(-)
diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 3bfa00b..3093a7c 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -2594,6 +2594,21 @@ int xc_memshr_add_to_physmap(xc_interface *xch,
domid_t client_domain,
unsigned long client_gfn);
+/* Allows to deduplicate the entire memory of a client domain in bulk. Using
+ * this function is equivalent of calling xc_memshr_nominate_gfn for each gfn
+ * in the two domains followed by xc_memshr_share_gfns. If successfull,
+ * returns the number of shared pages in 'shared'. Both domains must be paused.
+ *
+ * May fail with -EINVAL if the source and client domain have different
+ * memory size or if memory sharing is not enabled on either of the domains.
+ * May also fail with -ENOMEM if there isn't enough memory available to store
+ * the sharing metadata before deduplication can happen.
+ */
+int xc_memshr_bulk_share(xc_interface *xch,
+ domid_t source_domain,
+ domid_t client_domain,
+ uint64_t *shared);
+
/* Debug calls: return the number of pages referencing the shared frame backing
* the input argument. Should be one or greater.
*
diff --git a/tools/libxc/xc_memshr.c b/tools/libxc/xc_memshr.c
index deb0aa4..d38a6a9 100644
--- a/tools/libxc/xc_memshr.c
+++ b/tools/libxc/xc_memshr.c
@@ -181,6 +181,25 @@ int xc_memshr_add_to_physmap(xc_interface *xch,
return xc_memshr_memop(xch, source_domain, &mso);
}
+int xc_memshr_bulk_share(xc_interface *xch,
+ domid_t source_domain,
+ domid_t client_domain,
+ uint64_t *shared)
+{
+int rc;
+xen_mem_sharing_op_t mso;
+
+memset(&mso, 0, sizeof(mso));
+
+mso.op = XENMEM_sharing_op_bulk_share;
+mso.u.bulk.client_domain = client_domain;
+
+rc = xc_memshr_memop(xch, source_domain, &mso);
+if ( !rc && shared ) *shared = mso.u.bulk.applied;
+
+return rc;
+}
+
int xc_memshr_domain_resume(xc_interface *xch,
domid_t domid)
{
diff --git a/xen/arch/x86/mm/mem_sharing.c b/xen/arch/x86/mm/mem_sharing.c
index a95e105..b398d5a 100644
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -1293,6 +1293,42 @@ int relinquish_shared_pages(struct domain *d)
return rc;
}
+static int bulk_share(struct domain *d, struct domain *cd, unsigned long max,
+ struct mem_sharing_op_bulk *bulk)
+{
+int rc = 0;
+shr_handle_t sh, ch;
+
+while( bulk->start <= max )
+{
+rc = mem_sharing_nominate_page(d, bulk->start, 0, &sh);
+if ( rc == -ENOMEM )
+break;
+else if ( rc )
+goto next;
+
+rc = mem_sharing_nominate_page(cd, bulk->start, 0, &ch);
+if ( rc == -ENOMEM )
+break;
+else if ( rc )
+goto next;
+
+mem_sharing_share_pages(d, bulk->start, sh, cd, bulk->start, ch);
+
+next:
+++(bulk->start);
+
+/* Check for continuation if it's not the last iteration. */
+if ( bulk->start < max && hypercall_preempt_check() )
+{
+rc = 1;
+break;
+}
+}
+
+return rc;
+}
+
int mem_sharing_memop(XEN_GUEST_HANDLE_PARAM(xen_mem_sharing_op_t) arg)
{
int rc;
@@ -1467,6 +1503,69 @@ int
mem_sharing_memop(XEN_GUEST_HANDLE_PARAM(xen_mem_sharing_op_t) arg)
}
break;
+case XENMEM_sharing_op_bulk_share:
+{
+unsig
[Xen-devel] [xen-unstable-smoke test] 62985: tolerable all pass - PUSHED
flight 62985 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/62985/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 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
version targeted for testing:
xen c7e21966e6fe1e8640a4d1cb452118c43e27356d
baseline version:
xen ee653b97ce369decfdd4d18979fd9f6aec0073c2
Last test of basis62960 2015-10-14 10:54:10 Z1 days
Testing same since62985 2015-10-15 16:53:33 Z0 days1 attempts
People who touched revisions under test:
Boris Ostrovsky
Roger Pau Monné
Wei Liu
jobs:
build-amd64 pass
build-armhf pass
build-amd64-libvirt pass
test-armhf-armhf-xl pass
test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
test-amd64-amd64-libvirt pass
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
Pushing revision :
+ branch=xen-unstable-smoke
+ revision=c7e21966e6fe1e8640a4d1cb452118c43e27356d
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push xen-unstable-smoke
c7e21966e6fe1e8640a4d1cb452118c43e27356d
+ branch=xen-unstable-smoke
+ revision=c7e21966e6fe1e8640a4d1cb452118c43e27356d
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-unstable
+ : tested/2.6.39.x
+ . ./ap-common
++ xenbranch_forqemu=xen-unstable
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
getconfig GitCacheProxy
perl -e '
use Osstest;
readglobalconfig();
print $c{"GitCacheProxy"} or die $!;
'
+++ local cache=git://cache:9419/
+++ '[' xgit://cache:9419/ '!=' x ']'
+++ echo
'git://cache:9419/https://github.com/rumpk
Re: [Xen-devel] [PATCH] xen-netback: correctly check failed allocation
I changed patch with valid format.
On Thu, Oct 15, 2015 at 2:02 PM, Insu Yun wrote:
> Since vzalloc can be failed in memory pressure,
> writes -ENOMEM to xenstore to indicate error.
>
> Signed-off-by: Insu Yun
> ---
> drivers/net/xen-netback/xenbus.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/net/xen-netback/xenbus.c
> b/drivers/net/xen-netback/xenbus.c
> index 929a6e7..56ebd82 100644
> --- a/drivers/net/xen-netback/xenbus.c
> +++ b/drivers/net/xen-netback/xenbus.c
> @@ -788,6 +788,12 @@ static void connect(struct backend_info *be)
> /* Use the number of queues requested by the frontend */
> be->vif->queues = vzalloc(requested_num_queues *
> sizeof(struct xenvif_queue));
> + if (!be->vif->queues) {
> + xenbus_dev_fatal(dev, -ENOMEM,
> +"allocating queues");
> + return;
>
I didn't use goto err, because another error handling is not required
> + }
> +
> be->vif->num_queues = requested_num_queues;
> be->vif->stalled_queues = requested_num_queues;
>
> --
> 1.9.1
>
>
--
Regards
Insu Yun
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
