>>> On 02.02.16 at 16:09, wrote:
> On 02/02/16 14:10, Jan Beulich wrote:
> On 02.02.16 at 14:30, wrote:
>>> On 02/02/16 12:44, Jan Beulich wrote:
All,
while looking into some of the DEBUG_WX issues I came across
aforementioned function and started wondering how pv-ops gets
flight 80179 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/80179/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-pvops 5 kernel-build fail REGR. vs. 80122
test-armhf-armhf-xl
From: George Dunlap
At the moment, the pfec argument to gva_to_gfn has two functions:
* To inform guest_walk what kind of access is happenind
* As a value to pass back into the guest in the event of a fault.
Unfortunately this is not quite treated consistently: the hvm_fetch_*
function will "p
This patch adds pkeys support for cpuid handing.
Pkeys hardware support is CPUID.7.0.ECX[3]:PKU. software support is
CPUID.7.0.ECX[4]:OSPKE and it reflects the support setting of CR4.PKE.
X86_FEATURE_OSXSAVE depends on guest X86_FEATURE_XSAVE, but cpu_has_xsave
function reflects hypervisor X86_FE
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 access-disable bit for
protection key i (ADi); PKRU[
The XSAVE feature set can operate on PKRU state only if the feature set is
enabled (CR4.OSXSAVE = 1) and has been configured to manage PKRU state
(XCR0[9] = 1). And XCR0.PKRU is disabled on PV mode without PKU feature
enabled.
Signed-off-by: Huaitong Han
Reviewed-by: Andrew Cooper
Reviewed-by: K
This patch disables pkeys for guest in non-paging mode, However XEN always uses
paging mode to emulate guest non-paging mode, To emulate this behavior, pkeys
needs to be manually disabled when guest switches to non-paging mode.
Signed-off-by: Huaitong Han
Reviewed-by: Andrew Cooper
Acked-by: Kev
Changes in v10:
*Move PFEC_page_present check.
Changes in v9:
*Rename _write_cr4 to raw_write_cr4.
*Clear X86_FEATURE_OSPKE and X86_FEATURE_OSXSAVE when the condition is not
satisfied.
Changes in v8:
*Add the comment describing for paging_gva_to_gfn.
*Abstract out _write_cr4.
Changes in v7:
*Ad
On Tue, Feb 02, 2016 at 02:42:38AM -0700, Jan Beulich wrote:
> >> > With this another question then is whether, when both XSAVEC
> >> > and XSAVEOPT are available, it is indeed always better to use
> >> > XSAVEC (as the code is doing after your enabling).
> > Yes.
> > But current no machine only su
XEN HVM, after it hung, no serial log printed.
it hang in __pirq_guest_unbind. its call stack as follows:
(XEN)[] __pirq_guest_unbind+0x36/0x350
(XEN)[] __pirq_guest_unbind+0x36/0x350
(XEN)[] do_invalid_op+0x30b/0x3f0
(XEN)[] flush_area_mask+0x7c/0x130
(XEN)[] handle_exception_s
flight 80233 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/80233/
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
test-amd64-i386-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Wednesday, February 03, 2016 5:35 PM
> > (XEN) nvmx_handle_vmwrite: 0
> > (XEN) nvmx_handle_vmwrite: 2008
> > (XEN) nvmx_handle_vmwrite: 2008
> > (XEN) nvmx_handle_vmwrite: 0
> > (XEN) nvmx_handle_vmwrite: 2008
> > (XEN) nvmx_handle_vmwrite: 0
> From: Huaitong Han
> Sent: Wednesday, February 03, 2016 10:12 PM
>
> The XSAVE feature set can operate on PKRU state only if the feature set is
> enabled (CR4.OSXSAVE = 1) and has been configured to manage PKRU state
> (XCR0[9] = 1). And XCR0.PKRU is disabled on PV mode without PKU feature
> ena
> From: Huaitong Han
> Sent: Wednesday, February 03, 2016 10:12 PM
>
> 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
> From: Han, Huaitong
> Sent: Thursday, February 04, 2016 1:25 PM
>
> On Thu, 2016-02-04 at 13:20 +0800, Huaitong Han wrote:
> > On Thu, 2016-02-04 at 04:56 +, Tian, Kevin wrote:
> > > > From: Huaitong Han
> > > > Sent: Wednesday, February 03, 2016 10:12 PM
> > > >
> > > > The PKRU register (p
On 02/04/2016 03:40 AM, Wei Liu wrote:
> On Fri, Jan 29, 2016 at 01:27:21PM +0800, Wen Congyang wrote:
>> Before this patch:
>> 1. suspend
>> a. PVHVM and PV: we use the same way to suspend the guest (send the suspend
>>request to the guest). If the guest doesn't support evtchn, the xenstore
>>
On Wed, Feb 03, 2016 at 05:39:53AM -0700, Jan Beulich wrote:
> From: Shuai Ruan
>
> This patch use alternavtive asm on the xsave side.
> As xsaves use modified optimization like xsaveopt, xsaves
> may not writing the FPU portion of the save image too.
> So xsaves also need some extra tweaks.
>
>
On 02/04/2016 03:40 AM, Wei Liu wrote:
> On Fri, Jan 29, 2016 at 01:27:28PM +0800, Wen Congyang wrote:
>> In COLO mode, both VMs are running, and are considered in sync if the
>> visible network traffic is identical. After some time, they fall out of
>> sync.
>>
>> At this point, the two VMs have
On Thu, 2016-02-04 at 13:20 +0800, Huaitong Han wrote:
> On Thu, 2016-02-04 at 04:56 +, Tian, Kevin wrote:
> > > From: Huaitong Han
> > > Sent: Wednesday, February 03, 2016 10:12 PM
> > >
> > > The PKRU register (protection key rights for user pages) is a 32
> > > -bit register
> > > with the
On 02/04/2016 03:40 AM, Wei Liu wrote:
> On Fri, Jan 29, 2016 at 01:27:24PM +0800, Wen Congyang wrote:
>> In normal migration, the qemu state is passed to qemu as a parameter.
>> With COLO, secondary vm is running. So we will do the following steps
>> at every checkpoint:
>> 1. suspend both primary
On Thu, 2016-02-04 at 04:56 +, Tian, Kevin wrote:
> > From: Huaitong Han
> > Sent: Wednesday, February 03, 2016 10:12 PM
> >
> > The PKRU register (protection key rights for user pages) is a 32
> > -bit register
> > with the following format: for each i (0 ≤ i ≤ 15), PKRU[2i] is the
> > access
On 02/04/2016 03:40 AM, Wei Liu wrote:
> On Fri, Jan 29, 2016 at 01:27:23PM +0800, Wen Congyang wrote:
>> Pass checkpointed_stream from libxl to libxc.
>> It won't affact legacy migration because legacy migration
>> won't use this param.
>>
>> Signed-off-by: Yang Hongyang
>> Signed-off-by: Wen Con
On 02/04/2016 03:39 AM, Wei Liu wrote:
> On Fri, Jan 29, 2016 at 01:27:17PM +0800, Wen Congyang wrote:
>> init stream {read/write} state checkpoint_callback in Remus setup callback.
>> There's no functional change, it's just refactoring so that we can move
>> all remus code into one file.
>>
>> Sig
> From: Huaitong Han
> Sent: Wednesday, February 03, 2016 10:12 PM
>
> This patch disables pkeys for guest in non-paging mode, However XEN always
> uses
> paging mode to emulate guest non-paging mode, To emulate this behavior, pkeys
> needs to be manually disabled when guest switches to non-pagin
> From: Huaitong Han
> Sent: Wednesday, February 03, 2016 10:12 PM
>
> The PKRU register (protection key rights for user pages) is a 32-bit register
> with the following format: for each i (0 ≤ i ≤ 15), PKRU[2i] is the
> access-disable bit for protection key i (ADi); PKRU[2i+1] is the write-disabl
On Wed, Feb 3, 2016 at 7:39 AM, Dario Faggioli
wrote:
>
> On Tue, 2016-02-02 at 13:09 -0500, Tianyang Chen wrote:
> > On 2/2/2016 10:08 AM, Dario Faggioli wrote:
> > > On Sun, 2016-01-31 at 23:32 -0500, Tianyang Chen wrote:
> > > >
> > > > +struct rt_private *prv = rt_priv(ops);
> > > > +s
flight 80172 linux-4.1 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/80172/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-rumpuserxen 6 xen-build fail REGR. vs. 66399
build-i386-rumpuserxen
On 02/03/16 14:20, Andrew Cooper wrote:
> > (ACPI part is described in Section 3.3 later)
> >
> > Above (1)(2) have already been done in current QEMU. Only (3) is
> > needed to implement in QEMU. No change is needed in Xen for address
> > mapping in this design.
> >
> >>
On 02/03/16 15:22, Stefano Stabellini wrote:
> On Wed, 3 Feb 2016, George Dunlap wrote:
> > On 03/02/16 12:02, Stefano Stabellini wrote:
> > > On Wed, 3 Feb 2016, Haozhong Zhang wrote:
> > >> Or, we can make a file system on /dev/pmem0, create files on it, set
> > >> the owner of those files to xen
On 02/03/2016 02:56 AM, Ian Campbell wrote:
> On Tue, 2016-02-02 at 15:06 -0700, Jim Fehlig wrote:
>>> And extending
>>> the structure seems to be the right thing to do.
>> So what do you think of the approach in the RFC patch? It adds discrete
>> knobs in
>> the disk config and extends the disk s
On 02/03/16 10:47, Konrad Rzeszutek Wilk wrote:
> > > > > Open: It seems no system call/ioctl is provided by Linux kernel to
> > > > >get the physical address from a virtual address.
> > > > >/proc//pagemap provides information of mapping from
> > > > >VA to PA. Is it an ac
On 2/3/2016 7:39 AM, Dario Faggioli wrote:
On Tue, 2016-02-02 at 13:09 -0500, Tianyang Chen wrote:
On 2/2/2016 10:08 AM, Dario Faggioli wrote:
On Sun, 2016-01-31 at 23:32 -0500, Tianyang Chen wrote:
+struct rt_private *prv = rt_priv(ops);
+struct list_head *replq = rt_replq(ops);
+
>>> On 2/3/2016 at 10:33 PM, in message <56b20fcc.3010...@citrix.com>, George
Dunlap wrote:
> On 02/02/16 18:11, Ian Jackson wrote:
> > George Dunlap writes ("Re: [Xen-devel] [PATCH V13 3/5] libxl: add pvusb
> API"):
> >> There are effectively four states a device can be in, from the
> >>
>>> On 2/3/2016 at 10:38 PM, in message <56b210fa.7040...@citrix.com>, George
Dunlap wrote:
> On 03/02/16 07:34, Chun Yan Liu wrote:
> >
> >
> On 2/3/2016 at 02:11 AM, in message
> > <22192.61775.427189.268...@mariner.uk.xensource.com>, Ian Jackson
> > wrote:
> >> George Dunlap w
On 03/02/2016 23:59, Luis R. Rodriguez wrote:
> On Wed, Feb 03, 2016 at 08:52:50PM +, Andrew Cooper wrote:
>> On 03/02/16 18:55, Luis R. Rodriguez wrote:
>>> We add new hypervisor type to close the semantic gap for hypervisor types,
>>> and
>>> much like subarch enable also a subarch_data to l
On Wed, Feb 3, 2016 at 3:59 PM, Luis R. Rodriguez wrote:
>> If you still desperately want to avoid multiple entry points, then just
>> insist on using grub for the VM. I expect that that is how most people
>> will end up using HVMLite VMs anyway.
>
> Are you saying Grub can do some of this heavy
On Wed, Feb 03, 2016 at 08:52:50PM +, Andrew Cooper wrote:
> On 03/02/16 18:55, Luis R. Rodriguez wrote:
> > We add new hypervisor type to close the semantic gap for hypervisor types,
> > and
> > much like subarch enable also a subarch_data to let you pass and use your
> > hvmlite_start_info.
Hi all,
I have been testing the Xen 4.6.0 packages - however I have found the
following issue with attempting to perform the following commands:
[root@mynas-s5000xvn ~]# xl cd-eject test2 hdc
libxl: error: libxl_device.c:301:libxl__device_disk_set_backend: no
suitable bac
On Wed, Feb 03, 2016 at 03:11:56PM -0500, Boris Ostrovsky wrote:
> On 02/03/2016 01:55 PM, Luis R. Rodriguez wrote:
> >I saw no considerations for the recommendations I had made last on your v1:
> >
> >https://lkml.kernel.org/r/CAB=NE6XPA0YzbnM8=rspkkai6d3gkxxo00gr0vzuyoyzny6...@mail.gmail.com
> >
flight 80131 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/80131/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-vhd 10 guest-start fail REGR. vs. 79947
Regressions which a
Hi all,
I have been testing the Xen 4.6.0 packages - however there is no way that I
have found to enable websocket support in any of the xen / qemu
configuration files.
The only way that I have been able to do this is with the following patch -
which works perfectly for my use case on a CentOS 6
Hi all,
I have been testing the Xen 4.6.0 packages - however I have found the
following issue with attempting to reboot a Windows VM:
--
[root@mynas-s5000xvn services]# /usr/sbin/xl reboot Windows_2008_R2
Rebooting domain 5
PV control
flight 80122 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/80122/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-rumpuserxen 6 xen-build fail REGR. vs. 59254
build-i386-rumpuserxe
On 03/02/16 18:55, Luis R. Rodriguez wrote:
> We add new hypervisor type to close the semantic gap for hypervisor types, and
> much like subarch enable also a subarch_data to let you pass and use your
> hvmlite_start_info. This would not only help with the semantics but also help
> avoid yet-anothe
> > And I wonder if the XEN_DOMCTL_irq_permission aka, xc_domain_irq_permission
> > had been called. I remember that at some point we missed it for Xend..
> >
False alarm.
It was all in Linux. Attached are four patches (the first two
are for your issue you discovered).
I was wondering if there is
On 02/03/2016 01:55 PM, Luis R. Rodriguez wrote:
I saw no considerations for the recommendations I had made last on your v1:
https://lkml.kernel.org/r/CAB=NE6XPA0YzbnM8=rspkkai6d3gkxxo00gr0vzuyoyzny6...@mail.gmail.com
Of importance:
1) Using pv_info.paravirt_enabled = 1 is wrong unless you mea
On Fri, Jan 29, 2016 at 01:27:34PM +0800, Wen Congyang wrote:
> we call (init|cleanup)_subkind_nic and (init|cleanup)_subkind_drbd_disk
> directly in checkpoint device. Move them to libxl_remus.c, Call them before
> calling libxl__checkpoint_devices_setup() or after calling
> libxl__checkpoint_devi
On Fri, Jan 29, 2016 at 01:27:33PM +0800, Wen Congyang wrote:
> Add a new structure remus state, and move concrete layer's private
> member to remus state.
> it is pure refactoring and no functional changes.
> Init interval in libxl__remus_setup(). It is safe to move this initialisation,
> because
On Fri, Jan 29, 2016 at 01:27:27PM +0800, Wen Congyang wrote:
> In COLO mode, secondary needs to send the following data to primary:
> 1. In libxl
>Secondary sends the following CHECKPOINT_CONTEXT to primary:
>CHECKPOINT_SVM_SUSPENDED, CHECKPOINT_SVM_READY and CHECKPOINT_SVM_RESUMED
> 2. In
On Fri, Jan 29, 2016 at 01:27:24PM +0800, Wen Congyang wrote:
> In normal migration, the qemu state is passed to qemu as a parameter.
> With COLO, secondary vm is running. So we will do the following steps
> at every checkpoint:
> 1. suspend both primary vm and secondary vm
> 2. sync the state
> 3.
On Fri, Jan 29, 2016 at 01:27:17PM +0800, Wen Congyang wrote:
> init stream {read/write} state checkpoint_callback in Remus setup callback.
> There's no functional change, it's just refactoring so that we can move
> all remus code into one file.
>
> Signed-off-by: Yang Hongyang
> Signed-off-by: W
On Fri, Jan 29, 2016 at 01:27:31PM +0800, Wen Congyang wrote:
> This is just tidying up after the "tools/libxl: rename remus device
> to checkpoint device" patch automatic renaming.
>
> Signed-off-by: Yang Hongyang
> Signed-off-by: Wen Congyang
> Acked-by: Ian Campbell
> Reviewed-by: Konrad Rze
On Fri, Jan 29, 2016 at 01:27:28PM +0800, Wen Congyang wrote:
> In COLO mode, both VMs are running, and are considered in sync if the
> visible network traffic is identical. After some time, they fall out of
> sync.
>
> At this point, the two VMs have definitely diverged. Lets call the
> primary
On Fri, Jan 29, 2016 at 01:27:32PM +0800, Wen Congyang wrote:
> Checkpoint device is an abstract layer to do checkpoint.
> COLO can also use it to do checkpoint. But there are
> still some codes in checkpoint device which touch remus.
>
> This patch and:
> tools/libxl: move remus state into a sep
On Fri, Jan 29, 2016 at 01:27:21PM +0800, Wen Congyang wrote:
> Before this patch:
> 1. suspend
> a. PVHVM and PV: we use the same way to suspend the guest (send the suspend
>request to the guest). If the guest doesn't support evtchn, the xenstore
>variant will be used, suspending the guest
On Fri, Jan 29, 2016 at 01:27:20PM +0800, Wen Congyang wrote:
> Currently struct libxl__domain_suspend_state contains 2 type of states,
> one is save state, another is suspend state. This patch separates those
> two out.
> The motivation of this is that COLO will need to do suspend/resume
> continu
On Fri, Jan 29, 2016 at 01:27:26PM +0800, Wen Congyang wrote:
> We need to enable logdirty on secondary, so we export logdirty_init
> for internal use. Rename it to libxl__logdirty_init.
>
> Signed-off-by: Yang Hongyang
> Signed-off-by: Wen Congyang
> Acked-by: Ian Campbell
> Reviewed-by: Konra
On Fri, Jan 29, 2016 at 01:27:29PM +0800, Wen Congyang wrote:
> This patch is auto generated by the following commands:
> 1. git mv tools/libxl/libxl_remus_device.c
> tools/libxl/libxl_checkpoint_device.c
> 2. perl -pi -e 's/libxl_remus_device/libxl_checkpoint_device/g'
> tools/libxl/Makefile
>
On Fri, Jan 29, 2016 at 01:27:25PM +0800, Wen Congyang wrote:
> Secondary vm is running in COLO mode, we need to send secondary
> vm's dirty page information to primary host at checkpoint, so we
> have to enable qemu logdirty on secondary.
>
> libxl__domain_suspend_common_switch_qemu_logdirty() is
On Fri, Jan 29, 2016 at 01:27:22PM +0800, Wen Congyang wrote:
> Introduce enum type libxl_checkpointed_stream in IDL.
> rename the last argument of migrate_receive from "remus" to
> "checkpointed" since the semantics of this parameter has
> changed.
>
> NOTE:
> libxl_domain_restore_params and dom
On Fri, Jan 29, 2016 at 01:27:18PM +0800, Wen Congyang wrote:
> After previous refactoring, we are now able to move all remus code
> into a separate file libxl_remus.c.
>
> Export following functions for internal use:
> - Remus callbacks
> * libxl__remus_domain_suspend_callback
> * libxl__remu
On Fri, Jan 29, 2016 at 01:27:19PM +0800, Wen Congyang wrote:
> This is purely code motion.
>
> Signed-off-by: Yang Hongyang
> Signed-off-by: Wen Congyang
> CC: Ian Jackson
> CC: Wei Liu
> Acked-by: Ian Campbell
Acked-by: Wei Liu
___
Xen-devel ma
On Fri, Jan 29, 2016 at 01:27:23PM +0800, Wen Congyang wrote:
> Pass checkpointed_stream from libxl to libxc.
> It won't affact legacy migration because legacy migration
> won't use this param.
>
> Signed-off-by: Yang Hongyang
> Signed-off-by: Wen Congyang
> CC: Ian Campbell
> CC: Ian Jackson
On 02/02/2016 11:41 PM, Jim Fehlig wrote:
> Joao Martins wrote:
>> 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 conne
On 03/02/16 18:39, Andrew Cooper wrote:
> On 03/02/16 18:21, George Dunlap wrote:
>> 2. It's not technically difficult to extend the number of servers
>> supported to something sensible, like 4 (using 4 different write_dm
>> p2m types)
>
> While technically true, spare bits in the pagetable entrie
On Mon, Feb 01, 2016 at 10:38:50AM -0500, Boris Ostrovsky wrote:
> diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
> index c49f79e..9a239d5 100644
> --- a/drivers/xen/grant-table.c
> +++ b/drivers/xen/grant-table.c
> @@ -1147,13 +1147,13 @@ EXPORT_SYMBOL_GPL(gnttab_init);
>
>
I saw no considerations for the recommendations I had made last on your v1:
https://lkml.kernel.org/r/CAB=NE6XPA0YzbnM8=rspkkai6d3gkxxo00gr0vzuyoyzny6...@mail.gmail.com
Of importance:
1) Using pv_info.paravirt_enabled = 1 is wrong unless you mean to say this
is for legacy x86:
Your patch #3
On 03/02/16 18:21, George Dunlap wrote:
> 2. It's not technically difficult to extend the number of servers
> supported to something sensible, like 4 (using 4 different write_dm
> p2m types)
While technically true, spare bits in the pagetable entries are at a
premium, and steadily decreasing as In
On Wed, Feb 3, 2016 at 6:21 PM, George Dunlap
wrote:
> I really don't understand where you're coming from on this. The
> approach you've chosen looks to me to be slower, more difficult to
> implement, and more complicated; and it's caused a lot more resistance
> trying to get this series accepted
On Wed, Feb 3, 2016 at 5:41 PM, George Dunlap
wrote:
> I think at some point I suggested an alternate design based on marking
> such gpfns with a special p2m type; I can't remember if that
> suggestion was actually addressed or not.
FWIW, the thread where I suggested using p2m types was in respon
On Tue, Feb 02, 2016 at 12:45:00PM +0100, Dario Faggioli wrote:
> On Thu, 2016-01-28 at 22:27 -0500, Konrad Rzeszutek Wilk wrote:
> > On Thu, Jan 28, 2016 at 03:10:57PM +, Dario Faggioli wrote:
> > >
> > > So, may I ask what piece of (Linux) code are we actually talking
> > > about?
> > > Beca
On Tue, Feb 02, 2016 at 12:04:36PM +0800, Norton.Zhu wrote:
> Hi,all:
>
> I met a problem when passthrough 82599 to domU(for some reasons, I use pci
> passthrough not SRIOV).
Is this PV or HVM?
> It works well after passthrough, but the host hung after destroy domU.
> Btw, no log prints even fr
On Feb 3, 2016 5:52 AM, "Michael S. Tsirkin" wrote:
>
> On Tue, Feb 02, 2016 at 09:46:36PM -0800, Andy Lutomirski wrote:
> > virtio_ring currently sends the device (usually a hypervisor)
> > physical addresses of its I/O buffers. This is okay when DMA
> > addresses and physical addresses are the
On Tue, 2 Feb 2016, Andy Lutomirski wrote:
> This switches virtio to use the DMA API on Xen and if requested by
> module option.
>
> This fixes virtio on Xen, and it should break anything because it's
> off by default on everything except Xen PV on x86.
>
> To the Xen people: is this okay? If it
On Wed, Feb 3, 2016 at 3:10 PM, Paul Durrant wrote:
>> * Is it possible for libxl to somehow tell from the rest of the
>>configuration that this larger limit should be applied ?
>>
>
> If a XenGT-enabled VM is provisioned through libxl then some larger limit is
> likely to be required. One o
On Wed, Feb 3, 2016 at 2:43 PM, Ian Jackson wrote:
> Paul Durrant writes ("RE: [Xen-devel] [PATCH v3 3/3] tools: introduce
> parameter max_wp_ram_ranges."):
>> > From: Jan Beulich [mailto:jbeul...@suse.com]
> ...
>> > I wouldn't be happy with that (and I've said so before), since it
>> > would al
On Wed, Feb 03, 2016 at 02:17:26PM +0100, Dario Faggioli wrote:
> On Wed, 2016-02-03 at 13:10 +, Andrew Cooper wrote:
> > On 03/02/16 12:55, Dario Faggioli wrote:
> > >
> > > tbox login: (d1) mapping kernel into physical memory
> > > (d1) about to get started...
> > > (XEN) traps.c:2684:d1v0 D
On 03/02/16 17:12, Olaf Hering wrote:
> On Mon, Feb 01, Andrew Cooper wrote:
>
>> c/s 2d2f789 "tools: rename libxc's evtchn_port_or_error_t with an xc_
>> prefix" doesn't cater for older applications which have requested
>> XC_WANT_COMPAT_EVTCHN_API
> Not sure, but I think this breaks staging at la
On Mon, Feb 01, Andrew Cooper wrote:
> c/s 2d2f789 "tools: rename libxc's evtchn_port_or_error_t with an xc_
> prefix" doesn't cater for older applications which have requested
> XC_WANT_COMPAT_EVTCHN_API
Not sure, but I think this breaks staging at last in SLES11:
[ 93s] gcc -DPIC -O1 -fno-o
On 03/02/16 16:10, Ian Campbell wrote:
> Currently __XEN_TOOLS__ is defined in the global CFLAGS used for tools
> builds, exposing them all to the various unstable hypercall interfaces.
>
> However there are places where we do not want this (in particular all
> the stable libraries now under tools/
On Wed, Feb 03, 2016 at 05:08:44PM +0100, Daniel Kiper wrote:
> On Tue, Feb 02, 2016 at 03:50:17PM -0600, Doug Goldstein wrote:
> > On 2/2/16 3:20 PM, Daniel Kiper wrote:
> > > On Tue, Feb 02, 2016 at 01:02:56PM -0800, PGNet Dev wrote:
> > >> Here http://wiki.xenproject.org/wiki/Xen_EFI#Xen_as_gz_b
The next Xen technical call is scheduled for:
Wed 10 Feb 17:00:00 GMT 2016
`date -d @1455123600`
Note that the time can be changed if the participants interested in
the proposed topics are in a timezone which makes this slot inconvenient.
See http://lists.xen.org/archives/html/xen-devel/2
flight 80228 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/80228/
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 Mon, Jan 18, 2016 at 09:29:38AM +, Ian Campbell wrote:
> Just adding the Remus maintainers to the CC.
ping?
>
> On Fri, 2016-01-15 at 15:26 -0300, Pato Sáinz wrote:
> > Good evening, people.
> >
> > More than a bug, it's an issue, a big one IMO.
> >
> > Even though information on the Rem
On Wed, Feb 03, Wei Liu wrote:
> If it is to be removed, why don't you just filter it out and not have it
> in JSON at all? This is provided libxl won't rely on that to do proper
> clean-up I don't see the value of retaining them, and if libxl is
> relying on the JSON file to do clean-up the desig
On Wed, Feb 03, 2016 at 11:11:39AM -0500, Boris Ostrovsky wrote:
> HVMlite VCPUs can be added and removed by toggling 'availability'
> value of VCPU's xenstore entry.
>
> Signed-off-by: Boris Ostrovsky
> ---
>
> I am not sure this is really needed since it's no different from how we
> do hotplug
Ian Campbell writes ("[PATCH v2 2/2] tools: Do not expose all builds to
unstable hypercall APIs by default"):
> Currently __XEN_TOOLS__ is defined in the global CFLAGS used for tools
> builds, exposing them all to the various unstable hypercall interfaces.
Acked-by: Ian Jackson
Ian Campbell writes ("[PATCH v2 1/2] tools: consolidate Makefile runes to
building+installing qemu-trad"):
> Currently both subdir-all-qemu-traditional-dir and subdir-install-...
> recurse into qemu-traditional-dir and run xen-setup, but with subtly
> different options (--extra-cflags was only pas
HVMlite VCPUs can be added and removed by toggling 'availability'
value of VCPU's xenstore entry.
Signed-off-by: Boris Ostrovsky
---
I am not sure this is really needed since it's no different from how we
do hotplug for PV or HVM/qemu-trad guests.
I may have been a bit too grandiose by describi
Currently both subdir-all-qemu-traditional-dir and subdir-install-...
recurse into qemu-traditional-dir and run xen-setup, but with subtly
different options (--extra-cflags was only passed for install).
Consolidate these by having the install target depend on the all
(build) target and only callin
Currently __XEN_TOOLS__ is defined in the global CFLAGS used for tools
builds, exposing them all to the various unstable hypercall interfaces.
However there are places where we do not want this (in particular all
the stable libraries now under tools/libs), and there is a risk of
such uses slipping
On Tue, Feb 02, 2016 at 03:50:17PM -0600, Doug Goldstein wrote:
> On 2/2/16 3:20 PM, Daniel Kiper wrote:
> > On Tue, Feb 02, 2016 at 01:02:56PM -0800, PGNet Dev wrote:
> >> Here http://wiki.xenproject.org/wiki/Xen_EFI#Xen_as_gz_binary refers
> >> to original discussion in 2013 (work has been deferr
>>> On 03.02.16 at 16:54, wrote:
> On Wed, 2016-02-03 at 08:19 -0700, Jan Beulich wrote:
>> > > > On 03.02.16 at 15:12, wrote:
>> > This patch disables pkeys for guest in non-paging mode, However XEN
>> > always
>> > uses
>> > paging mode to emulate guest non-paging mode, To emulate this
>> > be
At 22:12 +0800 on 03 Feb (1454537524), Huaitong Han wrote:
> From: George Dunlap
>
> At the moment, the pfec argument to gva_to_gfn has two functions:
>
> * To inform guest_walk what kind of access is happenind
>
> * As a value to pass back into the guest in the event of a fault.
>
> Unfortuna
On Wed, 2016-02-03 at 08:19 -0700, Jan Beulich wrote:
> > > > On 03.02.16 at 15:12, wrote:
> > This patch disables pkeys for guest in non-paging mode, However XEN
> > always
> > uses
> > paging mode to emulate guest non-paging mode, To emulate this
> > behavior, pkeys
> > needs to be manually dis
On Wed, 2016-02-03 at 15:30 +, Ian Campbell wrote:
> @@ -159,8 +161,6 @@ SHDEPS_libxenlight = $(SHLIB_libxenctrl)
> $(SHLIB_libxenstore) $(SHLIB_libblktapc
> LDLIBS_libxenlight = $(SHDEPS_libxenlight)
> $(XEN_XENLIGHT)/libxenlight$(libextension)
> SHLIB_libxenlight = $(SHDEPS_libxenlight) -W
> > > > Open: It seems no system call/ioctl is provided by Linux kernel to
> > > >get the physical address from a virtual address.
> > > >/proc//pagemap provides information of mapping from
> > > >VA to PA. Is it an acceptable solution to let QEMU parse this
> > > >
flight 80121 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/80121/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt-raw 13 guest-saverestorefail never pass
test-armhf-armhf-libvirt-raw 11 migrate-sup
Currently both subdir-all-qemu-traditional-dir and subdir-install-...
recurse into qemu-traditional-dir and run xen-setup, but with subtly
different options (--extra-cflags was only passed for install).
Consolidate these by having the install target depend on the all
(build) target and only callin
On 1/27/16 9:18 AM, Lars Kurth wrote:
>
> Sorry, I have been a little bit unresponsive. Things were a little hectic
> in the last 2 weeks.
>
>
> On 27/01/2016 11:21, "George Dunlap" wrote:
>
>>
>>> FWIW, I am +1 for setting up infrastructure like this, but lets do it
>>> properly.
>>>
>>> Lars
1 - 100 of 266 matches
Mail list logo
