flight 57368 rumpuserxen real [real]
http://logs.test-lab.xenproject.org/osstest/logs/57368/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-rumpuserxen 5 rumpuserxen-build fail REGR. vs. 33866
build-i386-rumpuserxe
flight 57345 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/57345/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf 3 host-install(3) broken REGR. vs. 57312
test-amd64-i386-xl-qem
flight 57335 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/57335/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl 3 host-install(3) broken REGR. vs. 56375
test-armhf-armhf-xl-
On Tue, May 26, 2015 at 12:18 PM, Chong Li wrote:
> On Tue, May 26, 2015 at 4:08 AM, Jan Beulich wrote:
> On 26.05.15 at 02:05, wrote:
>>> Add two hypercalls(XEN_DOMCTL_SCHEDOP_getvcpuinfo/putvcpuinfo) to get/set a
>>> domain's
>>> per-VCPU parameters. Hypercalls are handled by newly added h
flight 57315 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/57315/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-credit2 3 host-install(3) broken REGR. vs. 56831
test-amd64-i386-fre
On 05/26/2015 08:07 PM, Rafael J. Wysocki wrote:
On Tuesday, May 26, 2015 10:32:03 AM Boris Ostrovsky wrote:
On 05/25/2015 10:17 PM, Rafael J. Wysocki wrote:
On Tuesday, May 26, 2015 03:08:17 AM Rafael J. Wysocki wrote:
On Tuesday, May 26, 2015 01:42:16 AM Rafael J. Wysocki wrote:
On Tuesda
On Mon, May 25, 2015 at 09:44:20PM +0100, Julien Grall wrote:
> The read emulation of the register IROUTER contains lots of uncessary
> code as irouter is already valid and doesn't need any processing before
> setting the value in a register.
>
> Also take the opportunity to factorize the code to
Hi Konrad, sorry to bother you again, any comments for this patch ?
Thanks!
Yijing.
On 2015/4/28 17:32, Yijing Wang wrote:
> From: Arnd Bergmann
>
> Use pci_scan_root_bus() instead of deprecated function
> pci_scan_bus_parented().
>
> Signed-off-by: Arnd Bergmann
> Signed-off-by: Yijing Wang
On Tuesday, May 26, 2015 10:32:03 AM Boris Ostrovsky wrote:
> On 05/25/2015 10:17 PM, Rafael J. Wysocki wrote:
> > On Tuesday, May 26, 2015 03:08:17 AM Rafael J. Wysocki wrote:
> >> On Tuesday, May 26, 2015 01:42:16 AM Rafael J. Wysocki wrote:
> >>> On Tuesday, May 26, 2015 01:22:12 AM Rafael J. Wy
flight 57310 linux-3.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/57310/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl 9 debian-install fail REGR. vs. 52209-bisect
test-amd64-amd64-pair
On Tue, May 26, 2015 at 11:56:00AM +0100, David Vrabel wrote:
> On 22/05/15 12:49, Marek Marczykowski-Górecki wrote:
> > Hi all,
> >
> > I'm experiencing xen-netfront crash when doing xl network-detach while
> > some network activity is going on at the same time. It happens only when
> > domU has
"Old" tested version had not actually been tested; therefore in this
flight we test it, rather than a new candidate. The baseline, if
any, is the most recent actually tested revision.
flight 57312 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/57312/
Failures :-/ but no
Reminder: Our project's Document Day for May is tomorrow!
Theme for this month: "No-Can-Do Without a HowTo, Part 2." Last
month, we ended up creating a great new page describing Huge Page
support. Can we top that this month?
We've got a lot of good information in the documentation, but it isn't
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 05/26/2015 11:50 AM, Stefano Stabellini wrote:
> I would go for:
>
> In the event that public disclosure is less than 15 days away, we will
> send a draft with information about the vulnerability to the
> pre-disclosure list as soon as possible,
flight 57304 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/57304/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail REGR. vs. 56492
test-amd64-i386-xl-qemuu-win
flight 57299 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/57299/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-multivcpu 17 leak-check/check fail REGR. vs. 56375
Tests which are fail
Signed-off-by: Daniel De Graaf
---
tools/libxc/xc_flask.c | 12
1 file changed, 12 insertions(+)
diff --git a/tools/libxc/xc_flask.c b/tools/libxc/xc_flask.c
index bb117f7..e24a2e7 100644
--- a/tools/libxc/xc_flask.c
+++ b/tools/libxc/xc_flask.c
@@ -191,6 +191,12 @@ int xc_flask_get
On 05/26/2015 05:34 AM, Jan Beulich wrote:
On 25.05.15 at 11:40, wrote:
I had a look at Osstest's latest xen-unstable run [0]. With Ian's patch
series we finally passed the point of guest creation on x86.
We now have a new set of "avc denied".
May 24 20:18:05.945118 (XEN) avc: denied { get_
Migration and HVM domain creation both trigger AVC denials that should
be allowed in the default policy; add these rules.
Guest console writes need to be either allowed or denied without audit
depending on the decision of the local administrator; introduce a policy
boolean to switch between these
When FLASK_{GET,SET}BOOL is called with a named boolean, the call to
flask_security_resolve_bool is made prior to bool_maxstr being populated
by flask_security_make_bools. This results in the maximum string length
being specified as zero, which is not useful. While it would be
possible to initial
On 05/26/2015 12:24 PM, Jan Beulich wrote:
On 21.05.15 at 19:57, wrote:
@@ -188,27 +189,52 @@ static inline void context_load(struct vcpu *v)
}
}
-static void amd_vpmu_load(struct vcpu *v)
+static int amd_vpmu_load(struct vcpu *v, bool_t from_guest)
{
struct vpmu_struct *vpm
From: Malcolm Crossley
Performance analysis of aggregate network throughput with many VMs
shows that performance is signficantly limited by contention on the
maptrack lock when obtaining/releasing maptrack handles from the free
list.
Instead of a single free list use a per-VCPU list. This avoids
The series builds on the original series by Matt Wilson and Christoph
Egger from Amazon.
Performance results for aggregate intrahost network throughput
(between 20 VM pairs, with 16 dom0 VCPUs) show substantial
improvements.
Throughput/Gbit/s
Base
In combination with the per-active entry locks, the grant table lock
can be made a read-write lock since the majority of cases only the
read lock is required. The grant table read lock protects against
changes to the table version or size (which are done with the write
lock held).
The write lock i
Split grant table lock into two separate locks. One to protect
maptrack state (maptrack_lock) and one for everything else (lock).
Based on a patch originally by Matt Wilson .
Signed-off-by: David Vrabel
---
docs/misc/grant-tables.txt|9 +
xen/common/grant_table.c |9 +++
Introduce a per-active entry spin lock to protect active entry state
The grant table lock must be locked before acquiring (locking) an
active entry.
This is a step in reducing contention on the grant table lock, but
will only do so once the grant table lock is turned into a read-write
lock.
Based
On Fri, May 22, 2015 at 5:21 AM, Juergen Gross wrote:
> On 05/21/2015 07:07 PM, George Dunlap wrote:
>>
>> We have several outstanding patch series which add devices that have
>> two levels: a controller and individual devices attached to that
>> controller.
>>
>> In the interest of consistency, t
On 05/26/2015 12:13 PM, Jan Beulich wrote:
On 21.05.15 at 19:57, wrote:
+ * guest when PMU_CACHED bit in pmu_flags is set (which is done by the
+ * hypervisor during PMU interrupt). Hypervisor will read updated data in
+ * XENPMU_flush hypercall and clear PMU_CACHED bit.
+ */
+struct xen_pmu_a
On Thu, 21 May 2015, Jan Beulich wrote:
> >>> On 21.05.15 at 12:34, wrote:
> > On 21/05/15 07:22, Jan Beulich wrote:
> >> The linked to document (on our wiki) is versioned 0.,
> >> which doesn't look like a final stable version. The same applies to
> >> the other (STAO?) one.
> >
> > That's a mis
On Fri, May 22, 2015 at 02:23:41AM +0200, Luis R. Rodriguez wrote:
> On Thu, May 21, 2015 at 05:33:21PM -0500, Bjorn Helgaas wrote:
> >
> > I tentatively put this (and the rest of the series) on a pci/resource
> > branch. I'm hoping you'll propose some clarification about
> > EXPORT_SYMBOL_GPL().
On 24/05/2015 09:16, Parth Dixit wrote:
On 21 May 2015 at 17:11, Julien Grall mailto:julien.gr...@citrix.com>> wrote:
On 21/05/15 12:38, Jan Beulich wrote:
On 21.05.15 at 12:52, mailto:julien.gr...@citrix.com>> wrote:
>> On 21/05/15 11:46, Jan Beulich wrote:
>> On 21
On Tue, May 26, 2015 at 4:08 AM, Jan Beulich wrote:
On 26.05.15 at 02:05, wrote:
>> Add two hypercalls(XEN_DOMCTL_SCHEDOP_getvcpuinfo/putvcpuinfo) to get/set a
>> domain's
>> per-VCPU parameters. Hypercalls are handled by newly added hook
>> (.adjust_vcpu) in the
>> scheduler interface.
>>
>
On Tue, 26 May 2015, Major Hayden wrote:
> On 05/26/2015 07:15 AM, Stefano Stabellini wrote:
> > On Fri, 22 May 2015, Major Hayden wrote:
> >> > On 05/22/2015 09:04 AM, Jan Beulich wrote:
> >>> > > If you were to ask for this only if the time gap until embargo expiry
> >>> > > was less than the def
>>> On 26.05.15 at 18:21, wrote:
> On 05/26/2015 06:47 PM, Jan Beulich wrote:
> On 25.05.15 at 10:33, wrote:
>>> --- a/xen/arch/x86/hvm/event.c
>>> +++ b/xen/arch/x86/hvm/event.c
>>> @@ -19,6 +19,7 @@
>>> * Place - Suite 330, Boston, MA 02111-1307 USA.
>>> */
>>>
>>> +#include
>>> #incl
>>> On 21.05.15 at 19:57, wrote:
> @@ -188,27 +189,52 @@ static inline void context_load(struct vcpu *v)
> }
> }
>
> -static void amd_vpmu_load(struct vcpu *v)
> +static int amd_vpmu_load(struct vcpu *v, bool_t from_guest)
> {
> struct vpmu_struct *vpmu = vcpu_vpmu(v);
> -struct
On 05/26/2015 06:47 PM, Jan Beulich wrote:
On 25.05.15 at 10:33, wrote:
>> --- a/xen/arch/x86/hvm/event.c
>> +++ b/xen/arch/x86/hvm/event.c
>> @@ -19,6 +19,7 @@
>> * Place - Suite 330, Boston, MA 02111-1307 USA.
>> */
>>
>> +#include
>> #include
>> #include
>
> Just like almost ever
>>> On 21.05.15 at 19:57, wrote:
> +/* Masks used for testing whether and MSR is valid */
> +#define ARCH_CTRL_MASK (~((1ull << 32) - 1) | (1ull << 21))
Considering this and ...
> @@ -556,7 +558,7 @@ static int core2_vpmu_do_wrmsr(unsigned int msr, uint64_t
> msr_content,
> struct
>>> On 21.05.15 at 19:57, wrote:
> --- a/xen/include/public/arch-arm.h
> +++ b/xen/include/public/arch-arm.h
> @@ -434,6 +434,11 @@ struct xen_arch_domainconfig {
>
> #endif
>
> +#ifndef __ASSEMBLY__
> +/* Stub definition of PMU structure */
> +typedef struct xen_pmu_arch {} xen_pmu_arch_t;
On Tue, 2015-05-26 at 17:38 +0200, Lengyel, Tamas wrote:
> Hi all,
>
> I'm wondering if someone can point me in the right direction. I'm
> trying to understand the process around domain save/restore using XL.
> I can see the xl save format and how its appended with the QEMU state
> aquired via the
>>> On 25.05.15 at 10:33, wrote:
> --- a/xen/arch/x86/hvm/event.c
> +++ b/xen/arch/x86/hvm/event.c
> @@ -19,6 +19,7 @@
> * Place - Suite 330, Boston, MA 02111-1307 USA.
> */
>
> +#include
> #include
> #include
Just like almost everywhere else, please have asm/ includes follow
xen/ ones.
On 05/26/2015 07:15 AM, Stefano Stabellini wrote:
> On Fri, 22 May 2015, Major Hayden wrote:
>> > On 05/22/2015 09:04 AM, Jan Beulich wrote:
>>> > > If you were to ask for this only if the time gap until embargo expiry
>>> > > was less than the default of two weeks, maybe I would buy this.
>> >
>>
Hi all,
I'm wondering if someone can point me in the right direction. I'm trying to
understand the process around domain save/restore using XL. I can see the
xl save format and how its appended with the QEMU state aquired via the
xen-save-devices-state qmp command (this is for upstream QEMU).
Howe
Hi Parth,
On 17/05/2015 22:03, Parth Dixit wrote:
@@ -307,6 +308,54 @@ DT_DEVICE_START(pl011, "PL011 UART", DEVICE_SERIAL)
.init = dt_pl011_uart_init,
DT_DEVICE_END
+#ifdef CONFIG_ACPI
+static int __init acpi_pl011_uart_init(const void *data)
+{
+struct pl011 *uart;
+acpi_st
Hi Chen,
On 23/05/2015 15:52, Chen Baozi wrote:
From: Chen Baozi
This patch does the same thing as the previous one but for dom0 kernel.
Please be explicit, the 2 patches may not be contiguous in Xen upstream.
Signed-off-by: Chen Baozi
---
xen/arch/arm/domain_build.c | 11 ---
Hi Chen,
On 23/05/2015 15:52, Chen Baozi wrote:
From: Chen Baozi
Linux kernel sometimes uses the 'hwid' which is fetched from DT node
of CPU as the MPIDR. We set the logical CPUID in the corresponding DT
node to MPIDR to keep consistency.
Hmmm... this is wrong. The field "reg" in the DT cont
Hi Chen,
On 23/05/2015 15:52, Chen Baozi wrote:
From: Chen Baozi
Since the size of GICR is determined by the number of CPU
cores, add 'nr_cpus' parameter when creating its DT node
and set gicr0_size dynamically.
This patch is not necessary, the re-distributor region can be bigger
without an
Hi Chen,
On 23/05/2015 15:52, Chen Baozi wrote:
From: Chen Baozi
Use the AFF1 value of ICC_SGI1R_EL1 when injecting SGI in vGIC,
which expands the number of supported vCPU more than 16 that
target list bitmap can hold independently.
Signed-off-by: Chen Baozi
---
xen/arch/arm/vgic.c | 10 ++
On 05/25/2015 10:17 PM, Rafael J. Wysocki wrote:
On Tuesday, May 26, 2015 03:08:17 AM Rafael J. Wysocki wrote:
On Tuesday, May 26, 2015 01:42:16 AM Rafael J. Wysocki wrote:
On Tuesday, May 26, 2015 01:22:12 AM Rafael J. Wysocki wrote:
On Friday, May 22, 2015 09:53:37 PM Boris Ostrovsky wrote:
From: Konrad Rzeszutek Wilk
This patch has been added to the 3.12 stable tree. If you have any
objections, please let us know.
===
commit a6dfa128ce5c414ab46b1d690f7a1b8decb8526d upstream.
A huge amount of NIC drivers use the DMA API, however if
compiled under 32-bit an very import
>>> On 13.05.16 at 09:51, wrote:
> The intel_pstate driver receives percentage values to set the
> performance limits. This patch adds interfaces to support the
> input of percentage values to control the intel_pstate driver.
> Also, the "get-cpufreq-para" is modified to show percentage
> based fe
>>> On 26.05.15 at 15:32, wrote:
> --- a/xen/arch/arm/p2m.c
> +++ b/xen/arch/arm/p2m.c
> @@ -1709,9 +1709,9 @@ bool_t p2m_mem_access_check(paddr_t gpa, vaddr_t gla,
> const struct npfec npfec)
>
> /*
> * Set access type for a region of pfns.
> - * If start_pfn == -1ul, sets the default acces
>>> On 13.05.16 at 09:51, wrote:
> --- a/xen/drivers/acpi/pmstat.c
> +++ b/xen/drivers/acpi/pmstat.c
> @@ -167,7 +167,7 @@ int do_get_pm_info(struct xen_sysctl_get_pmstat *op)
> * 2. Provide user PM control
> */
> static int read_scaling_available_governors(char
> *scaling_available_governor
On Tue, 2015-05-26 at 13:52 +, Mazen Ezzeddine (Student) wrote:
> I followed the instructions on
> ssup2.iptime.org/wiki/Xen_4.5.0_on_Arndale
> just replacing saucy with trusty (section 11-12) without setting any passwd?
> any hint please?
Please don't top post.
Any default password will be
Thanks,
Last time I did not set any passwd. In all cases, I will recompile/rebuild and
report.
Thank you so much.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
>>> On 13.05.16 at 09:51, wrote:
> --- a/xen/arch/x86/acpi/cpufreq/cpufreq.c
> +++ b/xen/arch/x86/acpi/cpufreq/cpufreq.c
> @@ -650,9 +650,12 @@ static int __init cpufreq_driver_init(void)
> int ret = 0;
>
> if ((cpufreq_controller == FREQCTL_xen) &&
> -(boot_cpu_data.x86_vendor
On 26/05/2015 15:52, Mazen Ezzeddine (Student) wrote:
I followed the instructions on
ssup2.iptime.org/wiki/Xen_4.5.0_on_Arndale
just replacing saucy with trusty (section 11-12) without setting any passwd?
any hint please?
If you followed section 11-12 step by step you set the password your
>>> On 13.05.16 at 09:50, wrote:
> +static inline int ceiling_fp(int32_t x)
> +{
> +int mask, ret;
Please here and below, consider whether types really need to be
signed. One exception: If you intend to import the Linux source file
with minimal modifications, and if that indeed results in onl
I followed the instructions on
ssup2.iptime.org/wiki/Xen_4.5.0_on_Arndale
just replacing saucy with trusty (section 11-12) without setting any passwd?
any hint please?
Thank you so much.
From: Julien Grall
Sent: Tuesday, May 26, 2015 4:46 PM
To: Mazen E
flight 57289 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/57289/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-rumpuserxen-amd64 15
rumpuserxen-demo-xenstorels/xenstorels.repeat fail REGR. vs. 5
Thanks Julien,
I added the hvc0 config file but now I can see the typed characthers on the
console, but I still can not login, what is the default login, I tried several
alternatives but still not able to login. I am missing something?
Thank you so much.
Regards,
___
On Tue, 2015-05-26 at 14:11 +0100, Jan Beulich wrote:
> >>> On 26.05.15 at 14:56, wrote:
> > On Tue, 2015-05-26 at 13:25 +0100, Jan Beulich wrote:
> >> >>> On 26.05.15 at 13:14, wrote:
> >> > --- a/xen/arch/x86/domctl.c
> >> > +++ b/xen/arch/x86/domctl.c
> >> > @@ -856,13 +856,16 @@ long arch_do_
On 26/05/2015 15:40, Mazen Ezzeddine (Student) wrote:
Thanks Julien,
I added the hvc0 config file but now I can see the typed characthers on the
console, but I still can not login, what is the default login, I tried several
alternatives but still not able to login. I am missing something
'pfn' and 'start_pfn' are ambiguous, both these functions expect GFNs as input.
On x86 the interface of p2m_set_mem_access() in p2m.c doesn't match the
declaration in p2m-common.h as 'pfn' is being used instead of 'start_pfn'.
On ARM both p2m_set_mem_access and p2m_get_mem_access interfaces don't
On Wed, 2015-05-20 at 10:56 +0100, Ian Campbell wrote:
> On Wed, 2015-05-20 at 09:34 +, osstest service user wrote:
> > flight 56759 xen-unstable real [real]
> > http://logs.test-lab.xenproject.org/osstest/logs/56759/
> >
> > Regressions :-(
> >
> > Tests which did not succeed and are blockin
>>> On 13.05.16 at 09:50, wrote:
> +extern int cpufreq_register_driver(struct cpufreq_driver *driver_data);
> +extern int cpufreq_unregister_driver(struct cpufreq_driver *driver);
Oh, btw, please also get rid of "extern" on function declarations,
unless in a particular header it is consistently b
>>> On 26.05.15 at 14:56, wrote:
> On Tue, 2015-05-26 at 13:25 +0100, Jan Beulich wrote:
>> >>> On 26.05.15 at 13:14, wrote:
>> > --- a/xen/arch/x86/domctl.c
>> > +++ b/xen/arch/x86/domctl.c
>> > @@ -856,13 +856,16 @@ long arch_do_domctl(
>> > ret = -EINVAL;
>> > else
>> >
>>> On 13.05.16 at 09:50, wrote:
> Register/unregister the CPU hotplug notifier when the driver is
> registered, and move the driver register/unregister function to
> the cpufreq.c.
Without saying why I'm afraid I don't even see much reason to
review this in any detail.
> --- a/xen/drivers/cpufr
flight 57291 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/57291/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt 11 guest-start fail REGR. vs. 53854
test-amd64-amd64-libvirt
On Thu, 2015-05-21 at 05:37 -0700, Manish Jaggi wrote:
>
> On Tuesday 19 May 2015 07:18 AM, Ian Campbell wrote:
> > On Tue, 2015-05-19 at 19:34 +0530, Vijay Kilari wrote:
> >> On Tue, May 19, 2015 at 7:24 PM, Ian Campbell
> >> wrote:
> >>> On Tue, 2015-05-19 at 14:36 +0100, Ian Campbell wrote:
>
>>> On 13.05.16 at 09:50, wrote:
> --- a/xen/drivers/cpufreq/utility.c
> +++ b/xen/drivers/cpufreq/utility.c
> @@ -456,6 +456,11 @@ int __cpufreq_set_policy(struct cpufreq_policy *data,
>
> data->min = policy->min;
> data->max = policy->max;
> +data->min_perf_pct = policy->min_perf
On Tue, 2015-05-26 at 13:25 +0100, Jan Beulich wrote:
> >>> On 26.05.15 at 13:14, wrote:
> > --- a/xen/arch/x86/domctl.c
> > +++ b/xen/arch/x86/domctl.c
> > @@ -856,13 +856,16 @@ long arch_do_domctl(
> > ret = -EINVAL;
> > else
> > {
> > +xen_guest_tsc_in
flight 57288 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/57288/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-freebsd10-amd64 18 guest-start.2 fail in 57141 REGR. vs. 56831
Tests which are fai
>>> On 13.05.16 at 09:50, wrote:
> The unregister notifier function is needed to support cpu hotplug.
Without loadable module support I have some difficulty seeing why
this should be needed.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http
>>> On 13.05.16 at 09:49, wrote:
> The added calculation related functions will be used in the intel_pstate.c.
If these are taken from Linux, please say so here (including the version
they got cloned from), as in that case close review can be considered
unnecessary. That said - do you really need
On 26/05/2015 08:57, Mazen Ezzeddine (Student) wrote:
Dear experts,
Hi,
I am running Xen 4.5 on the arndale 5250 by compiling u-boot, Xen, Linux
kernel(3.18.3) and filesystem (ubuntu Trusty). Boot messages of Xen and kernel
are fine and Dom0 is booted. However, I see the below login me
>>> On 13.05.16 at 09:49, wrote:
> --- a/xen/arch/x86/cpu/common.c
> +++ b/xen/arch/x86/cpu/common.c
> @@ -45,6 +45,45 @@ unsigned int paddr_bits __read_mostly = 36;
> */
> u64 host_pat = 0x050100070406;
>
> +/*
> + * x86_match_cpu - match the current CPU against an array of
> + * x86_cpu_ids
>>> On 26.05.15 at 13:14, wrote:
> --- a/xen/arch/x86/domctl.c
> +++ b/xen/arch/x86/domctl.c
> @@ -856,13 +856,16 @@ long arch_do_domctl(
> ret = -EINVAL;
> else
> {
> +xen_guest_tsc_info_t info = { 0 };
> +
> domain_pause(d);
> -
On 26/05/15 12:14, Ian Campbell wrote:
> There is no need to have this twice and we can simply inline
> xen_guest_tsc_info into xen_domctl_tsc_info as well.
>
> Signed-off-by: Ian Campbell
Nice diffstat.
Reviewed-by: Andrew Cooper
> ---
> ---
> tools/libxc/xc_domain.c | 23 -
On Fri, 22 May 2015, Major Hayden wrote:
> On 05/22/2015 09:04 AM, Jan Beulich wrote:
> > If you were to ask for this only if the time gap until embargo expiry
> > was less than the default of two weeks, maybe I would buy this.
>
> I'm good with that as well. I think we're saying:
>
> if embar
>>> On 23.05.15 at 03:33, wrote:
> --- a/docs/misc/xen-command-line.markdown
> +++ b/docs/misc/xen-command-line.markdown
> @@ -1185,6 +1185,19 @@ Specify the host reboot method.
> 'efi' instructs Xen to reboot using the EFI reboot call (in EFI mode by
> default it will use that method first).
>
On Mon, 2015-05-25 at 15:41 +0200, Mr Idris wrote:
> On 5/21/15, Dario Faggioli wrote:
> > ret.time is the next time instant you want a timer to fire, as you can
> > see right below the call do sched->do_schedule(), in schedule.c. That
> > timer, when firing, will cause the scheduler to run again
In order that xencommons is guarenteed to have been started before
libvirtd. Otherwise sometimes libvirt can be started first resulting
in:
error: invalid argument: unsupported config type xen-xl
Because xen wasn't available when libvirt started.
Signed-off-by: Ian Campbell
---
ts-libvi
On Tue, 2015-05-26 at 17:08 +0800, longtao.pang wrote:
>
> Ian Campbell (1):
> grub: remove patch to disable submenu from 20_linux_xen overlay
> longtao.pang (6):
> Parsing grub which has 'submenu' primitive
> Change
flight 57283 linux-3.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/57283/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl 9 debian-install fail REGR. vs. 52209-bisect
test-amd64-amd64-pair
>>> On 23.05.15 at 03:33, wrote:
> From: Elena Ufimtseva
>
> In preparation for auxiliary RMRR data provided on Xen
> command line, make RMRR adding a separate function.
> Also free memery for rmrr device scope in error path.
>
> Signed-off-by: Elena Ufimtseva
Reviewed-by: Jan Beulich
>>> On 23.05.15 at 03:33, wrote:
> --- a/xen/drivers/pci/pci.c
> +++ b/xen/drivers/pci/pci.c
> @@ -119,11 +119,21 @@ const char *__init parse_pci(const char *s, unsigned
> int *seg_p,
> unsigned int *bus_p, unsigned int *dev_p,
> unsigne
In 38b37ed82705 "x86/domctl: cleanup", XEN_DOMCTL_gettscinfo was
changed to use the standard copyback mechanism.
However the output TSC Info is a guerst handle, i.e. a pointer to the
location for the information, copyback just copies the unchanged
pointer back.
Switch back to fetching the details
There is no need to have this twice and we can simply inline
xen_guest_tsc_info into xen_domctl_tsc_info as well.
Signed-off-by: Ian Campbell
---
---
tools/libxc/xc_domain.c | 23 ---
xen/arch/x86/domctl.c | 21 +
xen/include/public/domctl.h
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 05/25/2015, 02:56 AM, Ben Hutchings wrote:
> This fix appears to be needed in all stable branches:
>
> commit a6dfa128ce5c414ab46b1d690f7a1b8decb8526d Author: Konrad
> Rzeszutek Wilk Date: Fri Apr 17 15:04:48
> 2015 -0400
>
> config: Enable N
On 22/05/15 12:49, Marek Marczykowski-Górecki wrote:
> Hi all,
>
> I'm experiencing xen-netfront crash when doing xl network-detach while
> some network activity is going on at the same time. It happens only when
> domU has more than one vcpu. Not sure if this matters, but the backend
> is in anot
On 26/05/15 11:18, Ian Campbell wrote:
> On Tue, 2015-05-26 at 11:13 +0100, Andrew Cooper wrote:
>> On 26/05/15 11:04, Ian Campbell wrote:
>>> In 38b37ed82705 "x86/domctl: cleanup", XEN_DOMCTL_gettscinfo was
>>> changed to use the standard copyback mechanism.
>>>
>>> However the output TSC Info is
On Tue, 2015-05-26 at 11:13 +0100, Andrew Cooper wrote:
> On 26/05/15 11:04, Ian Campbell wrote:
> > In 38b37ed82705 "x86/domctl: cleanup", XEN_DOMCTL_gettscinfo was
> > changed to use the standard copyback mechanism.
> >
> > However the output TSC Info is a guerst handle, i.e. a pointer to the
> >
On 26/05/15 10:58, Jan Beulich wrote:
On 26.05.15 at 09:34, wrote:
>> 'gfn' is not defined in p2m_get_mem_access() and this code compiles only
>> because of a coincidence: gfn_lock/gfn_unlock are currently macros which
>> don't use their second argument.
>>
>> Signed-off-by: Vitaly Kuznetsov
On 26/05/15 11:04, Ian Campbell wrote:
> In 38b37ed82705 "x86/domctl: cleanup", XEN_DOMCTL_gettscinfo was
> changed to use the standard copyback mechanism.
>
> However the output TSC Info is a guerst handle, i.e. a pointer to the
> location for the information, copyback just copies the unchanged
>
In 38b37ed82705 "x86/domctl: cleanup", XEN_DOMCTL_gettscinfo was
changed to use the standard copyback mechanism.
However the output TSC Info is a guerst handle, i.e. a pointer to the
location for the information, copyback just copies the unchanged
pointer back.
Switch back to fetching the details
On 05/25/15 03:50, lidonglin wrote:
> Hi all:
> Recentlly, I want to use PXE boot on Xen with OVMF as bios. At
> beginning, I just add rtl8139 as guest nic device, and I compile a
> release ovmf. When I enter into uefi, I can't find network boot menu.
> According to edk2/OvmfPkg/README file, I kno
On Tue, 2015-05-26 at 09:45 +0200, HANNAS YAYA Issa wrote:
> Hi
> I compile and install linux kernel 3.4 but when booting I don't see
> this kernel in the grub submenu of xen version 4.2.0.
> Does it means that there is a minimum version of linux kernel that xen
> 4.2.0 can supprort?
This is the
>>> On 26.05.15 at 09:34, wrote:
> 'gfn' is not defined in p2m_get_mem_access() and this code compiles only
> because of a coincidence: gfn_lock/gfn_unlock are currently macros which
> don't use their second argument.
>
> Signed-off-by: Vitaly Kuznetsov
> ---
> xen/arch/x86/mm/p2m.c | 4 ++--
>
>>> On 23.05.15 at 03:27, wrote:
> @@ -318,13 +321,13 @@ static int __init acpi_parse_dev_scope(
> if ( (cnt = scope_device_count(start, end)) < 0 )
> return cnt;
>
> -scope->devices_cnt = cnt;
> if ( cnt > 0 )
> {
> scope->devices = xzalloc_array(u16, cnt);
>>> On 25.05.15 at 11:40, wrote:
> I had a look at Osstest's latest xen-unstable run [0]. With Ian's patch
> series we finally passed the point of guest creation on x86.
>
> We now have a new set of "avc denied".
>
> May 24 20:18:05.945118 (XEN) avc: denied { get_vnumainfo } for domid=1
> sco
1 - 100 of 129 matches
Mail list logo
