flight 66922 linux-mingo-tip-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/66922/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-pvops 5 kernel-build fail REGR. vs. 60684
build-amd6
flight 66879 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/66879/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-rumpuserxen-i386 10 guest-startfail like 66415
test-amd64-i386-xl-qemuu-win7
> From: Xu, Quan
> Sent: Tuesday, December 22, 2015 6:26 PM
>
> > On 22.12.2015 at 5:09pm, wrote:
> > >>> On 22.12.15 at 09:43, wrote:
> > > Let's finish our discussion. I accept your idea. But I need to
> > > separate it into 3 patch set (It is complicated for me, sometime it makes
> > > me
>
> From: Boris Ostrovsky [mailto:boris.ostrov...@oracle.com]
> Sent: Wednesday, December 23, 2015 12:25 AM
>
> Current Intel VPMU emulation needs to perform more checks when writing
> PMU MSRs on guest's behalf:
> * MSR_CORE_PERF_GLOBAL_CTRL is not checked at all
> * MSR_CORE_PERF_FIXED_CTR_CTRL ha
> -Original Message-
> From: Tian, Kevin
> Sent: Wednesday, December 23, 2015 1:17 PM
> To: Wu, Feng ; Dario Faggioli ;
> xen-devel@lists.xen.org
> Cc: Keir Fraser ; George Dunlap ;
> Andrew Cooper ; Jan Beulich
>
> Subject: RE: [Xen-devel] [PATCH v10 6/7] vmx: VT-d posted-interrupt core
> From: Wu, Feng
> Sent: Wednesday, December 23, 2015 10:29 AM
> >
> > > +}
> > > +
> > > +static void vmx_pi_state_to_normal(struct vcpu *v)
> > > +{
> > >
> > I'm still a bit puzzled about the name... But it's better than in the
> > previous round, and I can't suggest a solution that I would like
flight 66869 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/66869/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-rumpuserxen-i386 10 guest-start fail REGR. vs. 63732
Tests which are failin
Hi Jan,
Kevin and Dario gave some comments about this patch. I would like to
know whether you have any comments about this patch, it is highly
appreciated if you can give your opinions, which is very important for
it to get merged as soon as possible. Thank you!
Thanks,
Feng
> -Original Mess
> -Original Message-
> From: Dario Faggioli [mailto:dario.faggi...@citrix.com]
> Sent: Wednesday, December 23, 2015 10:21 AM
> To: Wu, Feng ; xen-devel@lists.xen.org
> Cc: Tian, Kevin ; Keir Fraser ; George
> Dunlap ; Andrew Cooper
> ; Jan Beulich
> Subject: Re: [Xen-devel] [PATCH v10 6/
Add pvusb commands: usbctrl-attach, usbctrl-detach, usb-list,
usbdev-attach and usbdev-detach.
To attach a usb device to guest through pvusb, one could follow
following example:
#xl usbctrl-attach test_vm version=1 ports=8
#xl usb-list test_vm
will show the usb controllers and port usage unde
Add code to support pvusb in domain config file. One could specify
usbctrl and usb in domain's configuration file and create domain,
then usb controllers will be created and usb device would be attached
to guest automatically.
One could specify usb controllers and usb devices in config file
like t
Signed-off-by: Chunyan Liu
Signed-off-by: Simon Cao
Reviewed-by: Wei Liu
---
tools/libxl/libxl.c | 5 ++---
tools/libxl/libxl_internal.h | 3 +++
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 00d9ec4..43d5709 100644
--- a
This patch series is to add pvusb toolstack work, supporting hot add|remove
USB device to|from guest and specify USB device in domain configuration file.
Changes to V11:
* remov unnecessary check in patch 2/5
V11:
http://lists.xen.org/archives/html/xen-devel/2015-12/msg01626.html
V10:
http://lis
Add pvusb APIs, including:
- attach/detach (create/destroy) virtual usb controller.
- attach/detach usb device
- list usb controller and usb devices
- some other helper functions
Signed-off-by: Chunyan Liu
Signed-off-by: Simon Cao
Signed-off-by: George Dunlap
Reviewed-by: George Dunlap
---
Add a new function libxl_read_sysfs_file_contents to handle sysfs file
specially. It would be used in later pvusb work.
Signed-off-by: Chunyan Liu
---
Changes:
* remove unnecessary null pointer check after libxl__alloc and
libxl__realloc
tools/libxl/libxl_internal.h | 4 +++
tools/libxl/
Here I am,
On Thu, 2015-12-03 at 16:35 +0800, Feng Wu wrote:
> This is the core logic handling for VT-d posted-interrupts. Basically
> it
> deals with how and when to update posted-interrupts during the
> following
> scenarios:
> - vCPU is preempted
> - vCPU is slept
> - vCPU is blocked
>
> [..]
flight 66864 xen-4.4-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/66864/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-prev 5 xen-build fail REGR. vs. 66458
build-i386-prev
flight 66870 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/66870/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail REGR.
vs. 65543
test-amd64-amd64-
flight 66856 xen-4.5-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/66856/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 66426
test-amd64-amd64-
> On Tue, Dec 22, 2015 at 21:59 +0100, Mike Belopuhov wrote:
> > Hi,
> >
> > I'm trying to get grant table sub page mappings working on Xen 4.5.
> > I know there have been some changes in the trunk regarding moving src/
> > dst checks closer together, but I can't test this easily atm. Please
> >
On Tue, 22 Dec 2015 17:32:30 +0100 Vitaly Kuznetsov wrote:
> Currently, all newly added memory blocks remain in 'offline' state unless
> someone onlines them, some linux distributions carry special udev rules
> like:
>
> SUBSYSTEM=="memory", ACTION=="add", ATTR{state}=="offline",
> ATTR{state}=
On 22/12/2015 21:26, Doug Goldstein wrote:
> diff --git a/INSTALL b/INSTALL
> index c51447b..3d2e86a 100644
> --- a/INSTALL
> +++ b/INSTALL
> @@ -275,14 +275,10 @@ Building the python tools may fail unless certain
> options are passed to
> setup.py. Config.mk contains additional info how to use t
Converts the existing XSM_ENABLE flag from Config.mk to CONFIG_XSM
within Kconfig. This also re-adds the dependency of CONFIG_FLASK on
CONFIG_XSM.
CC: Daniel De Graaf
CC: Keir Fraser
CC: Jan Beulich
CC: Andrew Cooper
Signed-off-by: Doug Goldstein
---
Config.mk| 3 ---
IN
Converts the Config.mk option of FLASK_ENABLE into a Kconfig option for
the hypervisor called CONFIG_FLASK. This commit knowingly breaks the
dependent relationship on XSM_ENABLE which is addressed when XSM_ENABLE
is converted to Kconfig.
CC: Daniel De Graaf
Signed-off-by: Doug Goldstein
---
Con
On 22/12/15 20:59, Mike Belopuhov wrote:
> Hi,
>
> I'm trying to get grant table sub page mappings working on Xen 4.5.
> I know there have been some changes in the trunk regarding moving src/
> dst checks closer together, but I can't test this easily atm. Please
> bear with me for a moment. Or te
Hi,
I'm trying to get grant table sub page mappings working on Xen 4.5.
I know there have been some changes in the trunk regarding moving src/
dst checks closer together, but I can't test this easily atm. Please
bear with me for a moment. Or tell me that it might have been broken
previously.
Wh
Hi Stefano,
[auto build test WARNING on arm/for-next]
[also build test WARNING on v4.4-rc6 next-20151222]
url:
https://github.com/0day-ci/linux/commits/Stefano-Stabellini/arm-remove-CPU_V6-and-GENERIC_ATOMIC64-build-dependencies-for-XEN/20151222-222129
base: http://repo.or.cz/linux-2.6
On Tue, 10 Nov 2015, Ian Campbell wrote:
> ... instead of artificially masking the timer interrupt in the timer
> state and relying on the guest to unmask (which it isn't required to
> do per the h/w spec, although Linux does).
>
> By using the newly added hwppi save/restore functionality we make
In antcipation of XSM and FLASK migrating to Kconfig add support for
building them via Kconfig or the existing mechanism.
Signed-off-by: Doug Goldstein
---
I have not tested this because I'm honestly not sure and I'm not sure if
this is correct. I'm just trying to write something to prevent a fai
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Xen Security Advisory CVE-2015-8615 / XSA-169
version 2
x86: unintentional logging upon guest changing callback method
UPDATES IN VERSION 2
CVE assigned.
ISSUE DESCRIPTION
=
Provide EMUID_PV and use it appropriately. We split our qemus into
two:
EMUID_DM does actual emulation. EMUID_PV is for PV backends. Most
places relate to emulation and can simply pass EMUID_DM.
Creation is a notable exception, where we pass the emuid as a new
parameter to the spawn functions.
Combine two identical calls to libxl__device_model_xs_path, for
clarity.
No functional change.
Signed-off-by: Ian Jackson
---
v6: New patch.
---
tools/libxl/libxl_dm.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
If the pid is absent in xenstore, this means there is no such DM. Do
not complain about this, then. This allows us to simplify call sites.
Do so for libxl__destroy_domid.
Signed-off-by: Ian Jackson
---
v6: New patch.
---
tools/libxl/libxl.c|4 +---
tools/libxl/libxl_dm.c |7 ++-
From: Stefano Stabellini
We actually need to spawn a second QEMU if we want to run qemu as
non-root, because the pv backends ought to run as root (or device
hotplug may not work).
So in this case, start a second QEMU to provide PV backends in
userspace to HVM guests. Use both dcs->dmss.pvqemu a
Change the order of operations so that the dm determination and
destruction occur together.
The functional change is that the xenstore reads relating to the dm
determination now occur after the pci devices have been removed and
the domain has been paused. This should not have any visible effect.
If QEMU supports xsrestrict, pass xsrestrict=on to it (by default).
XXX We need to do this only if xenstored supports it, and AFAICT there
is not a particularly easy way to test this. Should we open a new
test xenstore connection to query this information ? We could do this
once per libxl ctx.
When creating a domain (including when restoring), invoke the
dm_support_check machinery on the principal qemu dm (if applicable).
This involves another introducing function callback boundary in the
domcreate control flow; but this is a straightforward one.
Now, libxl__dm_supported is available (
This is a new version of Stefano Stabellini's series
[PATCH v5 0/6] libxl: xs_restrict QEMU
I took Stefano's code as a spec for how to interact with qemu, and
have reworked the whole series. In particular, I have
- rebased onto staging
- split up some of the larger patches
- restructured the
Add a maximum limit of physmap entries to save, so that when the guest
gets write access to physmap it cannot DOS the toolstack.
Signed-off-by: Stefano Stabellini
Signed-off-by: Ian Jackson
---
v6: Split out of xs permissions relaxation patch.
---
tools/libxl/libxl_dom.c |7 +++
1 file
This is used in a driver domain context and doesn't get the caller's
domid. But that's OK, we can now use libxl__dm_xs_path_rel which
returns the same value as previously.
No functional change.
Signed-off-by: Ian Jackson
---
tools/libxl/libxl_dm.c |2 +-
1 file changed, 1 insertion(+), 1 d
This allows code elsewhere in libxl to find out what options a device
model executable supports. This is done by searching the usage
message for fixed strings.
Because this involves calling fork, callers must use the async
machinery. To make this easier, and to avoid repeatedly invoking the
dm,
Previously this option would be silently ignored, which is a potential
security problem (introduced in 84f2fd1b "run QEMU as non-root" in
xen-unstable only).
Signed-off-by: Ian Jackson
CC: Stefano Stabellini
---
v6: New patch.
---
tools/libxl/libxl_dm.c |8
1 file changed, 8 insert
Rather than recomputing this with a switch() statement, etc., we rely
on the emuidmap to tell us which qemus to destroy.
Signed-off-by: Ian Jackson
---
v6: New patch. This is a new approach in v6.
squash! libxl: Pass emuid to dm destruction
---
tools/libxl/libxl.c | 31 -
Record in xenstore which emulator(s) we have started. Right now this
information is not used.
The _get_bodgeerrors function is going to be needed in several call
sites where errors are currently not handled well. I don't want to
try to combine an error handling rework with this series.
Signed-o
This means that callers in libxl_internal.h can use it (eg, inline
functions). No functional change.
Signed-off-by: Ian Jackson
---
v6: New patch.
---
tools/libxl/libxl_internal.h |5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/tools/libxl/libxl_internal.h b/tools/li
This is going to be much more convenient in a moment, when one of the
call sites is going to want to run two in parallel.
No functional change.
Signed-off-by: Ian Jackson
---
v6: New patch.
---
tools/libxl/libxl.c |4 ++--
tools/libxl/libxl_create.c | 14 +++---
tools/l
Signed-off-by: Ian Jackson
---
v6: New patch.
---
tools/libxl/libxl_types_internal.idl |2 ++
1 file changed, 2 insertions(+)
diff --git a/tools/libxl/libxl_types_internal.idl
b/tools/libxl/libxl_types_internal.idl
index 5e55685..4397141 100644
--- a/tools/libxl/libxl_types_internal.idl
+++
This gives a relative path, suitable for driver domains. It will be
used shortly.
No functional change.
Signed-off-by: Ian Jackson
---
v6: New patch
---
tools/libxl/libxl_internal.c | 10 --
tools/libxl/libxl_internal.h |4
2 files changed, 12 insertions(+), 2 deletions(-)
This condenses a number of repetetive calls to
libxl__device_model_xs_path. No functional change.
Signed-off-by: Ian Jackson
---
v6: New patch.
---
tools/libxl/libxl_pci.c | 24 +---
1 file changed, 17 insertions(+), 7 deletions(-)
diff --git a/tools/libxl/libxl_pci.c b/t
We are going to want this shortly.
No functional change.
Signed-off-by: Ian Jackson
---
v6: New patch.
---
tools/libxl/libxl_create.c |9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 71893c5..b41c6bd 10
No functional change yet.
Signed-off-by: Ian Jackson
---
tools/libxl/libxl_dm.c |8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index bcae664..5b56047 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@
Move the dm user defaulting from libxl__build_device_model_args_new
earlier in domain create. We now do it just after the dm support
check has finished.
Convey the result to the dm args constructor in the b_info, ie in the
supplied config. So, the application's supplied config is filled in
with
We are going to want to run two qemus, which will mean them having
different xs control paths. But sometimes we will run only one qemu
to do both jobs, in which case there has to be one xs control path,
because otherwise the single qemu will only see in xenstore either the
HVM DM work to do, or th
We are going to want to talk to two different qemus for some domains.
This will involve a different xenstore path for the two qemus, so
libxl__device_model_xs_path will need to take a parameter to say which.
Most call sites will want to talk to the main (device model, `DM')
emulator. So introduce
Introduce libxl__dm_xs_pid_path and use it everywhere.
There is no overall functional change, although there is a change to
these internal paths. Also, the paths used are now relative (ie to
/local/domain/) rather than absolute.
Signed-off-by: Stefano Stabellini
Signed-off-by: Ian Jackson
---
Move
- the error log message
- the call to libxl__qmp_cleanup
into libxl__destroy_device_model from the one call site in
libxl__destroy_domid.
We are going to want to call libxl__destroy_device_model more than
once, and this code would otherwise need to be repeated for the other
call site(s).
T
Take some improvements from libxl__destroy_qdisk_backend:
* Use libxl__xs_rm_checked rather than xs_rm
* Remove the pid from xenstore
Then libxl__destroy_qdisk_backend can be made into a simple wrapper
around libxl__destroy_device_model.
Signed-off-by: Ian Jackson
---
v6: New patch.
---
tools/l
Signed-off-by: Ian Jackson
CC: Stefano Stabellini
---
v6: New patch
---
docs/man/xl.cfg.pod.5 |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
index 8899f75..dd93725 100644
--- a/docs/man/xl.cfg.pod.5
+++ b/docs/man/xl.cfg.pod
Rather than open-coding the answer. We are going to change this path.
No functional change (other than to very unlikely error paths).
Signed-off-by: Stefano Stabellini
Signed-off-by: Ian Jackson
---
v6: Broken out from a portmanteau patch which was in v5, and fixed.
---
tools/libxl/libxl_dm.c
On Tue, 10 Nov 2015, Ian Campbell wrote:
> Currently this has only a single caller, which I intend to teach about
> injecting PPIs shortly. This helper doesn't add much so remove it.
>
> Drop a stray tab from the comment immediately preceding this change.
>
> Signed-off-by: Ian Campbell
Acked-b
Hi all,
iommu=no-igfx is a gamechanger for Qubes support through 3.1 RC1 release,
thanks to Xen 4.6 :)
The Lenovo X200 supports vt-x, vt-d and TPM as reported and required by
Qubes in the HCL attached to this e-mail. The problem is that when Qubes
launches it's netvm which uses IOMMU to talk to i
flight 66834 linux-3.16 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/66834/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-rumpuserxen-i386 10 guest-start fail REGR. vs. 64969
Tests which are failin
On 22/12/15 17:14, Jan Beulich wrote:
On 16.12.15 at 22:24, wrote:
>> Calculate and expose the raw featureset to userspace. This is for
>> informational purposes; the difference between the raw and the host
>> featuresets are the features Xen has specifically chosen not to use.
> And what us
On 22/12/15 17:11, Jan Beulich wrote:
On 16.12.15 at 22:24, wrote:
>> @@ -22,6 +24,27 @@ void __init calculate_featuresets(void)
>>
>> /* Unconditionally claim to be able to set the hypervisor bit. */
>> __set_bit(X86_FEATURE_HYPERVISOR, pv_featureset);
>> +
>> +/* HVM feature
>>> On 22.12.15 at 18:13, wrote:
> On 22/12/15 17:07, Jan Beulich wrote:
> On 16.12.15 at 22:24, wrote:
>>> --- a/xen/arch/x86/cpuid/cpuid.c
>>> +++ b/xen/arch/x86/cpuid/cpuid.c
>>> @@ -102,7 +102,11 @@ const uint32_t
>>> known_features[XEN_NR_FEATURESET_ENTRIES]
> =
>>>
On 22/12/15 16:46, Jan Beulich wrote:
On 16.12.15 at 22:24, wrote:
>> --- a/xen/arch/x86/cpu/amd.c
>> +++ b/xen/arch/x86/cpu/amd.c
>> @@ -481,7 +481,7 @@ static void __devinit init_amd(struct cpuinfo_x86 *c)
>>
>> if (c->extended_cpuid_level >= 0x8007) {
>> c->x86_powe
>>> On 16.12.15 at 22:24, wrote:
> Calculate and expose the raw featureset to userspace. This is for
> informational purposes; the difference between the raw and the host
> featuresets are the features Xen has specifically chosen not to use.
And what use is this? Looks like dead code to me...
J
On 22/12/15 17:07, Jan Beulich wrote:
On 16.12.15 at 22:24, wrote:
>> --- a/xen/arch/x86/cpuid/cpuid.c
>> +++ b/xen/arch/x86/cpuid/cpuid.c
>> @@ -102,7 +102,11 @@ const uint32_t
>> known_features[XEN_NR_FEATURESET_ENTRIES] =
>> cpufeat_mask(X86_FE
>>> On 16.12.15 at 22:24, wrote:
> @@ -22,6 +24,27 @@ void __init calculate_featuresets(void)
>
> /* Unconditionally claim to be able to set the hypervisor bit. */
> __set_bit(X86_FEATURE_HYPERVISOR, pv_featureset);
> +
> +/* HVM featureset. */
> +if ( hvm_enabled )
> +{
>
>>> On 16.12.15 at 22:24, wrote:
> --- a/xen/arch/x86/cpuid/cpuid.c
> +++ b/xen/arch/x86/cpuid/cpuid.c
> @@ -102,7 +102,11 @@ const uint32_t known_features[XEN_NR_FEATURESET_ENTRIES]
> =
> cpufeat_mask(X86_FEATURE_CAT)
> |
>
On 22/12/15 16:32, Jan Beulich wrote:
On 16.12.15 at 22:24, wrote:
>> --- /dev/null
>> +++ b/xen/arch/x86/cpuid/cpuid-private.h
>> @@ -0,0 +1,27 @@
>> +#ifdef __XEN__
>> +
>> +#include
>> +
>> +#include
>> +
>> +#else
>> +
>> +# error TODO for userspace
> I suppose your intentions with this
On 22/12/15 16:42, Jan Beulich wrote:
On 16.12.15 at 22:24, wrote:
>> --- a/xen/arch/x86/cpu/common.c
>> +++ b/xen/arch/x86/cpu/common.c
>> @@ -324,6 +324,7 @@ void __cpuinit identify_cpu(struct cpuinfo_x86 *c)
>> * we do "generic changes."
>> */
>> for (i = 0; i < XEN_NR_FEA
>>> On 22.12.15 at 17:42, wrote:
> On 22/12/15 16:28, Jan Beulich wrote:
> On 16.12.15 at 22:24, wrote:
>>> +/* VIA/Cyrix/Centaur-defined CPU features, CPUID level 0xC001, FSMAX+2
>>> */
>>> +#define X86_FEATURE_XSTORE ((FSMAX+1)*32+ 2) /* on-CPU RNG present (xstore
>>> insn) */
>>> +#d
>>> On 16.12.15 at 22:24, wrote:
> @@ -190,6 +191,56 @@ long arch_do_sysctl(
> }
> break;
>
> +case XEN_SYSCTL_get_featureset:
> +{
> +uint32_t *featureset;
const
> +unsigned int nr;
> +
> +/* Request for maximum number of features? */
> +
On Tue, 10 Nov 2015, Ian Campbell wrote:
> s/it/if/ makes more sense.
>
> Signed-off-by: Ian Campbell
Acked-by: Stefano Stabellini
> xen/include/asm-arm/vgic.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/xen/include/asm-arm/vgic.h b/xen/include/asm-arm/vgic.h
>
On Tue, 10 Nov 2015, Ian Campbell wrote:
> Signed-off-by: Ian Campbell
Acked-by: Stefano Stabellini
> xen/include/asm-arm/domain.h | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
> index e7e40da..
>>> On 16.12.15 at 22:24, wrote:
> xen/arch/x86/Makefile | 1 +
> xen/arch/x86/cpuid.c| 23 +++
> xen/arch/x86/setup.c| 3 +++
> xen/include/asm-x86/cpuid.h | 22 ++
> 4 files changed, 49 insertions(+)
> create mode 100644 xen/arch/
>>> On 16.12.15 at 22:24, wrote:
> --- a/xen/arch/x86/cpu/amd.c
> +++ b/xen/arch/x86/cpu/amd.c
> @@ -481,7 +481,7 @@ static void __devinit init_amd(struct cpuinfo_x86 *c)
>
> if (c->extended_cpuid_level >= 0x8007) {
> c->x86_power = cpuid_edx(0x8007);
> -
On Thu, 17 Dec 2015, Ian Campbell wrote:
> > > +/* Save PPI and SGI states (per-CPU) */
> > > +spin_lock(&v->arch.vgic.lock);
> >
> > vgic_lock
>
> Ah, yes, this function was originally in save.c so didn't have access, but
> now it is in the right place I should use all the correct
On 22/12/15 16:28, Jan Beulich wrote:
On 16.12.15 at 22:24, wrote:
>> +/* VIA/Cyrix/Centaur-defined CPU features, CPUID level 0xC001, FSMAX+2
>> */
>> +#define X86_FEATURE_XSTORE ((FSMAX+1)*32+ 2) /* on-CPU RNG present (xstore
>> insn) */
>> +#define X86_FEATURE_XSTORE_EN ((FSMAX
>>> On 16.12.15 at 22:24, wrote:
> --- a/xen/arch/x86/cpu/common.c
> +++ b/xen/arch/x86/cpu/common.c
> @@ -324,6 +324,7 @@ void __cpuinit identify_cpu(struct cpuinfo_x86 *c)
>* we do "generic changes."
>*/
> for (i = 0; i < XEN_NR_FEATURESET_ENTRIES; ++i) {
> + c-
On 22/12/15 10:30, Huaitong Han wrote:
> Protection keys define a new 4-bit protection key field(PKEY) in bits 62:59 of
> leaf entries of the page tables.
>
> PKRU register defines 32 bits, there are 16 domains and 2 attribute bits per
> domain in pkru, for each i (0 ≤ i ≤ 15), PKRU[2i] is the acce
>>> On 16.12.15 at 22:24, wrote:
> --- /dev/null
> +++ b/xen/arch/x86/cpuid/cpuid-private.h
> @@ -0,0 +1,27 @@
> +#ifdef __XEN__
> +
> +#include
> +
> +#include
> +
> +#else
> +
> +# error TODO for userspace
I suppose your intentions with this will become apparent in later
patches?
Jan
_
Currently, all newly added memory blocks remain in 'offline' state unless
someone onlines them, some linux distributions carry special udev rules
like:
SUBSYSTEM=="memory", ACTION=="add", ATTR{state}=="offline", ATTR{state}="online"
to make this happen automatically. This is not a great solution
>>> On 16.12.15 at 22:24, wrote:
> --- a/xen/include/public/arch-x86/featureset.h
> +++ b/xen/include/public/arch-x86/featureset.h
> @@ -163,6 +163,7 @@
>
> /* Intel-defined CPU features, CPUID level 0x0007:0.ebx, word 5 */
> #define X86_FEATURE_FSGSBASE ( 5*32+ 0) /* {RD,WR}{FS,GS}BA
>>> On 16.12.15 at 22:24, wrote:
> +/* VIA/Cyrix/Centaur-defined CPU features, CPUID level 0xC001, FSMAX+2 */
> +#define X86_FEATURE_XSTORE ((FSMAX+1)*32+ 2) /* on-CPU RNG present (xstore
> insn) */
> +#define X86_FEATURE_XSTORE_EN((FSMAX+1)*32+ 3) /* on-CPU RNG enabled
> */
> +#de
Current Intel VPMU emulation needs to perform more checks when writing
PMU MSRs on guest's behalf:
* MSR_CORE_PERF_GLOBAL_CTRL is not checked at all
* MSR_CORE_PERF_FIXED_CTR_CTRL has more reserved bits in PMU version 2
* MSR_CORE_PERF_GLOBAL_OVF_CTRL's bit 61 is allowed on versions greater
* than
The Xen toolstack uses "vhd" to specify a disk in VHD format, however
the name of the driver in QEMU is "vpc". Replace "vhd" with "vpc", so
that QEMU can find the right driver to use for it.
Signed-off-by: Stefano Stabellini
---
hw/block/xen_disk.c |3 +++
1 file changed, 3 insertions(+)
di
From: Jan Beulich
Introduce yet another mask for them, so that the generic routine can
handle them, at once rendering xen_pt_pmcsr_reg_write() superfluous.
Signed-off-by: Jan Beulich
Signed-off-by: Stefano Stabellini
Reviewed-by: Stefano Stabellini
---
hw/xen/xen_pt.h |2 ++
From: Jan Beulich
The way the generic infrastructure works the intention of not allowing
unaligned accesses can't be achieved by simply setting .unaligned to
false. The benefit is that we can now replace the conditionals in
{get,set}_entry_value() by assert()-s.
Signed-off-by: Jan Beulich
Signe
From: Jan Beulich
The remaining log message in pci_msix_write() is wrong, as there guest
behavior may only appear to be wrong: For one, the old logic didn't
take the mask-all bit into account. And then this shouldn't depend on
host device state (i.e. the host may have masked the entry without the
The following changes since commit c3626ca7df027dabf0568284360a23faf18f0884:
Update version for v2.5.0-rc3 release (2015-12-07 17:47:40 +)
are available in the git repository at:
git://xenbits.xen.org/people/sstabellini/qemu-dm.git tags/xen-2015-12-22
for you to fetch changes up to fc3e
>>> On 17.12.15 at 17:31, wrote:
> --- a/xen/common/page_alloc.c
> +++ b/xen/common/page_alloc.c
> @@ -1786,6 +1786,57 @@ int assign_pages(
> return -1;
> }
>
> +int steal_page(
> +struct domain *d, struct page_info *page, unsigned int memflags)
> +{
I think it would better go into co
>>> On 17.12.15 at 17:31, wrote:
> Direct mapped domain needs to retrieve the exact same underlying
> physical page when the region is re-populated.
In which case - what sense does it make for such a domain to
exchange memory (the primary purpose of which is to get
_different_ memory populated at
>>> On 17.12.15 at 17:31, wrote:
> I've looked at reworking XENMEM_exchange to avoid mfn_to_gmfn. My idea would
> be to allocate a temporary array to store the GFN between the two loops.
> However, the array would be quite large (the max default is 18 on ARM),
> so I don't know if it's acceptable.
>>> On 22.12.15 at 17:02, wrote:
> How does it not make sense in this case? That's what Andrew and I are
> asking you to explain.
But I already explained it: The file isn't needed for booting.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
ht
On Tue, 22 Dec 2015, Russell King - ARM Linux wrote:
> On Tue, Dec 22, 2015 at 03:45:19PM +, Stefano Stabellini wrote:
> > The code builds, but of course it could not actually run on CPU_V6. But
> > the use case for me is building drivers/xen/grant-table.c, which can
> > only run on CPU_V7 anyw
On 12/22/15 9:59 AM, Jan Beulich wrote:
On 22.12.15 at 15:46, wrote:
>> On 22/12/15 12:52, Jan Beulich wrote:
>> On 22.12.15 at 13:45, wrote:
On 12/21/15 9:35 AM, Jan Beulich wrote:
On 21.12.15 at 16:20, wrote:
>> On 12/21/15 8:51 AM, Jan Beulich wrote:
>> On 2
>>> On 22.12.15 at 15:46, wrote:
> On 22/12/15 12:52, Jan Beulich wrote:
> On 22.12.15 at 13:45, wrote:
>>> On 12/21/15 9:35 AM, Jan Beulich wrote:
>>> On 21.12.15 at 16:20, wrote:
> On 12/21/15 8:51 AM, Jan Beulich wrote:
> On 21.12.15 at 15:35, wrote:
>>> On 12/21/15 6
On Tue, Dec 22, 2015 at 03:45:19PM +, Stefano Stabellini wrote:
> The code builds, but of course it could not actually run on CPU_V6. But
> the use case for me is building drivers/xen/grant-table.c, which can
> only run on CPU_V7 anyway, so it is not a problem.
What I'm concerned about in this
1 - 100 of 173 matches
Mail list logo
