>>> On 21.01.16 at 02:29, wrote:
> The platform device passthrough part for arm is to mapping the machine io
> address
> to the guest physical io address. Then guest can map the phsical io address
> to its
> own virtual address, then by accessing virtual address, guest can access
> machine io a
>>> On 20.01.16 at 19:32, wrote:
> On 18/01/16 15:53, Andrew Cooper wrote:
>> Looking at the XenServer patch queue, I have a few nominations for
>> backports.
>>
>> Hypervisor:
>> 22a1fbb575df "x86/hvm: make sure stdvga cache cannot be re-enabled"
>
> This patch appears to have been missed in the
>>> On 20.01.16 at 18:36, wrote:
> (As a side --- XSA-163 says that VPMU is "unsupported security-wise". Do
> we make any distinction between a feature being generally or
> security-wise unsupported?)
Not sure; considering stable tree maintenance one might imply
general support to be a superset
flight 78586 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/78586/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-multivcpu 6 xen-boot fail REGR. vs. 59254
test-armhf-armhf-xl-c
On 21/01/16 07:31, Platform Team regression test user wrote:
> This run is configured for baseline tests only.
>
> flight 38676 xen-4.5-testing real [real]
> http://osstest.xs.citrite.net/~osstest/testlogs/logs/38676/
I've seen this more than once now: some test results seem not to be
reachable f
This run is configured for baseline tests only.
flight 38676 xen-4.5-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38676/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64
+ * To solve this problem linker tables can be used on Linux, it enables you to
+ * always force compiling of select features that one wishes to avoid bit-rot
+ * while still enabling you to disable linking feature code into the final
+ * kernel image or building certain modules if the features ha
On 01/20/2016 11:41 PM, Konrad Rzeszutek Wilk wrote:
> Neither of these are sufficient however. That gets Qemu a mapping of
> the NVDIMM, not the guest. Something, one way or another, has to turn
> this into appropriate add-to-phymap hypercalls.
>
Yes, those hypercalls
On 01/20/16 12:18, Konrad Rzeszutek Wilk wrote:
> > c) hotplug support
> > >>>
> > >>>How does that work? Ah the _DSM will point to the new ACPI NFIT for the
> > >>>OS
> > >>>to scan. That would require the hypervisor also reading this for it to
> > >>>update it's data-structures.
> > >>
> > >
Joao Martins wrote:
> As suggested in a previous thread [0] this patch adds some missing calls
> to libxl_dominfo_dispose when doing some of the libxl_domain_info
> operations which would otherwise lead to memory leaks.
>
> [0]
> https://www.redhat.com/archives/libvir-list/2015-September/msg00519.
flight 78614 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/78614/
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-
Hi Jan,
On Wed, Jan 20, 2016 at 07:52:58AM -0700, Jan Beulich wrote:
On 20.01.16 at 15:37, wrote:
>> On Wed, Jan 20, 2016 at 07:16:36AM -0700, Jan Beulich wrote:
>> On 20.01.16 at 15:05, wrote:
On Wed, Jan 20, 2016 at 05:01:40AM -0700, Jan Beulich wrote:
On 20.01.16 at 12:
flight 78582 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/78582/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass
test-armhf-armhf-libvirt-xsm 14 guest-saver
This run is configured for baseline tests only.
flight 38674 xen-4.6-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38674/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-rumpuserxen-amd64 3 host-i
On January 20, 2016 3:15:48 PM PST, Michael Brown wrote:
>>> + * To solve this problem linker tables can be used on Linux, it
>enables you to
>>> + * always force compiling of select features that one wishes to
>avoid bit-rot
>>> + * while still enabling you to disable linking feature code into
>t
flight 78529 xen-4.5-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/78529/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail REGR. vs. 77666
test-amd64-amd64-xl-rtds
On Fri, Jan 15, 2016 at 03:47:25PM -0800, Andy Lutomirski wrote:
> On Fri, Jan 15, 2016 at 2:08 PM, Luis R. Rodriguez wrote:
> > I will be respinning the generic Linux linker table solution [0] soon
> > based on hpa's feedback again now that I'm back from vacation. As I do
> > that though I wanted
On January 20, 2016 2:12:49 PM PST, "Luis R. Rodriguez"
wrote:
>On Wed, Jan 20, 2016 at 1:41 PM, H. Peter Anvin wrote:
>> On 01/20/16 13:33, Luis R. Rodriguez wrote:
>>>
>>> That's correct for PV and PVH, likewise when qemu is required for
>HVM
>>> qemu could set it. I have the qemu change done
On Wed, Dec 23, 2015 at 10:06:24PM +0100, Julia Lawall wrote:
> The cleancache_ops structure is never modified, so declare it as const.
>
> This also removes the __read_mostly declaration on the cleancache_ops
> variable declaration, since it seems redundant with const.
>
> Done with the help of
On Wed, Jan 20, 2016 at 1:41 PM, H. Peter Anvin wrote:
> On 01/20/16 13:33, Luis R. Rodriguez wrote:
>>
>> That's correct for PV and PVH, likewise when qemu is required for HVM
>> qemu could set it. I have the qemu change done but that should only
>> cover HVM. A common place to set this as well c
On Tue, Dec 01, 2015 at 11:32:58PM +0100, Marek Marczykowski-Górecki wrote:
> On Tue, Dec 01, 2015 at 05:00:42PM -0500, Konrad Rzeszutek Wilk wrote:
> > On Tue, Nov 17, 2015 at 03:45:15AM +0100, Marek Marczykowski-Górecki wrote:
> > > On Wed, Oct 21, 2015 at 08:57:34PM +0200, Marek Marczykowski-Gór
On Wed, Jan 20, 2016 at 1:16 PM, Konrad Rzeszutek Wilk
wrote:
> On Tue, Dec 15, 2015 at 02:16:29PM -0800, Luis R. Rodriguez wrote:
>> From: "Luis R. Rodriguez"
>>
>> A long time ago in a galaxy far,
>> far away...
>
> :-)
>
> You wouldn't have this on a git tree by any c
This consolidates some of the different variables used for the ARM
builds. This change was prompted by the Kconfig changes but looking back
in time the CONFIG_ARM_{32,64} variables existed before Kconfig so this
should just be a generic cleanup.
Signed-off-by: Doug Goldstein
---
xen/arch/arm/Mak
On Wed, Jan 20, 2016 at 1:14 PM, Konrad Rzeszutek Wilk
wrote:
> On Tue, Dec 15, 2015 at 02:16:35PM -0800, Luis R. Rodriguez wrote:
>> From: "Luis R. Rodriguez"
>>
>> This also annotates this is only used for PC and
>> lguest hardware subarchitectures.
>>
>> Signed-off-by: Luis R. Rodriguez
>
> O
On 01/20/16 13:33, Luis R. Rodriguez wrote:
>
> That's correct for PV and PVH, likewise when qemu is required for HVM
> qemu could set it. I have the qemu change done but that should only
> cover HVM. A common place to set this as well could be the hypervisor,
> but currently the hypervisor doesn'
On Wed, Jan 20, 2016 at 1:00 PM, Konrad Rzeszutek Wilk
wrote:
>> +static bool x86_init_fn_supports_subarch(struct x86_init_fn *fn)
>> +{
>> + if (!fn->supp_hardware_subarch) {
>> + pr_err("Init sequence fails to declares any supported
>> subarchs: %pF\n", fn->early_init);
>> +
On Tue, Dec 15, 2015 at 02:16:29PM -0800, Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez"
>
> A long time ago in a galaxy far,
> far away...
:-)
You wouldn't have this on a git tree by any chance?
And thank you for doing this!
___
On Tue, Dec 15, 2015 at 02:16:37PM -0800, Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez"
>
> Using the linker table removes the need for the #ifdef'ery
> and clutter on head32.c.
Reviewed-by: Konrad Rzeszutek Wilk
>
> Signed-off-by: Luis R. Rodriguez
> ---
> arch/x86/include/asm/setup.
On Tue, Dec 15, 2015 at 02:16:36PM -0800, Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez"
>
> Using the linker table removes the need for the #ifdef'ery
> and clutter on head32.c.
>
> Signed-off-by: Luis R. Rodriguez
Reviewed-by: Konrad Rzeszutek Wilk
> ---
> arch/x86/include/asm/setup.
On Tue, Dec 15, 2015 at 02:16:35PM -0800, Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez"
>
> This also annotates this is only used for PC and
> lguest hardware subarchitectures.
>
> Signed-off-by: Luis R. Rodriguez
On Xen the code path (before this patch) was:
xen_start_kernel->i386_star
flight 78630 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/78630/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 12
> +static bool x86_init_fn_supports_subarch(struct x86_init_fn *fn)
> +{
> + if (!fn->supp_hardware_subarch) {
> + pr_err("Init sequence fails to declares any supported subarchs:
> %pF\n", fn->early_init);
> + WARN_ON(1);
> + }
> + if (BIT(boot_params.hdr.hardwa
On Tue, Dec 15, 2015 at 02:16:34PM -0800, Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez"
>
> This lets us annotate its requirements specifically for
> PC and lguest subarchitectures. While at it since head.c
> just has ebda data rename it. Since we're using linker tables
> and both x86 32-b
> diff --git a/arch/x86/Kconfig.debug b/arch/x86/Kconfig.debug
> index 137dfa96aa14..e66b030e82bc 100644
> --- a/arch/x86/Kconfig.debug
> +++ b/arch/x86/Kconfig.debug
> @@ -400,4 +400,51 @@ config PUNIT_ATOM_DEBUG
> The current power state can be read from
> /sys/kernel/debug/punit_
On Wed, Jan 20, 2016 at 12:17 PM, Konrad Rzeszutek Wilk
wrote:
> Where? Could you paste in the name of the patch in the description?
+x86_init_early(BIT(X86_SUBARCH_INTEL_MID), NULL, NULL,
+ x86_intel_mid_early_setup);
Is an example, so users of the subarch. Likewise the macro helpe
On Tue, Dec 15, 2015 at 02:16:32PM -0800, Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez"
>
> The boot/bitops.h guards against included the regular bitops,
It may sounds better this way:
The boot/bitops.h has guards against including the
regular bitops (include/asm-generic/bitops.h)
> it
Hi,
Pagetable entries are a shared medium between Xen and PV guests.
To the best of my knowledge, there is nothing written down about the ABI
here, and there are increasing problems as new hardware features become
available.
First of all, SMEP and SMAP. 32bit PV guests are subject to Xen's
SMEP
> diff --git a/Documentation/kbuild/makefiles.txt
> b/Documentation/kbuild/makefiles.txt
> index 13f888a02a3d..0a21b8db2f90 100644
> --- a/Documentation/kbuild/makefiles.txt
> +++ b/Documentation/kbuild/makefiles.txt
> @@ -1088,6 +1088,25 @@ When kbuild executes, the following steps are followed
On Tue, Dec 15, 2015 at 02:16:30PM -0800, Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez"
Hey Luis,
Sorry for the long time to respond..
>
> paravirt_enabled conveys the idea that if this is set or if
> paravirt_enabled() returns true you are in a paravirtualized
> environment. This is not
On 20/01/16 15:39, Jan Beulich wrote:
> Obtaining one individual range per variable range register (via
> get_mtrr_range()) was bogus from the beginning, as these registers may
> cover multiple disjoint ranges. Do away with that, in favor of simply
> comparing masked addresses.
>
> Also, for is_var
As suggested in a previous thread [0] this patch adds some missing calls
to libxl_dominfo_dispose when doing some of the libxl_domain_info
operations which would otherwise lead to memory leaks.
[0]
https://www.redhat.com/archives/libvir-list/2015-September/msg00519.html
Signed-off-by: Joao Martin
. From libxlMigrationBegin to libxlDomainMigrateBegin3Params().
This is a preparatory patch to be able to begin a job in the
perform phase.
Signed-off-by: Joao Martins
---
src/libxl/libxl_driver.c| 18 +-
src/libxl/libxl_migration.c | 16 +++-
2 files changed, 20
Introduce support for VIR_MIGRATE_PEER2PEER in libvirt migration.
Most of the changes occur at the source and no modifications
at the receiver.
In P2P mode there is only the Perform phase so we must handle
the connection with the destination and actually perform the
migration. libxlDomainPerformP2
Hey,
This series adds support for p2p migration: Patch 2 and 3
are new in this series and it's purpose is to take the
LIBXL_JOB_MODIFY as mentioned in the last review.
Changelog in individual patches.
Thanks,
Joao
Joao Martins (3):
libxl: add p2p migration
libxl: move begin phase job handli
Add a job LIBXL_JOB_MODIFY in the perform phase to prevent
changes to the domain from happening during migration.
Signed-off-by: Joao Martins
---
src/libxl/libxl_driver.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/src/libxl/libxl_driver.c b/src/libxl/libxl_dr
El 20/01/16 a les 14.01, Ian Campbell ha escrit:
> On Wed, 2016-01-20 at 12:57 +0100, Roger Pau Monne wrote:
>> Allow enabling or disabling emulated devices from the libxl domain
>> configuration file. For HVM guests with a device model all the emulated
>> devices are enabled. For HVM guests withou
On 18/01/16 15:53, Andrew Cooper wrote:
> Hi,
>
> Looking at the XenServer patch queue, I have a few nominations for
> backports.
>
> Hypervisor:
> 22a1fbb575df "x86/hvm: make sure stdvga cache cannot be re-enabled"
This patch appears to have been missed in the latest round of backports.
It cause
On 20/01/16 15:38, Jan Beulich wrote:
> ... to that covered by the physical address width supported by the
> processor. This implicitly avoids Dom0 (accidentally or due to some
> kind of abuse) passing out of range addresses to a guest, which in
> turn eliminates this only possibility for PV guests
Ian Campbell wrote:
> ... and consolidate the cmdline/extra/root parsing to facilitate doing
> so.
>
> The logic is the same as xl's parse_cmdline from the current xen.git master
> branch (e6f0e099d2c17de47fd86e817b1998db903cab61).
>
> In order to introduce a use of VIR_WARN for logging I had to
On 20/01/16 15:05, Stefano Stabellini wrote:
> On Wed, 20 Jan 2016, Andrew Cooper wrote:
>> On 20/01/16 14:29, Stefano Stabellini wrote:
>>> On Wed, 20 Jan 2016, Andrew Cooper wrote:
>>> I wouldn't encourage the introduction of anything else that requires
>>> root privileges in QEMU. With QEMU
On Thu, Jan 21, 2016 at 01:23:31AM +0800, Xiao Guangrong wrote:
>
>
> On 01/21/2016 01:18 AM, Konrad Rzeszutek Wilk wrote:
> >>c) hotplug support
> >
> >How does that work? Ah the _DSM will point to the new ACPI NFIT for the
> >OS
> >to scan. That would require the hypervisor
On Tue, 2016-01-19 at 15:17 +0800, Wen Congyang wrote:
> Wen Congyang (6):
> remus: don't do failover if we don't have an consistent state
> remus: don't call stream_continue() when doing failover
> remus: resume immediately if libxl__xc_domain_save_done() completes
> tools/libxc: don't sen
On 01/20/2016 12:13 PM, Jan Beulich wrote:
On 20.01.16 at 17:12, wrote:
There two patches need to be backported to 4.6
fb424bf x86/VPMU: don't allow any non-zero writes to MSR_IA32_PEBS_ENABLE
31af0d7 x86/VPMU: check more carefully which bits are allowed to be
written to MSRs
"Need to be" is
On 01/21/2016 01:18 AM, Konrad Rzeszutek Wilk wrote:
c) hotplug support
How does that work? Ah the _DSM will point to the new ACPI NFIT for the OS
to scan. That would require the hypervisor also reading this for it to
update it's data-structures.
Similar as you said. The NVDIMM root device
flight 78624 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/78624/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 12
On 01/21/2016 01:07 AM, Jan Beulich wrote:
On 20.01.16 at 16:29, wrote:
On 01/20/2016 07:20 PM, Jan Beulich wrote:
To answer this I need to have my understanding of the partitioning
being done by firmware confirmed: If that's the case, then "normal"
means the part that doesn't get exposed as
On Tue, 2016-01-19 at 17:58 +, Ian Jackson wrote:
> Andrew Cooper writes ("Re: [PATCH] tools/toollog: Drop
> XTL_NEW_LOGGER()"):
> > On 19/01/16 17:36, Ian Jackson wrote:
> > > I think this macro is useful because if you wanted to write (say)
> > > xtl_logger_syslog, you would want to use it to
> c) hotplug support
> >>>
> >>>How does that work? Ah the _DSM will point to the new ACPI NFIT for the OS
> >>>to scan. That would require the hypervisor also reading this for it to
> >>>update it's data-structures.
> >>
> >>Similar as you said. The NVDIMM root device in SSDT/DSDT dedicates a
>>> On 20.01.16 at 17:12, wrote:
> There two patches need to be backported to 4.6
>
> fb424bf x86/VPMU: don't allow any non-zero writes to MSR_IA32_PEBS_ENABLE
> 31af0d7 x86/VPMU: check more carefully which bits are allowed to be
> written to MSRs
"Need to be" is pretty strong for an unsupporte
Ian Campbell writes ("Re: [Xen-devel] OSSTEST: Re-blessing cubietruck-{picasso,
gleizes, metzinger} for production use"):
> The host console has:
>
> Jan 18 19:39:57.747858 [ 2354.661150] device vif1.0 entered promiscuous mode
> Jan 18 19:40:10.795484 [ 2354.670132] IPv6: ADDRCONF(NETDEV_UP): vif
>>> On 20.01.16 at 16:29, wrote:
> On 01/20/2016 07:20 PM, Jan Beulich wrote:
>> To answer this I need to have my understanding of the partitioning
>> being done by firmware confirmed: If that's the case, then "normal"
>> means the part that doesn't get exposed as a block device (SSD).
>> In any e
On 01/21/2016 12:47 AM, Konrad Rzeszutek Wilk wrote:
On Thu, Jan 21, 2016 at 12:25:08AM +0800, Xiao Guangrong wrote:
On 01/20/2016 11:47 PM, Konrad Rzeszutek Wilk wrote:
On Wed, Jan 20, 2016 at 11:29:55PM +0800, Xiao Guangrong wrote:
On 01/20/2016 07:20 PM, Jan Beulich wrote:
On 20.01.1
On Wed, 2016-01-20 at 11:58 +, Ian Campbell wrote:
> > > With the recent timeout fixes they are working as well as the
> > > production
> > > cubietruck-braque.
> > >
> > > There are two flakey tests test-armhf-armhf-xl-rtds and test-armhf-
> > > armhf-
> > > libvirt-raw, but those appear to b
On Thu, Jan 21, 2016 at 12:25:08AM +0800, Xiao Guangrong wrote:
>
>
> On 01/20/2016 11:47 PM, Konrad Rzeszutek Wilk wrote:
> >On Wed, Jan 20, 2016 at 11:29:55PM +0800, Xiao Guangrong wrote:
> >>
> >>
> >>On 01/20/2016 07:20 PM, Jan Beulich wrote:
> >>On 20.01.16 at 12:04, wrote:
> On 01/
On 01/20/2016 11:47 PM, Konrad Rzeszutek Wilk wrote:
On Wed, Jan 20, 2016 at 11:29:55PM +0800, Xiao Guangrong wrote:
On 01/20/2016 07:20 PM, Jan Beulich wrote:
On 20.01.16 at 12:04, wrote:
On 01/20/16 01:46, Jan Beulich wrote:
On 20.01.16 at 06:31, wrote:
Secondly, the driver implement
On Wed, 2016-01-20 at 11:58 +, Ian Campbell wrote:
>
> > > With the recent timeout fixes they are working as well as the
> > > production
> > > cubietruck-braque.
> > >
> > > There are two flakey tests test-armhf-armhf-xl-rtds and test-armhf-
> > > armhf-libvirt-raw, but those appear to be mu
On 2016/1/20 7:23, Ian Campbell wrote:
There have been a few reports recently[0] which relate to a failure of
netfront to allocate sufficient grant refs for all the queues:
[0.533589] xen_netfront: can't alloc rx grant refs
[0.533612] net eth0: only created 31 queues
Which can be worke
There two patches need to be backported to 4.6
fb424bf x86/VPMU: don't allow any non-zero writes to MSR_IA32_PEBS_ENABLE
31af0d7 x86/VPMU: check more carefully which bits are allowed to be
written to MSRs
(The second patch somewhat depends on
00e248c x86/VPMU: support only versions 2 throu
Ian Campbell writes ("[PATCH OSSTEST 3/3] Debian: erase-other-disks: rescan
partition tables after erasing whole disk"):
> This appears to happen anyway, but force it to be sure.
Acked-by: Ian Jackson
___
Xen-devel mailing list
Xen-devel@lists.xen.org
Ian Campbell writes ("[PATCH OSSTEST 2/3] Debian: erase-other-disks: erase
partitions first"):
> It seems that when sdX is zeroed there is some chance that sdX[0-9]
> will disappear before we get to them.
Acked-by: Ian Jackson
We're really pushing the commit-message-to-code ratio here :-).
Ian
Ian Campbell writes ("[PATCH OSSTEST 1/3] Debian: erase-other-disks: add a
log() helper"):
> Writing it out each time is too verbose.
>
> At the same time log the set of devices present before and after each
> batch of erasing, with a udev settle before the second to ensure any
> changes to /dev
On 01/20/16 10:41, Konrad Rzeszutek Wilk wrote:
> > > > > Neither of these are sufficient however. That gets Qemu a mapping of
> > > > > the NVDIMM, not the guest. Something, one way or another, has to turn
> > > > > this into appropriate add-to-phymap hypercalls.
> > > > >
> > > >
> > > > Yes,
On 01/20/16 14:54, Andrew Cooper wrote:
> On 20/01/16 14:47, Zhang, Haozhong wrote:
> > On 01/20/16 14:35, Stefano Stabellini wrote:
> >> On Wed, 20 Jan 2016, Zhang, Haozhong wrote:
> >>> On 01/20/16 12:43, Stefano Stabellini wrote:
> On Wed, 20 Jan 2016, Tian, Kevin wrote:
> >> From: Zhan
On Wed, Jan 20, 2016 at 11:29:55PM +0800, Xiao Guangrong wrote:
>
>
> On 01/20/2016 07:20 PM, Jan Beulich wrote:
> On 20.01.16 at 12:04, wrote:
> >>On 01/20/16 01:46, Jan Beulich wrote:
> >>On 20.01.16 at 06:31, wrote:
> Secondly, the driver implements a convenient block device inte
> > > > Neither of these are sufficient however. That gets Qemu a mapping of
> > > > the NVDIMM, not the guest. Something, one way or another, has to turn
> > > > this into appropriate add-to-phymap hypercalls.
> > > >
> > >
> > > Yes, those hypercalls are what I'm going to add.
> >
> > Why?
>
El 20/01/16 a les 13.46, Ian Campbell ha escrit:
> On Wed, 2016-01-20 at 12:57 +0100, Roger Pau Monne wrote:
>> libxl__arch_domain_prepare_config has access to the
>> libxl_domain_build_info
>> struct, so make sure it's properly initialised.
>>
>> Signed-off-by: Roger Pau Monné
>> ---
>> Cc: Ian J
Obtaining one individual range per variable range register (via
get_mtrr_range()) was bogus from the beginning, as these registers may
cover multiple disjoint ranges. Do away with that, in favor of simply
comparing masked addresses.
Also, for is_var_mtrr_overlapped()'s result to be correct when ca
... to that covered by the physical address width supported by the
processor. This implicitly avoids Dom0 (accidentally or due to some
kind of abuse) passing out of range addresses to a guest, which in
turn eliminates this only possibility for PV guests to create PTEs
with one or more reserved bits
On 01/20/2016 07:20 PM, Jan Beulich wrote:
On 20.01.16 at 12:04, wrote:
On 01/20/16 01:46, Jan Beulich wrote:
On 20.01.16 at 06:31, wrote:
Secondly, the driver implements a convenient block device interface to
let software access areas where NVDIMM devices are mapped. The
existing vNVDIMM
On Wed, 2016-01-20 at 16:32 +0100, Roger Pau Monné wrote:
> > I suspect the reason for the ordering today is that domain_make is intended
> > to consume create_info, not build_info. However that distinction seems to
> > me to be an artefact of a much older API structure which doesn't seem to
> > ma
On 01/20/16 10:13, Konrad Rzeszutek Wilk wrote:
> On Wed, Jan 20, 2016 at 10:53:10PM +0800, Haozhong Zhang wrote:
> > On 01/20/16 14:45, Andrew Cooper wrote:
> > > On 20/01/16 14:29, Stefano Stabellini wrote:
> > > > On Wed, 20 Jan 2016, Andrew Cooper wrote:
> > > >> On 20/01/16 10:36, Xiao Guangro
On Mon, Jan 11, 2016 at 3:06 PM, Malcolm Crossley
wrote:
> On 22/12/15 11:56, George Dunlap wrote:
>> On 18/12/15 16:08, Malcolm Crossley wrote:
>>>
>>> +
>>> +#ifndef NDEBUG
>>> +#define PERCPU_RW_LOCK_UNLOCKED(owner) { RW_LOCK_UNLOCKED, 0, owner }
>>> +static inline void _percpu_rwlock_owner_ch
On Wed, 2016-01-20 at 10:10 -0500, Boris Ostrovsky wrote:
> On 01/20/2016 10:02 AM, David Vrabel wrote:
> > On 20/01/16 14:52, Ian Campbell wrote:
> > > On Wed, 2016-01-20 at 09:40 -0500, Boris Ostrovsky wrote:
> > > > On 01/20/2016 07:23 AM, Ian Campbell wrote:
> > > > > There have been a few repo
On Wed, Jan 20, 2016 at 10:53:10PM +0800, Haozhong Zhang wrote:
> On 01/20/16 14:45, Andrew Cooper wrote:
> > On 20/01/16 14:29, Stefano Stabellini wrote:
> > > On Wed, 20 Jan 2016, Andrew Cooper wrote:
> > >> On 20/01/16 10:36, Xiao Guangrong wrote:
> > >>> Hi,
> > >>>
> > >>> On 01/20/2016 06:15
On 01/20/2016 10:02 AM, David Vrabel wrote:
On 20/01/16 14:52, Ian Campbell wrote:
On Wed, 2016-01-20 at 09:40 -0500, Boris Ostrovsky wrote:
On 01/20/2016 07:23 AM, Ian Campbell wrote:
There have been a few reports recently[0] which relate to a failure of
netfront to allocate sufficient grant
On 1/20/16 7:14 AM, Andrew Cooper wrote:
> On 20/01/16 12:29, Jan Beulich wrote:
> On 18.01.16 at 16:53, wrote:
>>> Possibly also:
>>> 42940c046902 "x86/shadow: Fix missing newline in dprintk()"
>> The affected statement compiles to nothing in a release build, which
>> can be taken as an argum
This run is configured for baseline tests only.
flight 38670 qemu-upstream-unstable real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38670/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvh-amd 3 host-
On Wed, Jan 20, 2016 at 07:04:49PM +0800, Haozhong Zhang wrote:
> On 01/20/16 01:46, Jan Beulich wrote:
> > >>> On 20.01.16 at 06:31, wrote:
> > > The primary reason of current solution is to reuse existing NVDIMM
> > > driver in Linux kernel.
> >
>
> CC'ing QEMU vNVDIMM maintainer: Xiao Guangron
This appears to happen anyway, but force it to be sure.
Signed-off-by: Ian Campbell
---
Osstest/Debian.pm | 9 +
1 file changed, 9 insertions(+)
diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index 20f3de7..e7b5538 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -1053,6 +1
It seems that when sdX is zeroed there is some chance that sdX[0-9]
will disappear before we get to them.
When partman comes along and recreates the partitions it is likely
that they will occupy the same disk space as before (since d-i's
autopartition is deterministic), meaning that LVM will find
This series of patches fix host installation on disks with multiple disks,
which has been failing since the update to Jessie. This has been affecting
only the *-mite and *-frog machines in the Citrix instance in Cambridge so
far, but second disks are on order for several machines in the production
Writing it out each time is too verbose.
At the same time log the set of devices present before and after each
batch of erasing, with a udev settle before the second to ensure any
changes to /dev have happened.
Signed-off-by: Ian Campbell
---
Osstest/Debian.pm | 17 +
1 file cha
On Wed, 20 Jan 2016, Andrew Cooper wrote:
> On 20/01/16 14:29, Stefano Stabellini wrote:
> > On Wed, 20 Jan 2016, Andrew Cooper wrote:
> >> On 20/01/16 10:36, Xiao Guangrong wrote:
> >>> Hi,
> >>>
> >>> On 01/20/2016 06:15 PM, Haozhong Zhang wrote:
> >>>
> CCing QEMU vNVDIMM maintainer: Xiao G
Initially reported to debian
(http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=810964), redirected here:
With AMD Opteron 6xxx processors, half of the memory controllers are
missing from /sys/devices/system/edac/mc
Checked with single 6120 (dual memory controller) and twin 6344 (2x dual
MC), other
On Wed, Jan 20, 2016 at 2:07 PM, Jan Beulich wrote:
> ... so make its return type reflect this.
>
> Signed-off-by: Jan Beulich
Acked-by: George Dunlap
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
On 20/01/16 14:52, Ian Campbell wrote:
> On Wed, 2016-01-20 at 09:40 -0500, Boris Ostrovsky wrote:
>> On 01/20/2016 07:23 AM, Ian Campbell wrote:
>>> There have been a few reports recently[0] which relate to a failure of
>>> netfront to allocate sufficient grant refs for all the queues:
>>>
>>> [
On 20/01/16 14:47, Zhang, Haozhong wrote:
> On 01/20/16 14:35, Stefano Stabellini wrote:
>> On Wed, 20 Jan 2016, Zhang, Haozhong wrote:
>>> On 01/20/16 12:43, Stefano Stabellini wrote:
On Wed, 20 Jan 2016, Tian, Kevin wrote:
>> From: Zhang, Haozhong
>> Sent: Tuesday, December 29, 2015
On 01/20/16 13:16, Andrew Cooper wrote:
> On 20/01/16 10:36, Xiao Guangrong wrote:
> >
> > Hi,
> >
> > On 01/20/2016 06:15 PM, Haozhong Zhang wrote:
> >
> >> CCing QEMU vNVDIMM maintainer: Xiao Guangrong
> >>
> >>> Conceptually, an NVDIMM is just like a fast SSD which is linearly
> >>> mapped
> >>>
>>> On 20.01.16 at 15:37, wrote:
> On Wed, Jan 20, 2016 at 07:16:36AM -0700, Jan Beulich wrote:
> On 20.01.16 at 15:05, wrote:
>>> On Wed, Jan 20, 2016 at 05:01:40AM -0700, Jan Beulich wrote:
>>> On 20.01.16 at 12:40, wrote:
> On Wed, Jan 20, 2016 at 03:14:20AM -0700, Jan Beulich wro
On 01/20/16 14:45, Andrew Cooper wrote:
> On 20/01/16 14:29, Stefano Stabellini wrote:
> > On Wed, 20 Jan 2016, Andrew Cooper wrote:
> >> On 20/01/16 10:36, Xiao Guangrong wrote:
> >>> Hi,
> >>>
> >>> On 01/20/2016 06:15 PM, Haozhong Zhang wrote:
> >>>
> CCing QEMU vNVDIMM maintainer: Xiao Gua
1 - 100 of 206 matches
Mail list logo