This run is configured for baseline tests only.
flight 44266 xen-4.3-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/44266/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf
I need a diagram that show Xen components or a document that explained it.
On Sunday, March 20, 2016 2:04 PM, Daniele Palumbo wrote:
Il giorno 20/mar/2016, alle ore 20:11, Jason Long ha
scritto:
> any idea?
FAQ?
___
Xen-devel mailing list
Xen-dev
Priya,
so for the delay: wasn't checking my mail on the weekend. Also adding Jesus and
Daniel
> On 19 Mar 2016, at 09:54, Priya wrote:
>
> Hello Lars Kurth,
>
> I'm Priya V, a final year Computer Science student from Amrita University,
> India. I came across this project on 'Improving Code R
Paulina,
Roger was on vacation last week. He is back now. Given that most of our
possible applicants, started to engage with the project very late, I will
investigate what the best way forward is
Regards
Lars
> On 17 Mar 2016, at 19:33, Paulina Szubarczyk
> wrote:
>
> Hi Roger,
>
> I am int
flight 86715 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/86715/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-rumpuserxen6 xen-build fail REGR. vs. 59254
build-amd64-rumpuserx
On Sat, Mar 19, Wei Liu wrote:
> My assessment of the pending patch: that's two thousand lines of code in
> a single patch, which potentially requires quite a few iterations to get
> right. Furthermore its prerequisite PVUSB was only merged yesterday,
> which has its own defects that needs sorting
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of
> Wei Liu
> Sent: 18 March 2016 12:07
> To: Xen-devel
> Cc: jgr...@suse.com; Lars Kurth; xiecl.f...@cn.fujitsu.com; Wei Liu;
> quan...@intel.com; we...@cn.fujitsu.com; George Dunlap; Andrew
> Cooper
Hi Julien,
On Fri, Mar 18, 2016 at 10:53 PM, Julien Grall wrote:
>
>
> On 18/03/16 15:01, Dushyant Behl wrote:
>>
>> Hi Julien,
>
>
> Hi Dushyant,
>
>> On Thu, Mar 17, 2016 at 8:22 PM, Julien Grall
>> wrote:
>>>
>>> On 14/03/16 14:19, Dushyant Behl wrote:
>
> Yes, I have enabled these co
Hi Lars,
Thank you for your answer. I am looking forward to further information
from you.
Thanks and regards
,
Paulina Szubarczyk
On 21 March 2016 at 10:57, Lars Kurth wrote:
> Paulina,
> Roger was on vacation last week. He is back now. Given that most of our
> possible applicants, started
Hi folks,
I saw that you have a few people who are interested in Outreachy. However, some
of our applicants highlighted their interest late. The following information is
relevant and important.
> 3) Applicants can complete their required contribution past the application
> deadline. This is es
> On 20 Mar 2016, at 21:04, Daniele Palumbo wrote:
>
> Il giorno 20/mar/2016, alle ore 20:11, Jason Long ha
> scritto:
>> any idea?
>
> FAQ?
See
http://wiki.xenproject.org/wiki/Xen_Project_Software_Overview
as well as several presentations on slideshare ... e.g.
http://www.slideshare.net/xe
flight 86723 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/86723/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail
REGR. vs. 86454
test
>>> On 18.03.16 at 18:26, wrote:
> On Fri, Mar 18, 2016 at 05:55:55AM -0600, Jan Beulich wrote:
>> >>> On 15.03.16 at 18:56, wrote:
>> > @@ -223,12 +224,15 @@ void __init do_initcalls(void)
>> > /*
>> > * Simple hypercalls.
>> > */
>> > -
>> > DO(xen_version)(int cmd, XEN_GUEST_HANDLE_PARAM
Hi Lasya, (adding xen-devel@)
> On 21 Mar 2016, at 11:17, Lasya Venneti wrote:
>
> Hi Lars, Jesus!
>
> This is Lasya from India, if you recall. I had worked with Xen before the
> last Outreachy round, however I could not get selected for the same as the
> program rules had changed and they wa
>>> On 18.03.16 at 19:32, wrote:
> Ian Jackson writes ("Re: [xen-4.3-testing test] 86445: regressions - trouble:
> blocked/broken/fail/pass"):
>> Jan Beulich writes ("Re: [xen-4.3-testing test] 86445: regressions -
>> trouble:
> blocked/broken/fail/pass"):
>> > But these have been recurring thr
flight 44268 distros-debian-sid real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/44268/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvops 4 capture-logs !broken [st=
On 03/18/2016 08:12 PM, Andrew Cooper wrote:
> On 17/03/16 16:12, Joao Martins wrote:
>> This field has two possible flags (as of latest pvclock ABI
>> shared with KVM).
>>
>> flags: bits in this field indicate extended capabilities
>> coordinated between the guest and the hypervisor. Specifical
On 03/18/2016 08:21 PM, Andrew Cooper wrote:
> On 17/03/16 16:12, Joao Martins wrote:
>> Introduce support for using TSC as platform time which is the highest
>> resolution time and most performant to get (~20 nsecs). Though there
>> are also several problems associated with its usage, and there
On 21/03/16 11:42, Joao Martins wrote:
>
> On 03/18/2016 08:12 PM, Andrew Cooper wrote:
>> On 17/03/16 16:12, Joao Martins wrote:
>>> This field has two possible flags (as of latest pvclock ABI
>>> shared with KVM).
>>>
>>> flags: bits in this field indicate extended capabilities
>>> coordinated be
On 03/18/2016 08:32 PM, Andrew Cooper wrote:
> On 17/03/16 16:12, Joao Martins wrote:
>> And use to initialize platform time solely for clocksource=tsc,
>> as opposed to initializing platform overflow timer, which would
>> only fire in ~180 years (on 2.2 Ghz Broadwell processor).
>>
>> Signed-off
On 03/18/2016 08:34 PM, Andrew Cooper wrote:
> On 17/03/16 16:12, Joao Martins wrote:
>> To fetch the last read from the clocksource which was used to
>> calculate system_time. In the case of clocksource=tsc we will
>> use it to set tsc_timestamp.
>>
>> Signed-off-by: Joao Martins
>
> Again, ju
On 03/18/2016 08:58 PM, Andrew Cooper wrote:
> On 17/03/16 16:12, Joao Martins wrote:
>> When using TSC as clocksource we will solely rely on TSC for updating
>> vcpu time infos (pvti). Right now, each vCPU takes the tsc_timestamp at
>> different instants meaning every EPOCH + delta. This delta i
On 03/21/2016 11:43 AM, Andrew Cooper wrote:
> On 21/03/16 11:42, Joao Martins wrote:
>>
>> On 03/18/2016 08:12 PM, Andrew Cooper wrote:
>>> On 17/03/16 16:12, Joao Martins wrote:
This field has two possible flags (as of latest pvclock ABI
shared with KVM).
flags: bits in this
(Strip the CC list)
On 19/03/2016 05:45, Shannon Zhao wrote:
On 2016年03月18日 20:07, Wei Liu wrote:
Hi all
Today is that last posting day for new features. And we are two weeks
away from the anticipated freeze date.
I've gone through the outstanding patch series on the list and ask for
input fr
>>> On 18.03.16 at 19:56, wrote:
> On 18/03/16 16:57, Jan Beulich wrote:
> On 15.03.16 at 16:35, wrote:
>>> +XEN_CPUFEATURE(MTRR, 0*32+12) /*S Memory Type Range Registers */
>> I thin I've said so before - this alters current behavior
>
> Again, no it doesn't. PV DomU's don't get
On Thu, Mar 17, 2016 at 4:08 PM, Ian Jackson wrote:
> Konrad Rzeszutek Wilk writes ("[PATCH v4 08/34] vmap: Make the while loop
> less fishy."):
>> error:
>> -while ( i-- )
>> -free_domheap_page(mfn_to_page(mfn_x(mfn[i])));
>> +while ( i )
>> +free_domheap_page(mfn_to_pa
Hi Doug,
Can you please help on questions/problems where I am stuck?
Deadline for applying for outreachy is coming closer.
Regards,
Sabiya
Hi Doug,
I am done with building of xen source.Now, I have started looking
at source files and identifying changes required for given task.
As you
Hi Shannon,
On 17/03/2016 09:40, Shannon Zhao wrote:
From: Shannon Zhao
These tables are aligned with 64bit.
Signed-off-by: Shannon Zhao
---
xen/arch/arm/acpi/lib.c| 15 +++
xen/include/asm-arm/acpi.h | 2 ++
2 files changed, 17 insertions(+)
diff --git a/xen/arch/arm/a
>>> On 21.03.16 at 07:18, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: Friday, March 18, 2016 5:49 PM
>>
>> >>> On 18.03.16 at 10:38, wrote:
>> > On Fri, 2016-03-18 at 03:29 -0600, Jan Beulich wrote:
>> >> >
>> >> Not sure what exactly you're asking for: As said, we first nee
On some hardware models (e.g. Dell Studio 1555 laptop) some hardware
related functions (e.g. SMIs) are to be executed on physical cpu 0
only. Instead of open coding such a functionality multiple times in
the kernel add a service function for this purpose. This will enable
the possibility to take sp
Use the smp_call_sync_on_phys_cpu() function to call system management
mode on cpu 0.
Signed-off-by: Juergen Gross
---
drivers/hwmon/dell-smm-hwmon.c | 27 ---
1 file changed, 12 insertions(+), 15 deletions(-)
diff --git a/drivers/hwmon/dell-smm-hwmon.c b/drivers/hwmon/d
Some hardware models (e.g. Dell Studio 1555 laptops) require calls to
the firmware to be issued on cpu 0 only. As Dom0 might have to use
these calls, add xen_pin_vcpu() to achieve this functionality.
In case either the domain doesn't have the privilege to make the
related hypercall or the hypervis
Import the actual version of include/xen/interface/sched.h from Xen.
Signed-off-by: Juergen Gross
---
include/xen/interface/sched.h | 100 ++
1 file changed, 82 insertions(+), 18 deletions(-)
diff --git a/include/xen/interface/sched.h b/include/xen/interf
Some hardware (e.g. Dell Studio laptops) require special functions to
be called on physical cpu 0 in order to avoid occasional hangs. When
running as dom0 under Xen this could be achieved only via special boot
parameters (vcpu pinning) limiting the hypervisor in it's scheduling
decisions.
This pat
Hi Shannon,
On 17/03/2016 09:40, Shannon Zhao wrote:
From: Shannon Zhao
Copy and modify FADT table before passing it to Dom0. Set PSCI_COMPLIANT
and PSCI_USE_HVC.
Signed-off-by: Shannon Zhao
Reviewed-by: Stefano Stabellini
Acked-by: Julien Grall
Regards,
--
Julien Grall
__
Add generic virtualization support for pinning the current vcpu to a
specified physical cpu. As this operation isn't performance critical
(a very limited set of operations like BIOS calls and SMIs is expected
to need this) just add a hypervisor specific indirection.
Such a pinning should last as s
Use smp_call_sync_on_phys_cpu() to raise SMI on cpu 0.
Signed-off-by: Juergen Gross
---
drivers/firmware/dcdbas.c | 46 --
1 file changed, 20 insertions(+), 26 deletions(-)
diff --git a/drivers/firmware/dcdbas.c b/drivers/firmware/dcdbas.c
index 829ee
>>> On 18.03.16 at 20:59, wrote:
> I know I copied and pasted it and I must have done something uncanny.
>
> Anyhow this is what the change looks like now (I've retained the Reviewed
> and Ack as I think this change is mostly cosmetical in nature?)
I think that's okay.
> v5: Add Acks, make BUIL
On Mon, Feb 29, 2016 at 09:00:44PM -0700, Jim Fehlig wrote:
> An expanded V2 of
>
> https://www.redhat.com/archives/libvir-list/2016-February/msg00140.html
>
> In V2, the feature is extended with a state='on|off' attribute to
> allow differentiating the 'on' and 'off' states with not set (or hyp
>>> On 18.03.16 at 20:22, wrote:
>> > + * return the number of bytes requested for the operation. Or an
>> > + * negative value if an error is encountered.
>> > + */
>> > +
>> > +typedef uint64_t xen_version_op_val_t;
>> > +DEFINE_XEN_GUEST_HANDLE(xen_version_op_val_t);
>> > +
>> > +typedef void x
flight 86747 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/86747/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-win7-amd64 15 guest-localmigrate/x10 fail REGR. vs.
86491
test-amd64-i38
>>> On 18.03.16 at 19:44, wrote:
> On 17/03/16 09:40, Shannon Zhao wrote:
>> --- /dev/null
>> +++ b/xen/arch/arm/efi/efi-dom0.c
>> @@ -0,0 +1,50 @@
>> +/*
>> + * efi-dom0.c - Domain0 EFI Boot Support
>> + *
>> + * Copyright (C) 2016 Shannon Zhao
>> + *
>> + *
>> ~~~
On 21/03/16 11:45, Joao Martins wrote:
>
> All fixed, though I found one change missing in this series, specifically on
> time_calibration_std_rendezvous. Otherwise this commit would break
> compilation.
> See chunk below for the change I am adding:
>
> @@ -1377,7 +1380,7 @@ static void time_calib
>>> On 21.03.16 at 13:04, wrote:
> On Thu, Mar 17, 2016 at 4:08 PM, Ian Jackson
> wrote:
>> Konrad Rzeszutek Wilk writes ("[PATCH v4 08/34] vmap: Make the while loop
>> less fishy."):
>>> error:
>>> -while ( i-- )
>>> -free_domheap_page(mfn_to_page(mfn_x(mfn[i])));
>>> +while
Thank you but I need a diagram like below. It is an diagram about OS components
:
http://www.c-jump.com/CIS24/Slides/Booting/images/os_components.png
Can you show me similar diagram for Xen?
On Monday, March 21, 2016 3:42 AM, Lars Kurth wrote:
> On 20 Mar 2016, at 21:04, Daniele Palumbo w
On 21/03/16 13:28, Jason Long wrote:
Don't top post.
> Thank you but I need a diagram like below. It is an diagram about OS
> components :
>
> http://www.c-jump.com/CIS24/Slides/Booting/images/os_components.png
>
> Can you show me similar diagram for Xen?
http://lmgtfy.com/?q=diagram+of+xen+com
>>> On 18.03.16 at 22:26, wrote:
> Add XEN_DOMCTL_SCHEDOP_getvcpuinfo and _putvcpuinfo hypercalls
> to independently get and set the scheduling parameters of each
> vCPU of a domain
>
> Signed-off-by: Chong Li
> Signed-off-by: Meng Xu
> Signed-off-by: Sisu Xi
>
> ---
> Changes on PATCH v7:
>
On 21/03/16 11:53, Jan Beulich wrote:
+XEN_CPUFEATURE(X2APIC,1*32+21) /*A Extended xAPIC */
>>> Does this make sense for PV?
>> It is currently visible, and we already have to leak APIC through to PV
>> guests.
> Having to leak on piece of state doesn't mean when need to leak
> more,
>>> On 21.03.16 at 13:24, wrote:
> @@ -758,9 +759,14 @@ struct smp_sync_call_struct {
> static void smp_call_sync_callback(struct work_struct *work)
> {
> struct smp_sync_call_struct *sscs;
> + unsigned int cpu = smp_processor_id();
So this obtains the vCPU number, yet ...
> ss
flight 86783 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/86783/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-libvirt 5 libvirt-build fail REGR. vs. 86536
Tests which did not succe
On 21/03/16 13:42, Jan Beulich wrote:
>
> Also don't you need to call smp_processor_id() after preempt_disable()?
I suggest using get_cpu()/put_cpu() here.
David
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
On 21/03/16 14:42, Jan Beulich wrote:
On 21.03.16 at 13:24, wrote:
>> @@ -758,9 +759,14 @@ struct smp_sync_call_struct {
>> static void smp_call_sync_callback(struct work_struct *work)
>> {
>> struct smp_sync_call_struct *sscs;
>> +unsigned int cpu = smp_processor_id();
>
> So thi
>>> On 18.03.16 at 20:04, wrote:
> --- a/xen/include/xen/sched-if.h
> +++ b/xen/include/xen/sched-if.h
> @@ -9,6 +9,7 @@
> #define __XEN_SCHED_IF_H__
>
> #include
> +#include
>
> /* A global pointer to the initial cpupool (POOL0). */
> extern struct cpupool *cpupool0;
There is no visibl
On Mon, Mar 21, 2016 at 1:26 PM, Jan Beulich wrote:
On 21.03.16 at 13:04, wrote:
>> On Thu, Mar 17, 2016 at 4:08 PM, Ian Jackson
>> wrote:
>>> Konrad Rzeszutek Wilk writes ("[PATCH v4 08/34] vmap: Make the while loop
>>> less fishy."):
error:
-while ( i-- )
-f
Hello,
My initial contribution can be found at:
http://lists.xen.org/archives/html/xen-devel/2015-10/msg02921.html
On Mon, Mar 21, 2016 at 4:56 PM, Lars Kurth
wrote:
> Hi Lasya, (adding xen-devel@)
>
> On 21 Mar 2016, at 11:17, Lasya Venneti wrote:
>
> Hi Lars, Jesus!
>
> This is Lasya from I
>>> On 18.03.16 at 20:04, wrote:
> RTDS is basically identical to Credit2, as far as scheduler
> lock (re)mapping is concerned. Therefore, the same analisys
> and considerations expressed for the previous patch ("xen:
> sched: prepare a .switch_sched hook for Credit2"), applies
> to it to.
Yet th
It is not a good diagram. Looking at my OS diagram.
For example, Xen have Dom0, DomU and
On Monday, March 21, 2016 6:34 AM, Andrew Cooper
wrote:
On 21/03/16 13:28, Jason Long wrote:
Don't top post.
> Thank you but I need a diagram like below. It is an diagram about OS
> components :
>
>
On 18/03/16 08:11, Juergen Gross wrote:
> On 17/03/16 17:06, George Dunlap wrote:
>> On Thu, Mar 10, 2016 at 3:00 PM, Juergen Gross wrote:
>>> Today the device model (qemu) is started for a pv domain only in case
>>> a device requiring qemu is specified in the domain configuration
>>> (qdisk, vfb,
On 21/03/16 15:28, George Dunlap wrote:
> On 18/03/16 08:11, Juergen Gross wrote:
>> On 17/03/16 17:06, George Dunlap wrote:
>>> On Thu, Mar 10, 2016 at 3:00 PM, Juergen Gross wrote:
Today the device model (qemu) is started for a pv domain only in case
a device requiring qemu is specifie
On 18/03/16 20:04, Dario Faggioli wrote:
> The .alloc_pdata scheduler hook must, before this change,
> be implemented by all schedulers --even those ones that
> don't need to allocate anything.
>
> Make it possible to just use the SCHED_OP(), like for
> the other hooks, by using ERR_PTR() and IS_E
On 18/03/16 20:05, Dario Faggioli wrote:
> From: Uma Sharma
>
> and, while we are adjusting signedness of opt_load_window_shift,
> make also prv->load_window_shift unsigned, as approapriate.
>
> Signed-off-by: Uma Sharma
> Signed-off-by: Dario Faggioli
> ---
> Cc: George Dunlap
> Cc: Juergen
On Mon, Mar 21, 2016 at 06:21:20AM +0100, Juergen Gross wrote:
[...]
> > 4. Load bios via toolstack
>
> What about my pending "pin override" tools related patches? Hypervisor
> parts are already committed.
>
That was omitted, because as far as I can tell all toolstack patches
were already acked
>>> On 21.03.16 at 15:22, wrote:
> Or to take a different tack: I understand that you don't think there's
> no particular benefit to adding a comment in cases like this; could
> you explain to me why you think it would have a significant cost?
There's no significant cost here. Yet I do think that
>>> On 21.03.16 at 15:48, wrote:
> On 18/03/16 20:04, Dario Faggioli wrote:
>> --- a/xen/common/schedule.c
>> +++ b/xen/common/schedule.c
>> @@ -1491,9 +1491,9 @@ static int cpu_schedule_up(unsigned int cpu)
>> if ( idle_vcpu[cpu] == NULL )
>> return -ENOMEM;
>>
>> -if ( (ops.a
>>> On 17.03.16 at 17:12, wrote:
> --- a/xen/include/public/xen.h
> +++ b/xen/include/public/xen.h
> @@ -614,10 +614,14 @@ struct vcpu_time_info {
> */
> uint32_t tsc_to_system_mul;
> int8_t tsc_shift;
> -int8_t pad1[3];
> +int8_t flags;
For use as flags I'm sure thi
On 20/03/16 00:23, Paul Gortmaker wrote:
> [[PATCH v2 0/5] xen: avoid module usage in non-modular code] On 21/02/2016
> (Sun 19:06) Paul Gortmaker wrote:
>
>> This series of commits is a part of a larger project to ensure
>> people don't reference modular support functions in non-modular
>> code.
Hi Shannon,
On 17/03/2016 09:40, Shannon Zhao wrote:
From: Shannon Zhao
Add a new member in gic_hw_operations which is used to creat MADT table
s/create/create/
for Dom0.
Signed-off-by: Shannon Zhao
Reviewed-by: Stefano Stabellini
---
xen/arch/arm/gic-v2.c | 34 +++
On Mon, Mar 21, 2016 at 8:35 AM, Jan Beulich wrote:
On 18.03.16 at 22:26, wrote:
>> Add XEN_DOMCTL_SCHEDOP_getvcpuinfo and _putvcpuinfo hypercalls
>> to independently get and set the scheduling parameters of each
>> vCPU of a domain
>>
>> Signed-off-by: Chong Li
>> Signed-off-by: Meng Xu
>
Hi Shannon,
On 17/03/2016 09:40, Shannon Zhao wrote:
From: Shannon Zhao
Copy main MADT table contents and distributor subtable from physical
ACPI MADT table. Make other subtables through the callback of
gic_hw_ops.
Signed-off-by: Shannon Zhao
Reviewed-by: Stefano Stabellini
With the 2 cha
On 21/03/16 15:10, Jan Beulich wrote:
On 17.03.16 at 17:12, wrote:
>> --- a/xen/include/public/xen.h
>> +++ b/xen/include/public/xen.h
>> @@ -614,10 +614,14 @@ struct vcpu_time_info {
>> */
>> uint32_t tsc_to_system_mul;
>> int8_t tsc_shift;
>> -int8_t pad1[3];
>> +
On 17/03/16 18:11, Ian Jackson wrote:
> George Dunlap writes ("[PATCH 4/8] libxl: Move check for local access to a
> funciton"):
>> +static char * libxl__device_disk_find_local_path(libxl__gc *gc,
>> + const libxl_device_disk
>> *disk) {
> ...
>> +
Hi Shannon,
On 17/03/2016 09:40, Shannon Zhao wrote:
From: Shannon Zhao
Create STAO table for Dom0. This table is used to tell Dom0 whether it
should ignore UART defined in SPCR table or the ACPI namespace names.
Look at below url for details:
http://wiki.xenproject.org/mediawiki/images/0/02/
On 03/21/2016 03:27 PM, Andrew Cooper wrote:
> On 21/03/16 15:10, Jan Beulich wrote:
> On 17.03.16 at 17:12, wrote:
>>> --- a/xen/include/public/xen.h
>>> +++ b/xen/include/public/xen.h
>>> @@ -614,10 +614,14 @@ struct vcpu_time_info {
>>> */
>>> uint32_t tsc_to_system_mul;
>>>
>>> On 15.03.16 at 16:35, wrote:
> @@ -18,12 +19,34 @@ uint32_t __read_mostly hvm_featureset[FSCAPINTS];
>
> static void __init sanitise_featureset(uint32_t *fs)
> {
> +uint32_t disabled_features[FSCAPINTS];
> unsigned int i;
>
> for ( i = 0; i < FSCAPINTS; ++i )
> {
>
Hi Shannon,
On 17/03/2016 09:40, Shannon Zhao wrote:
From: Shannon Zhao
Copy and modify XSDT table before passing it to Dom0. Repalce the entry
s/Repalce/Replace/
value of the copied table. Add a new entry for STAO table as well. And
keep entry value of other reused tables unchanged.
Sign
On 03/21/2016 06:49 AM, Ján Tomko wrote:
> On Mon, Feb 29, 2016 at 09:00:44PM -0700, Jim Fehlig wrote:
>> An expanded V2 of
>>
>> https://www.redhat.com/archives/libvir-list/2016-February/msg00140.html
>>
>> In V2, the feature is extended with a state='on|off' attribute to
>> allow differentiating
>>> On 15.03.16 at 16:35, wrote:
> When clearing a cpu cap, clear all dependent features. This avoids having a
> featureset with intermediate features disabled, but leaf features enabled.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
_
flight 86761 linux-4.1 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/86761/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-rumpuserxen 6 xen-build fail REGR. vs. 66399
build-i386-rumpuserxen
On 21/03/16 15:18, Chong Li wrote:
> On Mon, Mar 21, 2016 at 8:35 AM, Jan Beulich wrote:
> On 18.03.16 at 22:26, wrote:
>>> Add XEN_DOMCTL_SCHEDOP_getvcpuinfo and _putvcpuinfo hypercalls
>>> to independently get and set the scheduling parameters of each
>>> vCPU of a domain
>>>
>>> Signed-off
>>> On 21.03.16 at 16:18, wrote:
> On Mon, Mar 21, 2016 at 8:35 AM, Jan Beulich wrote:
> On 18.03.16 at 22:26, wrote:
>>> --- a/xen/include/public/domctl.h
>>> +++ b/xen/include/public/domctl.h
>>> @@ -338,24 +338,64 @@ DEFINE_XEN_GUEST_HANDLE(xen_domctl_max_vcpus_t);
>>> #define XEN_SCHEDU
>>> On 21.03.16 at 16:26, wrote:
> On 17/03/2016 09:40, Shannon Zhao wrote:
>> +gicd = container_of(header, struct acpi_madt_generic_distributor,
>> header);
>> +ACPI_MEMCPY(base_ptr + table_size, gicd,
>> +sizeof(struct acpi_madt_generic_distributor));
>> +table_size
Title: to map/unmap
On 17/03/2016 09:40, Shannon Zhao wrote:
diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
index 433952a..17be6ad 100644
--- a/xen/include/asm-arm/p2m.h
+++ b/xen/include/asm-arm/p2m.h
@@ -144,6 +144,16 @@ int p2m_cache_flush(struct domain *d, xen_pfn_t start
Title: Map all other tables into DOM0 memory.
On 17/03/2016 09:40, Shannon Zhao wrote:
From: Shannon Zhao
Map all other tables to Dom0 using 1:1 mappings.
s/to/into/
Signed-off-by: Shannon Zhao
Reviewed-by: Stefano Stabellini
---
xen/arch/arm/domain_build.c | 26 ++
On Mon, Mar 21, 2016 at 10:49 AM, Jan Beulich wrote:
On 21.03.16 at 16:18, wrote:
>> On Mon, Mar 21, 2016 at 8:35 AM, Jan Beulich wrote:
>> On 18.03.16 at 22:26, wrote:
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -338,24 +338,64 @@ DEFINE_XEN_G
Hi Shannon,
On 17/03/2016 09:40, Shannon Zhao wrote:
From: Shannon Zhao
Copy RSDP table and replace rsdp->xsdt_physical_address with new address
^ the
of XSDT table, so it can point to the right XSDT table.
Signed-off-by: Shannon
Hi Shannon,
On 17/03/2016 09:40, Shannon Zhao wrote:
[...]
diff --git a/xen/arch/arm/efi/efi-dom0.c b/xen/arch/arm/efi/efi-dom0.c
index 90a7699..b8a062c 100644
--- a/xen/arch/arm/efi/efi-dom0.c
+++ b/xen/arch/arm/efi/efi-dom0.c
@@ -48,3 +48,47 @@ size_t __init estimate_efi_size(int mem_nr_bank
>>> On 15.03.16 at 16:35, wrote:
> case 0x8001:
> -/* We expose RDTSCP feature to guest only when
> - tsc_mode == TSC_MODE_DEFAULT and host_tsc_is_safe() returns 1 */
> -if ( d->arch.tsc_mode != TSC_MODE_DEFAULT ||
> - !host_tsc_is_safe() )
> -
>>> On 15.03.16 at 16:35, wrote:
> Before c/s 44e24f8567 "x86: don't call generic_identify() redundantly", the
> commandline-provided masks would take effect in Xen's view of the features.
>
> As the masks got applied after the query for features, the redundant call to
> generic_identify() would
>>> On 15.03.16 at 16:35, wrote:
> --- a/xen/arch/x86/cpu/common.c
> +++ b/xen/arch/x86/cpu/common.c
> @@ -36,6 +36,12 @@ integer_param("cpuid_mask_ext_ecx",
> opt_cpuid_mask_ext_ecx);
> unsigned int opt_cpuid_mask_ext_edx = ~0u;
> integer_param("cpuid_mask_ext_edx", opt_cpuid_mask_ext_edx);
>
On Mon, 21 Mar 2016, Paulina Szubarczyk wrote:
> Hi Lars,
>
> Thank you for your answer. I am looking forward to further information from
> you.
Hello Paulina,
Sorry for the delay, I was away last week and I'm just trying to catch up
with all my email.
As a first step you should look into
>>> On 21.03.16 at 17:03, wrote:
> On Mon, Mar 21, 2016 at 10:49 AM, Jan Beulich wrote:
> On 21.03.16 at 16:18, wrote:
>>> On Mon, Mar 21, 2016 at 8:35 AM, Jan Beulich wrote:
>>> On 18.03.16 at 22:26, wrote:
> --- a/xen/include/public/domctl.h
> +++ b/xen/include/public/domctl.
>>> On 15.03.16 at 16:35, wrote:
> This patch is best reviewed as its end result rather than as a diff, as it
> rewrites almost all of the setup.
>
> On the BSP, cpuid information is used to evaluate the potential available
> set
> of masking MSRs, and they are unconditionally probed, filling in
Hi Shannon,
On 17/03/2016 09:40, Shannon Zhao wrote:
From: Shannon Zhao
Create a few EFI memory descriptors to tell Dom0 the RAM region
s/a few//
information, ACPI table regions and EFI tables reserved resions.
s/resions/regions/
Signed-off-by: Parth Dixit
Signed-off-by: Shannon Zhao
>>> On 15.03.16 at 16:35, wrote:
> + /* Fast-forward bits - Must be set. */
> + if (ecx & cpufeat_mask(X86_FEATURE_XSAVE))
> + ecx |= cpufeat_mask(X86_FEATURE_OSXSAVE);
Wouldn't you think it would be better to also handle PKU/OSPKE
here, just in case AM
On 21/03/16 16:51, Jan Beulich wrote:
On 15.03.16 at 16:35, wrote:
>> +/* Fast-forward bits - Must be set. */
>> +if (ecx & cpufeat_mask(X86_FEATURE_XSAVE))
>> +ecx |= cpufeat_mask(X86_FEATURE_OSXSAVE);
> Wouldn't you think it would be better to als
>>> On 15.03.16 at 16:35, wrote:
> And use them in preference to cpumask_defaults on context switch. HVM
> domains
> must not be masked (to avoid interfering with cpuid calls within the guest),
> so always lazily context switch to the host default.
>
> Signed-off-by: Andrew Cooper
Reviewed-by
Hello,
On Tue, 15 Mar 2016, Jan Beulich wrote:
> >>> On 14.03.16 at 18:55, wrote:
> > --- a/xen/include/public/xen.h
> > +++ b/xen/include/public/xen.h
> > @@ -841,6 +841,37 @@ typedef struct start_info start_info_t;
> > */
> > #define XEN_HVM_START_MAGIC_VALUE 0x336ec578
> >
> > +#if defin
>>> On 15.03.16 at 16:35, wrote:
> @@ -87,6 +88,129 @@ static void update_domain_cpuid_info(struct domain *d,
> d->arch.x86_model = (ctl->eax >> 4) & 0xf;
> if ( d->arch.x86 >= 0x6 )
> d->arch.x86_model |= (ctl->eax >> 12) & 0xf0;
> +
> +if ( is_pv_domain(d)
>>> On 21.03.16 at 18:04, wrote:
> On Tue, 15 Mar 2016, Jan Beulich wrote:
>> >>> On 14.03.16 at 18:55, wrote:
>> > --- a/xen/include/public/xen.h
>> > +++ b/xen/include/public/xen.h
>> > @@ -841,6 +841,37 @@ typedef struct start_info start_info_t;
>> > */
>> > #define XEN_HVM_START_MAGIC_VALU
flight 86792 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/86792/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 65543
test-amd64-i386-xl-qemuu-ovm
1 - 100 of 126 matches
Mail list logo
