On February 23, 2017 8:27 PM, Jan Beulich wrote:
On 23.02.17 at 12:55, wrote:
>> On February 23, 2017 7:01 PM, Jan Beulich wrote:
>> On 23.02.17 at 11:53, wrote:
IOW,
which vcpu does the 'current' refer to?
which cpu does the ' smp_processor_id()' refer to?
>>>
>>>curren
flight 106028 xen-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106028/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-credit2 17 guest-localmigrate/x10 fail REGR. vs. 105855
Tests which are
>>> On 24.02.17 at 09:02, wrote:
> Another question, it 'd be the _main_gap_..
> If the pCPU runs __vmx_deliver_posted_interrupt() here, in a
> hyperver-context,
> _iiuc_, all of vCPUs , waiting in the run queue, are scheduled out.. So the
> 'current' is NULL, as there is no running vCPU..
Exc
flight 106029 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106029/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 3 host-install(3) broken REGR. vs. 105963
versi
>>> On 23.02.17 at 18:03, wrote:
> As some users have suggested, elaborate the usage of RMRR specification
> on the command line, and provide a usage example.
>
> Also, always treat the specified page numbers as hexadecimal values.
>
> Signed-off-by: Venu Busireddy
Reviewed-by: Jan Beulich
>
Hello,
Having a XEN_DOMCTL_getvcpuextstate libxc wrapper would help
introspection get the state of SSE registers, and it looks trivial to do
at a glance.
Are there specific reasons why it hasn't been exposed already, or is it
fine to try to submit a patch?
Thanks,
Razvan
__
On 24/02/2017 09:44, Razvan Cojocaru wrote:
> Hello,
>
> Having a XEN_DOMCTL_getvcpuextstate libxc wrapper would help
> introspection get the state of SSE registers, and it looks trivial to do
> at a glance.
>
> Are there specific reasons why it hasn't been exposed already, or is it
> fine to try t
On Fri, Feb 24, 2017 at 07:21:42AM +0100, Juergen Gross wrote:
> The Xenstore protocol supports the XS_CONTROL command for triggering
> various actions in the Xenstore daemon. Enhance that support by using
> a command table and adding a help function.
>
> Support multiple control commands in the a
Hi,
On 02/22/2017 02:11 PM, Julien Grall wrote:
On 22/02/17 13:19, Ian Jackson wrote:
Julien Grall writes ("Re: [Xen-devel] [linux-linus test] 104684:
regressions - FAIL"):
On 14/02/17 17:42, Wei Liu wrote:
(test-lab)liuw@osstest:~/testing.git$ ./mg-hosts showprops | grep
DTUART | grep arndal
flight 106060 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106060/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a
build-arm64 5 xen
c/s e966818264908e842e2847f579ca4d94e586eaac added
mce_need_clearbank_register below the comment of
x86_mce_callback_register(). This commit (1) adjusts the first
paragraph of comment to be a general statement of all callback
register functions, and (2) moves the second paragraph to the
front of x8
All existing calls to x86_mcinfo_reserve() are followed by statements
that set the size and the type of the reserved space, so move them into
x86_mcinfo_reserve() to simplify the code.
Signed-off-by: Haozhong Zhang
---
Cc: Christoph Egger
Cc: Jan Beulich
Cc: Andrew Cooper
Changes:
* Use "uns
The current implementation only fills MC MSRs on vcpu0 and leaves MC
MSRs on other vcpus empty in the broadcast case. When guest reads 0
from MSR_IA32_MCG_STATUS on vcpuN (N > 0), it may think it's not
possible to recover the execution on that vcpu and then get panic,
although MSR_IA32_MCG_STATUS f
This patch series separates the uncommitted code cleanup and bugfix
patches from my previous patch series "[PATCH 00/19] MCE code cleanup and add
LMCE support"
with other new fixes.
* This patch series is based on Jan's patch "x86/MCE: sanitize domain/vcpu ID
handling".
* Patch 1 & 6 are new one
c/s 9d13fd9fd320a7740c6446c048ff6a2990095966 turned to update the
mcinfo buffer in-place instead of using x86_mcinfo_add(). The last
uses of x86_mcinfo_add() were removed by that commit as well.
Therefore, x86_mcinfo_add() was deprecated in fact.
Signed-off-by: Haozhong Zhang
---
Cc: Christoph Eg
mce_dhandlers[] and its array size mce_dhandler_num are not used and
set on non-Intel platforms, so the corresponding ASSERT's in
mce_action() should be valid only for Intel.
Signed-off-by: Haozhong Zhang
---
Cc: Christoph Egger
Cc: Jan Beulich
Cc: Andrew Cooper
---
xen/arch/x86/cpu/mcheck/mc
Use "unsigned int" rather than "int" to align to the type "uint32_t"
of xen_mc_physcpuinfo.ncpus.
Signed-off-by: Haozhong Zhang
---
Cc: Ian Jackson
Cc: Wei Liu
Cc: Jan Beulich
Changes:
* Replace "uint32_t" by "unsigned int".
---
tools/tests/mce-test/tools/xen-mceinj.c | 12 +++-
1 f
On Intel CPU, an attemp to write to MSR_IA32_MCG_STATUS with any
non-zero value would result in #GP.
This commit writes 0 on AMD CPU as well instead of just clearing MCIP
bit, because all non-reserved bits of MSR_IA32_MCG_STATUS have been
handled at this point.
Signed-off-by: Haozhong Zhang
---
c/s 49de10f3c "x86/hvm: Don't raise #GP behind the emulators back for MSR
accesses" missed an edge case.
hvm_set_efer() raises #GP itself, so deliberately avoided the goto gp_fault
path in hvm_msr_write_intercept().
With the above change, guest updates to MSR_EFER which end up faulting raises
hvm
On Fri, Feb 24, 2017 at 07:12:10AM +0800, Chao Gao wrote:
> Commit 20b75251d97 ("libxl/libxl_pci.c: used LOG*D functions") reverses the
> logic to call xc_deassign_device(). It makes the device unusable.
>
> Signed-off-by: Chao Gao
Acked + applied.
> ---
> tools/libxl/libxl_pci.c | 2 +-
> 1 f
Julien Grall writes ("Re: [Xen-devel] [linux-linus test] 104684: regressions -
FAIL"):
> This means that the path to the serial is different between 3.16 and
> 4.10 and we have no common one. For now, I would revert it.
Done.
> A per-flight override sounds quite ugly, so I am not sure how to so
osstest service owner writes ("[xen-4.8-testing test] 106011: tolerable
trouble: blocked/broken/fail/pass - PUSHED"):
> flight 106011 xen-4.8-testing real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/106011/
>
> Failures :-/ but no regressions.
>
> Tests which are failing intermitte
flight 68613 distros-debian-jessie real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68613/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-armhf-jessie-netboot-pygrub 1 build-check(1) blocked n/a
build-arm64
branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-xl-qemuu-ovmf-amd64
testid debian-hvm-install
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf https://github.com/tianocore/edk2.git
Tree: qemu git://xen
On 02/24/2017 05:52 AM, Haozhong Zhang wrote:
> On Intel CPU, an attemp to write to MSR_IA32_MCG_STATUS with any
> non-zero value would result in #GP.
>
> This commit writes 0 on AMD CPU as well instead of just clearing MCIP
> bit, because all non-reserved bits of MSR_IA32_MCG_STATUS have been
> ha
On 02/24/2017 05:59 AM, Andrew Cooper wrote:
> c/s 49de10f3c "x86/hvm: Don't raise #GP behind the emulators back for MSR
> accesses" missed an edge case.
>
> hvm_set_efer() raises #GP itself, so deliberately avoided the goto gp_fault
> path in hvm_msr_write_intercept().
>
> With the above change, g
flight 106034 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106034/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-winxpsp3 3 host-install(3) broken REGR. vs. 105933
test-amd64-amd64-i
On 24/02/17 14:14, Vlad-Ioan TOPAN wrote:
> Hello,
>
> We are trying to use the #VE support in Xen to monitor memory accesses
> to certain pages from a kernel module in Windows.
>
> As it is written now, the #VE-enabling code appears to enforce being
> called by a domain for itself (by each VCPU f
Hello,
We are trying to use the #VE support in Xen to monitor memory accesses
to certain pages from a kernel module in Windows.
As it is written now, the #VE-enabling code appears to enforce being
called by a domain for itself (by each VCPU for itself, actually), which
severely limits its useful
>>> On 24.02.17 at 11:59, wrote:
> c/s 49de10f3c "x86/hvm: Don't raise #GP behind the emulators back for MSR
> accesses" missed an edge case.
>
> hvm_set_efer() raises #GP itself, so deliberately avoided the goto gp_fault
> path in hvm_msr_write_intercept().
>
> With the above change, guest upda
On 02/23/2017 08:20 PM, osstest service owner wrote:
> flight 106009 linux-linus real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/106009/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-amd64-i386-xl-qemuu-ovmf-am
This run is configured for baseline tests only.
flight 68612 xen-4.5-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68612/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl 15 guest-start/
> #VE, by design, raises an exception in non-root context, without
> breaking out to the hypervisor.
>
> The vcpu in question needs to set up a suitable #VE handler, so it is
> not safe for an external entity to chose when a vcpu should start
> receiving #VE's.
The problem is that from a security
Hi Ian,
On 23/02/17 20:53, osstest service owner wrote:
flight 106032 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106032/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 1 build-check(1)
flight 106042 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106042/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-pvops 3 host-install(3) broken REGR. vs. 59254
test-amd64-i386-xl-
flight 106071 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106071/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-i386 9 debian-hvm-install fail REGR. vs.
106060
Tests
On 21/02/17 12:03, George John wrote:
Hi,
Hello,
I was trying out xen in salvator-X(M3 Board as described
in
https://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions/Salvator-X
I ran in to following error:
U-Boot 2015.04 (Feb 21 2017 - 14:24:48)
CPU: Renesas Electronics
>>> On 24.02.17 at 11:52, wrote:
> c/s 9d13fd9fd320a7740c6446c048ff6a2990095966 turned to update the
> mcinfo buffer in-place instead of using x86_mcinfo_add(). The last
> uses of x86_mcinfo_add() were removed by that commit as well.
> Therefore, x86_mcinfo_add() was deprecated in fact.
>
> Signe
>>> On 24.02.17 at 11:52, wrote:
> All existing calls to x86_mcinfo_reserve() are followed by statements
> that set the size and the type of the reserved space, so move them into
> x86_mcinfo_reserve() to simplify the code.
>
> Signed-off-by: Haozhong Zhang
Reviewed-by: Jan Beulich
>>> On 24.02.17 at 11:52, wrote:
> On Intel CPU, an attemp to write to MSR_IA32_MCG_STATUS with any
> non-zero value would result in #GP.
>
> This commit writes 0 on AMD CPU as well instead of just clearing MCIP
> bit, because all non-reserved bits of MSR_IA32_MCG_STATUS have been
> handled at th
>>> On 24.02.17 at 11:52, wrote:
> The current implementation only fills MC MSRs on vcpu0 and leaves MC
> MSRs on other vcpus empty in the broadcast case. When guest reads 0
> from MSR_IA32_MCG_STATUS on vcpuN (N > 0), it may think it's not
> possible to recover the execution on that vcpu and then
On 24/02/17 14:42, Vlad-Ioan TOPAN wrote:
>> #VE, by design, raises an exception in non-root context, without
>> breaking out to the hypervisor.
>>
>> The vcpu in question needs to set up a suitable #VE handler, so it is
>> not safe for an external entity to chose when a vcpu should start
>> receiv
Hello,
This patch series removes the PVHv1 code, both from the hypervisor and the
tools, and also gets rid of the has_hvm_container_{domain/vcpu} macro, since
from Xen's point of view there are only two types of guests: PV or HVM.
Last patch is a minor code movement to have all the domain build P
Hi,
Not 100% sure, but anyway...
Can you recheck after squashing all memory nodes to a single one.
---
I guess, you have following in your device tree:
memory@4800 {
device_type = "memory";
/* first 128MB is reserved for secure area. */
reg = <0x0 0x4800 0x0 0x3800>;
};
memory@5000
It is now useless since PVHv1 is removed and PVHv2 is a HVM domain from Xen's
point of view.
Signed-off-by: Roger Pau Monné
---
Cc: Christoph Egger
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Boris Ostrovsky
Cc: Suravee Suthikulpanit
Cc: Jun Nakajima
Cc: Kevin Tian
Cc: Elena Ufimtseva
Cc: Georg
This removal applies to both the hypervisor and the toolstack side of PVHv1.
Note that on the toolstack side there's one hiccup: on xl the "pvh"
configuration option is translated to builder="hvm",
device_model_version="none". This is done because otherwise xl would start
parsing PV like options,
This function is only used by PVHv2 domain build, so move it together with the
other PVH domain build functions.
Just code motion, no functional change.
Signed-off-by: Roger Pau Monné
---
Cc: Jan Beulich
Cc: Andrew Cooper
---
xen/arch/x86/domain_build.c | 134 ++---
flight 106048 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106048/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt 3 host-install(3)broken REGR. vs. 105973
Re
>>> On 24.02.17 at 11:52, wrote:
> --- a/xen/arch/x86/cpu/mcheck/mce.c
> +++ b/xen/arch/x86/cpu/mcheck/mce.c
> @@ -1621,8 +1621,8 @@ static enum mce_result mce_action(const struct
> cpu_user_regs *regs,
> handlers = mce_uhandlers;
> }
>
> -/* At least a default handler should
flight 106047 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106047/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-intel 3 host-install(3) broken REGR. vs. 1059
>>> On 23.02.17 at 10:41, wrote:
> @@ -992,10 +993,30 @@ bool_t update_secondary_system_time(struct vcpu *v,
> {
> XEN_GUEST_HANDLE(vcpu_time_info_t) user_u = v->arch.time_info_guest;
> smap_check_policy_t saved_policy;
> +bool nested_guest_mode = false;
>
> if ( guest_handle
>>> On 23.02.17 at 10:41, wrote:
> The current implementation of nested VMX cannot work without HAP.
Of course the better route would be to fix the actual problem,
the more that - according to other feedback you've got elsewhere -
this apparently is a regression. Nevertheless I can see you perhap
Boris Ostrovsky writes ("Re: [Xen-devel] [linux-linus test] 106009: regressions
- trouble: blocked/broken/fail/pass"):
> Can you change PVH test to use
> device_model_version="none"
> instead of
> pvh=1
I had this conversation with Roger and we seem to have concluded that
`pvh=1' should b
>>> On 24.02.17 at 16:13, wrote:
> This function is only used by PVHv2 domain build, so move it together with the
> other PVH domain build functions.
>
> Just code motion, no functional change.
>
> Signed-off-by: Roger Pau Monné
Acked-by: Jan Beulich
On 24/02/17 15:13, Roger Pau Monne wrote:
> diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
> index 85cbb7c..65b7475 100644
> --- a/xen/include/public/domctl.h
> +++ b/xen/include/public/domctl.h
> @@ -60,11 +60,8 @@ struct xen_domctl_createdomain {
> /* Disable out-of-sync
On 24/02/17 15:13, Roger Pau Monne wrote:
> It is now useless since PVHv1 is removed and PVHv2 is a HVM domain from Xen's
> point of view.
>
> Signed-off-by: Roger Pau Monné
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xen.org
On 24/02/17 15:13, Roger Pau Monne wrote:
> diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
> index 66b7aba..fa601da 100644
> --- a/xen/arch/x86/setup.c
> +++ b/xen/arch/x86/setup.c
> @@ -62,10 +62,6 @@ integer_param("maxcpus", max_cpus);
>
> unsigned long __read_mostly cr4_pv32_mask;
>
>>> On 22.02.17 at 19:24, wrote:
> vpmu_enabled() (used by hvm/pv_cpuid() to properly report 0xa leaf
> for Intel processors) is based on the value of VPMU_CONTEXT_ALLOCATED
> bit. This is problematic:
> * For HVM guests VPMU context is allocated lazily, during the first
> access to VPMU MSRs. S
>>> On 22.02.17 at 19:24, wrote:
> When toolstack overrides Intel CPUID leaf 0xa's PMU version with an
> invalid value VPMU should not be available to the guest.
>
> Signed-off-by: Boris Ostrovsky
Reviewed-by: Jan Beulich
with one nit:
> --- a/xen/arch/x86/domctl.c
> +++ b/xen/arch/x86/domctl
At 15:13 + on 24 Feb (1487949198), Roger Pau Monne wrote:
> It is now useless since PVHv1 is removed and PVHv2 is a HVM domain from Xen's
> point of view.
>
> Signed-off-by: Roger Pau Monné
Acked-by: Tim Deegan
___
Xen-devel mailing list
Xen-deve
>>> On 24.02.17 at 16:32, wrote:
> On 24/02/17 15:13, Roger Pau Monne wrote:
>> diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
>> index 85cbb7c..65b7475 100644
>> --- a/xen/include/public/domctl.h
>> +++ b/xen/include/public/domctl.h
>> @@ -60,11 +60,8 @@ struct xen_domctl_
>> > + System administrator can change PSR allocation policy at runtime by
>> > + tool stack. Since MBA shares COS with CAT/CDP, a COS corresponds to a
>> > + 2-tuple, like [CBM, Thrtl] with only-CAT enalbed, when CDP is enable,
>> > + the COS corresponds to a 3-tuple, like [Code_CBM, Data_CBM,
On 2/22/17 5:37 AM, Wei Liu wrote:
> On Wed, Feb 22, 2017 at 08:53:24AM +0100, Juergen Gross wrote:
>> On 20/02/17 16:19, Andrew Cooper wrote:
>>> On 20/02/17 14:43, Juergen Gross wrote:
On 20/02/17 15:31, Wei Liu wrote:
> On Thu, Feb 16, 2017 at 08:47:07AM +0100, Juergen Gross wrote:
flight 106051 xen-4.4-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106051/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xend-qemut-winxpsp3 15 guest-localmigrate/x10 fail REGR. vs.
105835
test-armh
On 2/22/17 1:53 AM, Juergen Gross wrote:
> On 20/02/17 16:19, Andrew Cooper wrote:
>> On 20/02/17 14:43, Juergen Gross wrote:
>>> On 20/02/17 15:31, Wei Liu wrote:
On Thu, Feb 16, 2017 at 08:47:07AM +0100, Juergen Gross wrote:
> There have been reports that Fedora 25 uses /run instead of /
They should be treated like any other libraries installed on the build
host. Compiler options are set correctly to point to their locations.
Signed-off-by: Wei Liu
---
tools/xl/xl.c | 6 +++---
tools/xl/xl.h | 2 +-
tools/xl/xl_cmdimpl.c | 8
tools/xl/xl_cmdtable.c |
It is included by xl.h. Previously it was using _paths.h from some other
place. We'd better generate one for xl as well.
Signed-off-by: Wei Liu
---
.gitignore| 1 +
tools/xl/Makefile | 7 ++-
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/.gitignore b/.gitignore
index
Signed-off-by: Wei Liu
---
tools/xl/xl.c | 4 +---
tools/xl/xl.h | 2 +-
tools/xl/xl_cmdimpl.c | 4 +---
tools/xl/xl_cmdtable.c | 2 +-
tools/xl/xl_sxp.c | 4 +---
5 files changed, 5 insertions(+), 11 deletions(-)
diff --git a/tools/xl/xl.c b/tools/xl/xl.c
index a27225815
xl_cmdimpl.c has become prohibitively large (almost 10k lines in one single
file). Try to split it up into multiple files according to the functionality of
the code.
I will run a full osstest flight before merging. Send the first version out as
quick as possible to gather feedback because I know
Move some commonly used functions to a new file. Prepend "x" to
function names to stick to consistent naming scheme.
Signed-off-by: Wei Liu
---
tools/xl/Makefile | 2 +-
tools/xl/xl_cmdimpl.c | 343 +-
tools/xl/xl_utils.c | 258
There is no reason for a client to include a private header from libxl.
Remove the inclusion and define _GNU_SOURCE for {v,}asprintf in
xl_cmdimpl.c.
Signed-off-by: Wei Liu
---
tools/xl/xl.c | 2 --
tools/xl/xl_cmdimpl.c | 2 +-
tools/xl/xl_sxp.c | 2 --
3 files changed, 1 insertion(
Signed-off-by: Wei Liu
---
tools/xl/xl_cmdimpl.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/xl/xl_cmdimpl.c b/tools/xl/xl_cmdimpl.c
index 9901011008..1d7cf8ffa8 100644
--- a/tools/xl/xl_cmdimpl.c
+++ b/tools/xl/xl_cmdimpl.c
@@ -6732,7 +6732,7 @@ static int sched
We're going to split xl_cmdimpl.c into multiple files. Lift the commonly
used macros to xl_utils.h.
Signed-off-by: Wei Liu
---
tools/xl/xl_cmdimpl.c | 104 +---
tools/xl/xl_utils.h | 129 ++
2 files changed, 13
It was never intended to be committed. Lucky the high level Makefile was
correct so it didn't cause us problem when building xl.
Signed-off-by: Wei Liu
---
tools/xl/Makefile | 6 --
1 file changed, 6 deletions(-)
diff --git a/tools/xl/Makefile b/tools/xl/Makefile
index d4b862c9b9..32dff4058
Looking at
void _spin_lock(spinlock_t *lock)
{
spinlock_tickets_t tickets = SPINLOCK_TICKET_INC;
LOCK_PROFILE_VAR;
check_lock(&lock->debug);
tickets.head_tail = arch_fetch_and_add(&lock->tickets.head_tail,
tickets.head_tail);
while (
Get read of #ifdefs in suspend.c by splitting the code into
suspend_pv.c and suspend_hvm.c.
Signed-off-by: Vitaly Kuznetsov
---
arch/x86/xen/Makefile | 4 ++--
arch/x86/xen/suspend.c | 58 --
arch/x86/xen/suspend_hvm.c | 22 ++
Introduce CONFIG_XEN_PV config option and split enlighten.c into
4 files. Temporary add #ifdef CONFIG_XEN_PV to smp.c and mmu.c to
not break the build and not make the patch even bigger.
xen_cpu_up_prepare*/xen_cpu_die hooks require separation to support
future xen_smp_intr_init() split.
Signed-o
[Adding Juergen]
On Wed, 2017-02-22 at 01:46 -0700, Jan Beulich wrote:
> > > > On 22.02.17 at 01:02, wrote:
> > (XEN) Xen call trace:
> > (XEN)[]
> > sched_credit2.c#vcpu_is_migrateable+0x22/0x9a
> > (XEN)[]
> > sched_credit2.c#csched2_schedule+0x823/0xb4e
> > (XEN)[] schedule.c#sched
On 24/02/17 17:06, Doug Goldstein wrote:
> On 2/22/17 1:53 AM, Juergen Gross wrote:
>> On 20/02/17 16:19, Andrew Cooper wrote:
>>> On 20/02/17 14:43, Juergen Gross wrote:
On 20/02/17 15:31, Wei Liu wrote:
> On Thu, Feb 16, 2017 at 08:47:07AM +0100, Juergen Gross wrote:
>> There have be
Hi,
it's been a while since my 'RFC' submission in November:
https://lists.xen.org/archives/html/xen-devel/2016-11/msg01044.html
I was advised to wait till PVHv2 stuff lands upstream and as this has already
happened I'm sending the first non-RFC version.
Changes since RFC:
- Rebase
- Use enlight
More or less mechanically split smp.c into 3 files. XEN_PV_SMP and
XEN_PVHVM_SMP config options added to support the change.
Signed-off-by: Vitaly Kuznetsov
---
arch/x86/xen/Kconfig| 8 +
arch/x86/xen/Makefile | 3 +
arch/x86/xen/enlighten_pv.c | 9 +
arch/x86/xen/smp.c
xen_pmu_init/finish() functions are used in suspend.c and
enlighten.c, add stubs for now.
Signed-off-by: Vitaly Kuznetsov
---
arch/x86/xen/Kconfig | 2 +-
arch/x86/xen/Makefile | 5 +++--
arch/x86/xen/pmu.h| 5 +
3 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/arch/x86/xe
>> +for_each_vcpu( d, v )
> If you use blanks immediately inside the parentheses, there should
> also be one immediately before the opening one. Can be corrected
> upon commit of course.
Yes, please fix this when committing. Thanks.
-boris
___
Signed-off-by: Wei Liu
---
tools/xl/Makefile | 1 +
tools/xl/xl_cmdimpl.c | 533 ---
tools/xl/xl_psr.c | 567 ++
3 files changed, 568 insertions(+), 533 deletions(-)
create mode 100644 tools/xl/
Signed-off-by: Wei Liu
---
tools/xl/Makefile | 2 +-
tools/xl/xl_cmdimpl.c | 119 ---
tools/xl/xl_flask.c | 153 ++
3 files changed, 154 insertions(+), 120 deletions(-)
create mode 100644 tools/xl/xl_flas
Signed-off-by: Wei Liu
---
tools/xl/Makefile | 1 +
tools/xl/xl_cmdimpl.c | 856
tools/xl/xl_sched.c | 888 ++
3 files changed, 889 insertions(+), 856 deletions(-)
create mode 100644 tools/xl
A collections of functions that don't warrant their own files.
Moving main_devd there requires lifting do_daemonize to xl_utils.c.
Signed-off-by: Wei Liu
---
tools/xl/Makefile | 2 +-
tools/xl/xl_cmdimpl.c | 390 --
tools/xl/xl_misc.c| 3
Signed-off-by: Wei Liu
---
tools/xl/Makefile | 2 +-
tools/xl/xl_cmdimpl.c | 306 -
tools/xl/xl_vcpu.c| 337 ++
3 files changed, 338 insertions(+), 307 deletions(-)
create mode 100644 tools/xl/x
Add some function declarations to xl.h because they are now needed in
multiple files.
Signed-off-by: Wei Liu
---
tools/xl/Makefile | 2 +-
tools/xl/xl.h | 6 +
tools/xl/xl_cmdimpl.c | 227 --
tools/xl/xl_saverestore.c | 273
Signed-off-by: Wei Liu
---
tools/xl/Makefile | 2 +-
tools/xl/xl_cmdimpl.c | 140
tools/xl/xl_nic.c | 172 ++
3 files changed, 173 insertions(+), 141 deletions(-)
create mode 100644 tools/xl/xl_nic
Signed-off-by: Wei Liu
---
tools/xl/Makefile | 2 +-
tools/xl/xl_cmdimpl.c | 592 ---
tools/xl/xl_cpupool.c | 624 ++
3 files changed, 625 insertions(+), 593 deletions(-)
create mode 100644 tools/xl
After splitting out all the meaty bits, xl_cmdimpl.c doesn't contain
much. Merge the rest into xl.c and delete the file.
Signed-off-by: Wei Liu
---
tools/xl/Makefile | 2 +-
tools/xl/xl.c | 58 +++
tools/xl/xl_cmdimpl.c | 107 ---
Signed-off-by: Wei Liu
---
tools/xl/Makefile | 2 +-
tools/xl/xl_cmdimpl.c | 883 +--
tools/xl/xl_info.c| 925 ++
3 files changed, 929 insertions(+), 881 deletions(-)
create mode 100644 tools/xl
Signed-off-by: Wei Liu
---
tools/xl/Makefile | 2 +-
tools/xl/xl_cd.c | 114 ++
tools/xl/xl_cmdimpl.c | 80 ---
3 files changed, 115 insertions(+), 81 deletions(-)
create mode 100644 tools/xl/xl_cd.c
dif
Signed-off-by: Wei Liu
---
tools/xl/Makefile | 2 +-
tools/xl/xl_cmdimpl.c | 136
tools/xl/xl_mem.c | 167 ++
3 files changed, 168 insertions(+), 137 deletions(-)
create mode 100644 tools/xl/xl_mem
Signed-off-by: Wei Liu
---
tools/xl/Makefile | 2 +-
tools/xl/xl_cmdimpl.c | 190 --
tools/xl/xl_usb.c | 222 ++
3 files changed, 223 insertions(+), 191 deletions(-)
create mode 100644 tools/xl/xl_u
Signed-off-by: Wei Liu
---
tools/xl/Makefile | 2 +-
tools/xl/xl_block.c | 129 ++
tools/xl/xl_cmdimpl.c | 99 --
3 files changed, 130 insertions(+), 100 deletions(-)
create mode 100644 tools/xl/xl_block
The new file also contains code for channel, which is just a console
in disguise.
Replace the call to vncviewer() with libxl_vncviewer_exec() directly in
main_vncviewer.
Signed-off-by: Wei Liu
---
tools/xl/Makefile | 2 +-
tools/xl/xl_cmdimpl.c | 98 -
Signed-off-by: Wei Liu
---
tools/xl/Makefile | 1 +
tools/xl/xl_cmdimpl.c | 122
tools/xl/xl_vtpm.c| 153 ++
3 files changed, 154 insertions(+), 122 deletions(-)
create mode 100644 tools/xl/xl_vtpm
Signed-off-by: Wei Liu
---
tools/xl/Makefile | 2 +-
tools/xl/xl_cmdimpl.c | 247
tools/xl/xl_pci.c | 278 ++
3 files changed, 279 insertions(+), 248 deletions(-)
create mode 100644 tools/xl/xl
1 - 100 of 129 matches
Mail list logo
