>>> On 08.12.15 at 15:43, wrote:
> As v is the eventual correct parameter to be passed here, I do not want
> to see it changed to a domain, just for me to revert that change shortly.
I'll take you on the "shortly" here (keeping in mind that it looks like
this was meant to happen "shortly" for qui
> -Original Message-
> From: Robert Hu [mailto:robert...@vmm.sh.intel.com]
> Sent: Wednesday, December 09, 2015 2:27 PM
> To: Ian Campbell
> Cc: Hu, Robert; Ian Jackson; Nakajima, Jun; Tian, Kevin;
> xen-de...@lists.xensource.com; osstest service owner; Jan Beulich; Andrew
> Cooper; Wang, Y
>>> On 08.12.15 at 20:53, wrote:
> On 11/30/15 8:45 AM, Jan Beulich wrote:
> On 24.11.15 at 18:51, wrote:
>>> @@ -227,9 +230,14 @@ kconfig := silentoldconfig oldconfig config menuconfig
>>> defconfig \
>>> $(kconfig):
>>> $(MAKE) -f $(BASEDIR)/scripts/kconfig/Makefile ARCH=$(XEN_TARGET_
flight 65556 xen-4.4-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/65556/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qcow2 3 host-install(3) broken REGR. vs. 64766
build-armhf
On Mon, 2015-12-07 at 15:04 +0530, Harmandeep Kaur wrote:
> Hi,
>
Hello Harmandeep,
> I am Harmandeep Kaur, Outreachy intern for December 2015 – March 2016
> round
> from India. I will be working on the project “Introducing
> PowerClamp-like driver for
> Xen” with Dario Faggioli and George Dunlap
>>> On 09.12.15 at 10:28, wrote:
> flight 65556 xen-4.4-testing real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/65556/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-amd64-amd64-xl-qcow2 3 host-install(3
On Tue, 2015-12-08 at 20:02 +, Wei Liu wrote:
> The block-attach command now returns 1 when fails. Update first test
> case to expect return value 1 instead of 255.
>
> The parser now doesn't generate output for default values. Remove them
> from expected output.
This it looks good.
> The "d
>>> On 09.12.15 at 10:47, wrote:
On 09.12.15 at 10:28, wrote:
>> flight 65556 xen-4.4-testing real [real]
>> http://logs.test-lab.xenproject.org/osstest/logs/65556/
>>
>> Regressions :-(
>>
>> Tests which did not succeed and are blocking,
>> including tests which could not be run:
>> tes
On Tue, 2015-12-08 at 18:04 +, Andrew Cooper wrote:
> On 08/12/15 17:59, Doug Goldstein wrote:
> > On 12/8/15 8:25 AM, Jan Beulich wrote:
> > > > > > On 08.12.15 at 15:16, wrote:
> > > > On 12/8/15 1:32 AM, Jan Beulich wrote:
> > > > > > > > On 07.12.15 at 22:27, wrote:
> > > > > > On 12/3/15
On Wed, Dec 09, 2015 at 10:06:17AM +, Ian Campbell wrote:
> On Tue, 2015-12-08 at 20:02 +, Wei Liu wrote:
> > The block-attach command now returns 1 when fails. Update first test
> > case to expect return value 1 instead of 255.
> >
> > The parser now doesn't generate output for default va
Ccing the vPMU maintainers.
El 07/12/15 a les 17.48, Roger Pau Monne ha escrit:
> Instead of choosing the interface to expose to guests based on the guest
> type, do it based on whether the guest has an emulated local apic or not.
>
> Signed-off-by: Roger Pau Monné
> Signed-off-by: Boris Ostrovs
On Wed, 2015-12-09 at 08:35 +, Jin, Gordon wrote:
> > -Original Message-
> > From: Robert Hu [mailto:robert...@vmm.sh.intel.com]
> > Sent: Wednesday, December 09, 2015 2:27 PM
> > To: Ian Campbell
> > Cc: Hu, Robert; Ian Jackson; Nakajima, Jun; Tian, Kevin;
> > xen-de...@lists.xensource
On Wed, Dec 09, 2015 at 10:15:35AM +, Wei Liu wrote:
> On Wed, Dec 09, 2015 at 10:06:17AM +, Ian Campbell wrote:
> > On Tue, 2015-12-08 at 20:02 +, Wei Liu wrote:
> > > The block-attach command now returns 1 when fails. Update first test
> > > case to expect return value 1 instead of 25
On Wed, 2015-12-09 at 10:24 +, Wei Liu wrote:
> On Wed, Dec 09, 2015 at 10:15:35AM +, Wei Liu wrote:
> > On Wed, Dec 09, 2015 at 10:06:17AM +, Ian Campbell wrote:
> > > On Tue, 2015-12-08 at 20:02 +, Wei Liu wrote:
> > > > The block-attach command now returns 1 when fails. Update fi
>>> On 09.12.15 at 11:13, wrote:
On 09.12.15 at 10:47, wrote:
> On 09.12.15 at 10:28, wrote:
>>> flight 65556 xen-4.4-testing real [real]
>>> http://logs.test-lab.xenproject.org/osstest/logs/65556/
>>>
>>> Regressions :-(
>>>
>>> Tests which did not succeed and are blocking,
>>> incl
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-xl-qemuu-win7-amd64
testid xen-boot
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditi
The block-attach command now returns 1 when fails. Update first test
case to expect return value 1 instead of 255.
The parser now doesn't generate output for default values. Remove them
from expected output.
According to 417e6b70 ("libxl: add option for discard support to xl disk
configuration"),
For one the uses of domu_max_order and ptdom_max_order were swapped.
And then gcc warns about an unused result of a __must_check function
in the control part of a conditional expression when both other
expressions can be determined by the compiler to produce the same value
(see https://gcc.gnu.org
flight 38469 distros-debian-squeeze real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38469/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-amd64-squeeze-netboot-pygrub 9 debian-di-install fail like
38418
baseline ver
On Wed, 2015-12-09 at 03:53 -0700, Jan Beulich wrote:
> For one the uses of domu_max_order and ptdom_max_order were swapped.
> And then gcc warns about an unused result of a __must_check function
> in the control part of a conditional expression when both other
> expressions can be determined by t
>>> On 09.12.15 at 12:02, wrote:
> On Wed, 2015-12-09 at 03:53 -0700, Jan Beulich wrote:
>> For one the uses of domu_max_order and ptdom_max_order were swapped.
>
>> And then gcc warns about an unused result of a __must_check function
>> in the control part of a conditional expression when both o
On Thu, Dec 03, 2015 at 11:21:59AM +, Ian Campbell wrote:
> As far as I can tell there is no requirement for these and it builds
> fine without them.
>
> Signed-off-by: Ian Campbell
Acked-by: Wei Liu
___
Xen-devel mailing list
Xen-devel@lists.xen
On Thu, Dec 03, 2015 at 11:22:17AM +, Ian Campbell wrote:
> The existing xc_map_foreign_bulk-like interface encourages callers to
> miss error checking for partial failure (by forgetting to scan the err
> array).
>
> Add support for passing err==NULL which behaves in a
> xc_map_foreign_pages-l
On Thu, Dec 03, 2015 at 11:22:11AM +, Ian Campbell wrote:
> It can trivially be replaced by xc_map_foreign_pages which is the
> interface I want to move to going forward (by standardising on _bulk
> but handling err=NULL as _pages does).
>
> The callers of _batch are checking a mixture of a NU
On Thu, Dec 03, 2015 at 11:21:58AM +, Ian Campbell wrote:
> From: Roger Pau Monne
>
> With the addition of HVMlite the hypervisor now always requires a non-null
> arch domain config, which is different between HVM and PV guests.
>
> Add a new parameter to xc_domain_create that contains a poi
On Thu, Dec 03, 2015 at 11:22:00AM +, Ian Campbell wrote:
> xtl doesn't require the full LDLIBS_libxenctrl, just the -L and
> xenlight.cmxa, the latter which contains LDLIBS_libxenctrl as needed.
> Fixing this avoids the need to be concerned about LDLIBS_libxenctrl
> becoming more than one word
On Thu, Dec 03, 2015 at 11:22:26AM +, Ian Campbell wrote:
> We stick with using FD_CLOEXEC on the legacy /proc/xen/privcmd
> fallback device since it was present in older kernel where O_CLOEXEC
> may not be assured.
>
> Signed-off-by: Ian Campbell
Acked-by: Wei Liu
On Thu, Dec 03, 2015 at 11:22:24AM +, Ian Campbell wrote:
> This behaviour has been confirmed by inspection on:
>
> - Linux
> - FreeBSD (NB: hcall->retval is the hypercall return value only for
>values >= 0. For negative values the underlying privcmd driver
>translates the value from
On Thu, Dec 03, 2015 at 11:22:18AM +, Ian Campbell wrote:
> By having the "num" argument before the page and error arrays we can
> potentially use a variable-length-array argument ("int pages[num]") in
> the function prototype.
>
> However VLAs are a C99 feature and we are currently targetting
On Thu, Dec 03, 2015 at 11:22:27AM +, Ian Campbell wrote:
> Use pthread_atfork to prevent the application from forking before the
> madvisoe(), which would result in CoW mappings getting passed to
madvise
> hypercalls.
>
> (largely cribbed from libxl_fork.c)
>
> Signed-off-by: Ian Campbell
On 2015/12/09 13:22, Wei Liu wrote:
> On Thu, Dec 03, 2015 at 11:22:17AM +, Ian Campbell wrote:
>> The existing xc_map_foreign_bulk-like interface encourages callers to
>> miss error checking for partial failure (by forgetting to scan the err
>> array).
>>
>> Add support for passing err==NULL w
On Thu, 2015-12-03 at 11:21 +, Ian Campbell wrote:
>
> Last time proposed that these precursors (and the corresponding qemu-xen-
> traditional + mini-os patches) should go in now:
>
> tools/Rules.mk: Properly handle libraries with recursive dependencies.
> tools: Refactor "xentoollog
On Thu, Dec 03, 2015 at 11:22:22AM +, Ian Campbell wrote:
[...]
> + * connection, connected, etc).
> + *
> + * Both ends are permitted to modify (including clear) their
> + * respective status bytes and to signal the event channel themselves
> + * from userspace.
> + *
> + * Depending on the me
On Wed, 2015-12-09 at 12:22 +, Wei Liu wrote:
> > diff --git a/tools/libs/foreignmemory/core.c
> > b/tools/libs/foreignmemory/core.c
> > index 21dc7ee..91bea55 100644
> > --- a/tools/libs/foreignmemory/core.c
> > +++ b/tools/libs/foreignmemory/core.c
> > @@ -14,6 +14,8 @@
> > */
> >
> > #i
On Wed, 2015-12-09 at 13:31 +0100, Egger, Christoph wrote:
>
> I recommend calloc(num, sizeof(int))
I decided not to since it needlessly (in this case) zeroes the memory.
Perhaps that is a premature optimisation though.
BTW, if you'd be able to test (even just a build test) on NetBSD that would
On Wed, Dec 09, 2015 at 12:41:49PM +, Ian Campbell wrote:
> On Wed, 2015-12-09 at 12:22 +, Wei Liu wrote:
> > > diff --git a/tools/libs/foreignmemory/core.c
> > > b/tools/libs/foreignmemory/core.c
> > > index 21dc7ee..91bea55 100644
> > > --- a/tools/libs/foreignmemory/core.c
> > > +++ b/to
On Wed, 2015-12-09 at 12:41 +, Wei Liu wrote:
> > + */
> > +
> > +/*
> > * Grant Table Interface (making use of grants from other domains)
> > */
> >
> > typedef struct xengntdev_handle xengnttab_handle;
> >
> > /*
> > - * Note:
> > - * After fork a child process must not use any open
On Wed, 2015-12-09 at 12:56 +, Wei Liu wrote:
> On Wed, Dec 09, 2015 at 12:41:49PM +, Ian Campbell wrote:
> > On Wed, 2015-12-09 at 12:22 +, Wei Liu wrote:
> > > > diff --git a/tools/libs/foreignmemory/core.c
> > > > b/tools/libs/foreignmemory/core.c
> > > > index 21dc7ee..91bea55 10064
>On 04.12.2015 at 2:55pm, wrote:
> >>> "Tian, Kevin" 12/04/15 2:49 AM >>>
> >> From: Jan Beulich [mailto:jbeul...@suse.com]
> >> Sent: Thursday, December 03, 2015 9:16 PM
> >> >>> On 03.12.15 at 09:09, wrote:
> >> > If impacted domain is Dom0 or hardware domain, just throw out a
> warning.
>
On Wed, Dec 09, 2015 at 01:00:34PM +, Ian Campbell wrote:
> On Wed, 2015-12-09 at 12:41 +, Wei Liu wrote:
> > > + */
> > > +
> > > +/*
> > > * Grant Table Interface (making use of grants from other domains)
> > > */
> > >
> > > typedef struct xengntdev_handle xengnttab_handle;
> > >
>>> On 09.12.15 at 14:30, wrote:
> Any more comment or suggestion?
>
> Now there are 2 comments from you and Kevin Tian.
> 1. from you, just checking g hardware_domain should be enough.
> 2. from Kevin Tian, do timeout check within dev_invalidate_iotlb for each
> ATS device, to identify bo
On Thu, 2015-12-03 at 11:23 +, Ian Campbell wrote:
> diff --git a/hw/display/xenfb.c b/hw/display/xenfb.c
> index 5e324ef..c96d974 100644
> --- a/hw/display/xenfb.c
> +++ b/hw/display/xenfb.c
> @@ -104,9 +104,8 @@ static int common_bind(struct common *c)
> if (xenstore_read_fe_int(&c->xend
On 09/12/15 13:00, Ian Campbell wrote:
> On Wed, 2015-12-09 at 12:41 +, Wei Liu wrote:
>>> + */
>>> +
>>> +/*
>>> * Grant Table Interface (making use of grants from other domains)
>>> */
>>>
>>> typedef struct xengntdev_handle xengnttab_handle;
>>>
>>> /*
>>> - * Note:
>>> - * After f
On 09/12/15 13:41, Ian Campbell wrote:
> On Thu, 2015-12-03 at 11:23 +, Ian Campbell wrote:
>> diff --git a/hw/display/xenfb.c b/hw/display/xenfb.c
>> index 5e324ef..c96d974 100644
>> --- a/hw/display/xenfb.c
>> +++ b/hw/display/xenfb.c
>> @@ -104,9 +104,8 @@ static int common_bind(struct commo
On Wed, 2015-12-09 at 13:50 +, Andrew Cooper wrote:
> On 09/12/15 13:00, Ian Campbell wrote:
> > On Wed, 2015-12-09 at 12:41 +, Wei Liu wrote:
> > > > + */
> > > > +
> > > > +/*
> > > > * Grant Table Interface (making use of grants from other domains)
> > > > */
> > > >
> > > > typed
On Wed, 2015-12-09 at 13:56 +, Andrew Cooper wrote:
> On 09/12/15 13:41, Ian Campbell wrote:
> > On Thu, 2015-12-03 at 11:23 +, Ian Campbell wrote:
> > > diff --git a/hw/display/xenfb.c b/hw/display/xenfb.c
> > > index 5e324ef..c96d974 100644
> > > --- a/hw/display/xenfb.c
> > > +++ b/hw/di
flight 65617 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/65617/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-xl 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 13
Which routine xen uses when translate nested xen address ? The first one or the
second?
1. nested vm -->EPT1 of L1 xen --> EPT0 of L0 xen --> machine address
2. nested vm --> EPT1 of L1 xen --> machine address
Does the nested vm directly translate its virtual address by vEPT or through
two EPT tr
Because the enum gic_version values do not correspond to the gic
version (in order to allow space for variants such as GICv2m, although
that is currently not present) logging the raw value is not terribly
useful. Provide gic_hw_desc which provides a string describing each
GIC version.
Will be used
For arm32 + gicv2 systems the following supports apparently successful
save/restore as well dead migrate a domain.
There are several caveats/blockers, hence RFC.
* GIC v2 support only, no GIC v3 at all
* ARM32 only. Doesn't even build for ARM64 (vfp state handling needs
adjustment)
* No liv
... with copyback functionality. A future domctl is going to want
this, rather than end up with different ops having different return
behaviour, simply switch everything over to a single exit path scheme.
Signed-off-by: Ian Campbell
---
xen/arch/arm/domctl.c | 76
This will allow generic vgic save code to get at this state without needing
to know about gic v2 vs v3 etc.
Signed-off-by: Ian Campbell
---
xen/arch/arm/gic-v2.c | 20
xen/arch/arm/gic-v3.c | 21 -
xen/arch/arm/gic.c| 5 +
xen/include
*** NOT TO BE APPLIED ***
Currently no support (even in this series) for live migration so
removing LIBXL_HAVE_NO_SUSPEND_RESUME on ARM for real seems premature.
This bodge however lets xl save/restore work and causes xl migrate to
do a dead instead of live migration for testing.
Do not apply th
This seems almost too easy.
It's possible there is some scope for sharing more with the x86/HVM
side.
Signed-off-by: Ian Campbell
Cc: andyhhp
---
config/arm32.mk | 1 +
config/arm64.mk | 1 +
tools/libxc/Makefile| 3 +
tools/libxc/xc_sr_common.h
XXX TBD No support for arm64 (or even 32-bit guest on arm64).
XXX In particular the handling of save/restore of VFP state doesn't
XXX even compile for arm32. I need to investigate the best way to
XXX reflect the differing possible VFB states in the save record.
Signed-off-by: Ian Campbell
---
xe
Signed-off-by: Ian Campbell
---
tools/libxc/xc_resume.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/tools/libxc/xc_resume.c b/tools/libxc/xc_resume.c
index 87d4324..fa16c3e 100644
--- a/tools/libxc/xc_resume.c
+++ b/tools/libxc/xc_resume.c
@@ -81,6 +81,24 @@ static int
These correspond to the content of struct xen_arch_domainconfig.
On restore various things are checked, mostly to ensure they match the
hardcoded things of the restoring Xen.
Signed-off-by: Ian Campbell
---
xen/arch/arm/save.c| 44 ++
xen/incl
Signed-off-by: Ian Campbell
---
xen/arch/arm/vtimer.c | 72 ++
xen/include/public/arch-arm/hvm/save.h | 15 ++-
2 files changed, 86 insertions(+), 1 deletion(-)
diff --git a/xen/arch/arm/vtimer.c b/xen/arch/arm/vtimer.c
index 629feb4..9dfc699
Currently only GICv2 support is implemented.
Given the differing architectural state between the GICv2 and v3 I
ended up with separate save records. I'm not sure if this is the best
plan. I have also split the state into GICD (per domain) and GICC (per
vcpu, although also including banked GICD sta
offline_page and compression are under a CONFIG_MIGRATE (out of
context) and along with xen-hptool these seem to rely on features
currently implemented only on x86.
I am shortly going to be enabling CONFIG_MIGRATE for ARM, but these
features are not yet available there.
I'm not sure if these are
Adding the rtc platform device in a Xen PV guests causes an IRQ
conflict because these guests do not have a legacy PIC.
In a single VCPU Xen PV guest we should have:
/proc/interrupts:
CPU0
0: 4934 xen-percpu-virq timer0
1: 0 xen-percpu-ipi spinlock0
2:
Replace various stub functions with real functionality, including
reestablishing the shared info page and the per-vcpu info pages on
restore.
Reestablishing the vcpu info page is a little subtle. The
VCPUOP_register_vcpu_info hypercall can only be called on either the
current VCPU or on an offline
I wasn't sure of the best way to achieve this, but a pair of per-arch
hooks seemed to be preferable to ifdeffery.
I also wasn't sure about the change to guest_type for save. The
restore half of the ctxt already has such a field but since the save
side treats it as an input to the process as oppose
This is just the minimally required basic infra and header, no actual
useful data is saved yet.
Signed-off-by: Ian Campbell
---
xen/arch/arm/Makefile | 1 +
xen/arch/arm/domctl.c | 74 ++
xen/arch/arm/save.c|
This is used by the save/restore code.
On ARM we only have RAM (0) or not-RAM (XTAB) types.
Signed-off-by: Ian Campbell
---
xen/arch/arm/domctl.c | 49 +
1 file changed, 49 insertions(+)
diff --git a/xen/arch/arm/domctl.c b/xen/arch/arm/domctl.c
>>> On 09.12.15 at 15:32, wrote:
> --- a/arch/x86/kernel/rtc.c
> +++ b/arch/x86/kernel/rtc.c
> @@ -200,6 +200,9 @@ static __init int add_rtc_cmos(void)
> }
> #endif
>
> + if (paravirt_enabled())
> + return -ENODEV;
What about Xen Dom0?
Jan
_
On Wed, Dec 09, 2015 at 09:32:49AM -0500, Boris Ostrovsky wrote:
> Adding the rtc platform device in a Xen PV guests causes an IRQ
> conflict because these guests do not have a legacy PIC.
>
> In a single VCPU Xen PV guest we should have:
>
> /proc/interrupts:
>CPU0
> 0: 4934
I noticed Linux 4.4 doing this universally now, and I think it's a good
idea to override such anti-security BIOS settings (we certainly have no
compatibility problem due to NX being enabled).
Secondary changes:
- no need to check supported extended CPUID level for leaves 8000
and 8001 (r
VT-d: make flush-all actually flush all
Passing gfn=0 and page_count=0 actually avoids the
iommu_flush_iotlb_dsi() and results in page-specific invalidation
instead.
Reported-by: "张智"
Signed-off-by: Jan Beulich
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
On Wed, 2015-12-02 at 16:53 +, Ian Campbell wrote:
> The next Xen technical call is scheduled for:
> Wed 9 Dec 17:00:00 GMT 2015
> `date -d @1449680400`
No agenda, so no call today.
Thanks,
Ian.
>
> Note that the time can be changed if the participants interested in
> the proposed
On 09/12/15 14:51, Jan Beulich wrote:
> I noticed Linux 4.4 doing this universally now, and I think it's a good
> idea to override such anti-security BIOS settings (we certainly have no
> compatibility problem due to NX being enabled).
>
> Secondary changes:
> - no need to check supported extended
On 2015-12-09 15:42, Jan Beulich wrote:
On 09.12.15 at 15:32, wrote:
--- a/arch/x86/kernel/rtc.c
+++ b/arch/x86/kernel/rtc.c
@@ -200,6 +200,9 @@ static __init int add_rtc_cmos(void)
}
#endif
+ if (paravirt_enabled())
+ return -ENODEV;
What about Xen Dom0?
Jan
On 09/12/15 14:32, Ian Campbell wrote:
> offline_page and compression are under a CONFIG_MIGRATE (out of
> context) and along with xen-hptool these seem to rely on features
> currently implemented only on x86.
>
> I am shortly going to be enabling CONFIG_MIGRATE for ARM, but these
> features are no
On 12/09/2015 10:00 AM, Sander Eikelenboom wrote:
On 2015-12-09 15:42, Jan Beulich wrote:
On 09.12.15 at 15:32, wrote:
--- a/arch/x86/kernel/rtc.c
+++ b/arch/x86/kernel/rtc.c
@@ -200,6 +200,9 @@ static __init int add_rtc_cmos(void)
}
#endif
+if (paravirt_enabled())
+return -
Sander Eikelenboom writes:
> On 2015-12-09 15:42, Jan Beulich wrote:
> On 09.12.15 at 15:32, wrote:
>>> --- a/arch/x86/kernel/rtc.c
>>> +++ b/arch/x86/kernel/rtc.c
>>> @@ -200,6 +200,9 @@ static __init int add_rtc_cmos(void)
>>> }
>>> #endif
>>>
>>> + if (paravirt_enabled())
>>> +
>>> On 09.12.15 at 16:15, wrote:
> On 12/09/2015 10:00 AM, Sander Eikelenboom wrote:
>> On 2015-12-09 15:42, Jan Beulich wrote:
>> On 09.12.15 at 15:32, wrote:
--- a/arch/x86/kernel/rtc.c
+++ b/arch/x86/kernel/rtc.c
@@ -200,6 +200,9 @@ static __init int add_rtc_cmos(void)
On 09/12/15 14:32, Ian Campbell wrote:
> I wasn't sure of the best way to achieve this, but a pair of per-arch
> hooks seemed to be preferable to ifdeffery.
I agree. The patch looks good.
>
> I also wasn't sure about the change to guest_type for save. The
> restore half of the ctxt already has s
On Wed, 2015-12-09 at 15:26 +, Andrew Cooper wrote:
> On 09/12/15 14:32, Ian Campbell wrote:
> > I wasn't sure of the best way to achieve this, but a pair of per-arch
> > hooks seemed to be preferable to ifdeffery.
>
> I agree. The patch looks good.
>
> >
> > I also wasn't sure about the ch
Ian Campbell writes ("[PATCH XEN v6 16/32] tools: Refactor foreign memory
mapping into libxenforeignmemory"):
> libxenforeignmemory will provide a stable API and ABI for mapping
> foreign domain memory (subject to appropriate privileges).
Acked-by: Ian Jackson
__
Ian Campbell writes ("[PATCH XEN v6 20/32] tools/libs/foreignmemory: Support
err == NULL to map."):
> The existing xc_map_foreign_bulk-like interface encourages callers to
> miss error checking for partial failure (by forgetting to scan the err
> array).
Acked-by: Ian Jackson
I have not reviewe
Ian Campbell writes ("[PATCH XEN v6 17/32] tools/libs/foreignmemory: provide
xenforeignmemory_unmap."):
> And require it be used instead of direct munmap.
Acked-by: Ian Jackson
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xe
On Wed, 9 Dec 2015, Jianzhong,Chang wrote:
> Add pci = [ '$VF_BDF1', '$VF_BDF2', '$VF_BDF3'] in
> hvm guest configuration file. After the guest boot up,
> detach the VFs in sequence by
> "xl pci-detach $DOMID $VF_BDF1"
> "xl pci-detach $DOMID $VF_BDF2"
> "xl pci-detach $DOMID $VF_BDF3"
> and rea
Ian Campbell writes ("[PATCH XEN v6 22/32] tools/libs/foreignmemory: optimise
map(num==1, err==NULL) case"):
> This looks to be a reasonably common case (many of the previous
> callers to xc_map_foreign_pages use it) and it is easy enough to avoid
> a malloc for it.
...
> I'm not 100% sure this is
Ian Campbell writes ("[PATCH XEN v6 21/32] tools/libs/foreignmemory: pull array
length argument to map forward"):
> By having the "num" argument before the page and error arrays we can
> potentially use a variable-length-array argument ("int pages[num]") in
> the function prototype.
>
> However V
flight 65593 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/65593/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail
REGR. vs. 65543
version targeted
On 09/12/15 14:32, Ian Campbell wrote:
> This seems almost too easy.
I am glad that a healthy quantity of time has passed since the 4.6 dev
window. Easy is not how I would have described this back then!
> diff --git a/tools/libxc/xc_sr_common_arm.h b/tools/libxc/xc_sr_common_arm.h
> new file mod
On 09/12/15 14:31, Ian Campbell wrote:
> For arm32 + gicv2 systems the following supports apparently successful
> save/restore as well dead migrate a domain.
>
> There are several caveats/blockers, hence RFC.
>
> * GIC v2 support only, no GIC v3 at all
> * ARM32 only. Doesn't even build for ARM64
On Tue, 8 Dec 2015, Jan Beulich wrote:
> 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 m
On 09/12/15 14:52, Jan Beulich wrote:
> VT-d: make flush-all actually flush all
>
> Passing gfn=0 and page_count=0 actually avoids the
> iommu_flush_iotlb_dsi() and results in page-specific invalidation
> instead.
>
> Reported-by: "张智"
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
__
Ian Campbell writes ("[PATCH XEN v6 25/32] tools/libs/gnttab: Extensive updates
to API documentation."):
> In particular around error handling, behaviour on fork and the unmap
> notification mechanism.
>
> Behaviour of xengnttab_map_*grant_refs and xengntshr_share_pages on
> partial failure has b
Ian Campbell writes ("Re: [Xen-devel] [PATCH XEN v6 25/32] tools/libs/gnttab:
Extensive updates to API documentation."):
> On Wed, 2015-12-09 at 13:50 +, Andrew Cooper wrote:
> > An _open() call must be matched with a _close() call.
>
> This is not safe after an exec though, since the fd will
On Wed, 2015-12-09 at 15:51 +, Andrew Cooper wrote:
> On 09/12/15 14:31, Ian Campbell wrote:
> > For arm32 + gicv2 systems the following supports apparently successful
> > save/restore as well dead migrate a domain.
> >
> > There are several caveats/blockers, hence RFC.
> >
> > * GIC v2 supp
On Wed, Dec 09, 2015 at 01:15:31PM +, Ian Campbell wrote:
> On Wed, 2015-12-09 at 12:56 +, Wei Liu wrote:
> > On Wed, Dec 09, 2015 at 12:41:49PM +, Ian Campbell wrote:
> > > On Wed, 2015-12-09 at 12:22 +, Wei Liu wrote:
> > > > > diff --git a/tools/libs/foreignmemory/core.c
> > > >
Ian Campbell writes ("[PATCH XEN v6 27/32] tools/libs/call: Describe return
values and error semantics for xencall*"):
> This behaviour has been confirmed by inspection on:
Acked-by: Ian Jackson
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http:
Ian Campbell writes ("[PATCH XEN v6 30/32] tools/libs/call: linux: avoid
forking between mmap and madvise"):
> Use pthread_atfork to prevent the application from forking before the
> madvisoe(), which would result in CoW mappings getting passed to
> hypercalls.
OMG.
Is it not possible (not effec
Ian Campbell writes ("[PATCH XEN v6 29/32] tools/libs/call: Use O_CLOEXEC when
opening /dev/xen/privcmd on Linux"):
> We stick with using FD_CLOEXEC on the legacy /proc/xen/privcmd
> fallback device since it was present in older kernel where O_CLOEXEC
> may not be assured.
This is a lot of effort
Ian Campbell writes ("Re: [PATCH XEN v6 25/32] tools/libs/gnttab: Extensive
updates to API documentation."):
> On Wed, 2015-12-09 at 16:09 +, Ian Jackson wrote:
> > Is this actually true ? Normally close() on an fd does not munmap
> > anything mmapped from the fd.
>
> Uh yes, I was talking r
flight 65622 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/65622/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 5 libvirt-build fail REGR. vs. 65617
Tests which di
On Wed, 2015-12-09 at 16:09 +, Ian Jackson wrote:
> > + * The child must open a new handle if they want to interact with
> > + * gnttab.
> > *
> > - * Return an fd onto the grant table driver. Logs errors.
> > + * A child may safely call xengnttab_close() on a xengnttab_handle
> > + * inheri
>>> On 09.12.15 at 16:55, wrote:
> On Tue, 8 Dec 2015, Jan Beulich wrote:
>> 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
>> hos
1 - 100 of 127 matches
Mail list logo
