In addition, how can I obtain the physical address range of the nested Xen? By
default, I can obtain its virtual address from xen-syms file, but I don't think
it is equal to its physical address, as there are two Xens (L0 and L1)
co-exists.
> From: quizy
>>> On 10.12.15 at 04:06, wrote:
>
>> -Original Message-
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: Wednesday, December 9, 2015 10:53 PM
>> To: xen-devel
>> Cc: Wu, Feng ; Tian, Kevin
>> Subject: [PATCH] VT-d: make flush-all actually flush all
>>
>> VT-d: make flush-all
flight 65648 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/65648/
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
flight 65607 xen-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/65607/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i3863 host-install(3) broken REGR. vs. 64765
build-armhf
flight 65602 linux-mingo-tip-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/65602/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-rumpuserxen-amd64 3 host-install(3) broken REGR. vs. 60684
test-amd64
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Wednesday, December 9, 2015 10:53 PM
> To: xen-devel
> Cc: Wu, Feng ; Tian, Kevin
> Subject: [PATCH] VT-d: make flush-all actually flush all
>
> VT-d: make flush-all actually flush all
>
> Passing gfn=0 and pa
flight 65603 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/65603/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt-pair 4 host-install/dst_host(4) broken REGR. vs. 63340
test-amd64-i386-libvirt-q
flight 65646 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/65646/
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 ar
> On 09.12.2015 at 9:38pm, wrote:
> >>> 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_
This patch fixs two memleaks in konrad/xen.git/for-jens-4.5.
backtrace:
[] kmemleak_alloc+0x28/0x50
[] kmem_cache_alloc+0xbb/0x1d0
[] xen_blkbk_probe+0x58/0x230
[] xenbus_dev_probe+0x76/0x130
[] driver_probe_device+0x166/0x2c0
[] __device_attach_driver+0xac/0xb0
[] bus
flight 65641 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/65641/
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 12/08/15 14:21, Boris Ostrovsky wrote:
> On 12/07/2015 08:52 PM, Haozhong Zhang wrote:
> >On 12/07/15 13:14, Boris Ostrovsky wrote:
> >>On 12/06/2015 03:58 PM, Haozhong Zhang wrote:
> >>>This patch makes the pvclock return the scaled host TSC and
> >>>corresponding scaling parameters to HVM doma
On 12/08/15 13:26, Boris Ostrovsky wrote:
> On 12/07/2015 08:08 PM, Haozhong Zhang wrote:
> >On 12/07/15 12:53, Boris Ostrovsky wrote:
> >>On 12/06/2015 03:58 PM, Haozhong Zhang wrote:
> >>>When the TSC mode of a HVM container is TSC_MODE_DEFAULT or
> >>>TSC_MODE_PVRDTSCP and no TSC emulation is us
flight 65601 xen-4.5-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/65601/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-freebsd10-i386 3 host-install(3) broken REGR. vs. 649
flight 65637 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/65637/
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
flight 65598 xen-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/65598/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemut-rhel6hvm-amd 3 host-install(3) broken REGR. vs. 653
On 12/9/15 2:34 PM, Doug Goldstein wrote:
> On 12/9/15 2:40 AM, Jan Beulich wrote:
> 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
On 12/9/15 2:40 AM, Jan Beulich wrote:
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
flight 65630 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/65630/
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 12/09/2015 03:43 AM, 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.
I made the same changes yesterday to get the te
flight 65575 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/65575/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-rumpuserxen3 host-install(3) broken REGR. vs. 65114
flight 65627 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/65627/
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 12/09/2015 10:27 AM, Jan Beulich wrote:
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_rt
Harmandeep,
Your blog should now be visible on Planet Hypervisor, reachable from the top
navigation bar of XenProject.org.
If you see any problem with the feed, please let me know.
Russ Pavlicek
Xen Project Evangelist
From: Dario Faggioli [dario.faggi..
On Wed, 2015-12-09 at 16:28 +, Ian Jackson wrote:
> 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
>
On Wed, Nov 25, 2015 at 9:46 AM, Chunyan Liu wrote:
> 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 cou
On Wed, Nov 25, 2015 at 9:46 AM, Chunyan Liu wrote:
> 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
>>> 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
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
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
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
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 ("[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 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:
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
> > > >
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
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
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
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
__
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: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 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
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
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
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
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 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
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 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
__
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
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 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)
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 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 -
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 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: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 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
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
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
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
>>> 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
_
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
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|
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:
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
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
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
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
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
... 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
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
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
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
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
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
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 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 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 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 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 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 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, 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 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, 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 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, 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 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 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 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, 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 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
1 - 100 of 127 matches
Mail list logo
