Hi,
On 5 March 2017 at 13:51, Julien Grall wrote:
> Hi Bhupinder,
>
> Commit title: s/atleat/at least/
>
> On 02/21/2017 11:26 AM, Bhupinder Thakur wrote:
>>
>> Ensure that nr_spis intialized in in vgic_init is atleast 1 to allow
>> allocation of
>
>
> s/intialized/initialized/ and again s/atleas
On 15/03/17 20:23, Stefano Stabellini wrote:
> Implement functions to handle the xenbus handshake. Upon connection,
> allocate the rings according to the protocol specification.
>
> Initialize a work_struct and a wait_queue. The work_struct will be used
> to schedule work upon receiving an event c
On 15/03/17 20:23, Stefano Stabellini wrote:
> Hi all,
>
> This patch series implements a new transport for 9pfs, aimed at Xen
> systems.
>
> The transport is based on a traditional Xen frontend and backend drivers
> pair. This patch series implements the frontend, which typically runs in
> a reg
On 15/03/17 19:44, Stefano Stabellini wrote:
> On Wed, 15 Mar 2017, Juergen Gross wrote:
>> On 14/03/17 22:22, Stefano Stabellini wrote:
>>> Hi Juergen,
>>>
>>> thank you for the review!
>>>
>>> On Tue, 14 Mar 2017, Juergen Gross wrote:
On 14/03/17 00:50, Stefano Stabellini wrote:
> Implem
On Wed, Mar 15, 2017 at 10:48:25AM -0600, Jan Beulich wrote:
On 15.03.17 at 06:11, wrote:
>> +/*
>> + * The following method to update IRTE is safe on condition that
>> + * only the high qword or the low qword is to be updated.
>> + * If entire IRTE is to be up
On 15/03/17 19:05, Mohsen wrote:
> Thank you so much Lars.
> I used LibreOffice and I will test HTML format and inform you.
You are aware of the MediaWiki export function of LibreOffice?
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https
On Wed, Mar 15, 2017 at 10:41:13AM -0600, Jan Beulich wrote:
On 15.03.17 at 06:11, wrote:
>> --- a/xen/drivers/passthrough/vtd/intremap.c
>> +++ b/xen/drivers/passthrough/vtd/intremap.c
>> @@ -552,11 +552,12 @@ static int msi_msg_to_remap_entry(
>> struct msi_desc *msi_desc, struct msi_m
flight 106689 linux-4.1 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106689/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvh-intel 11 guest-start fail REGR. vs. 104301
Tests which are faili
flight 106687 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106687/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail
REGR. vs. 106570
test
On 03/15/2017 06:56 PM, Wei Liu wrote:
On Wed, Mar 15, 2017 at 10:02:46AM +0800, Zhang Chen wrote:
On 03/14/2017 07:24 PM, Wei Liu wrote:
On Mon, Mar 06, 2017 at 10:59:25AM +0800, Zhang Chen wrote:
We use kernel colo proxy's way to get the checkpoint event
from qemu colo-compare.
Qemu colo-
flight 106696 qemu-upstream-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106696/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-libvirt 13 saverestore-support-checkfail like 105955
test-armhf-armhf-
On Wed, 15 Mar 2017, Julien Grall wrote:
> On 15/03/17 07:19, Wei Chen wrote:
> > Hi Stefano,
>
> Hello,
>
> > On 2017/3/15 8:24, Stefano Stabellini wrote:
> > > On Mon, 13 Mar 2017, Wei Chen wrote:
> > > > We want to add HCR_EL2 register to Xen context switch. And each copy
> > > > of HCR_EL2 in
On Wed, 15 Mar 2017, Greg Kurz wrote:
> On Mon, 13 Mar 2017 16:55:57 -0700
> Stefano Stabellini wrote:
>
> > Upon receiving an event channel notification from the frontend, schedule
> > the bottom half. From the bottom half, read one request from the ring,
> > create a pdu and call pdu_submit to
On Wed, 15 Mar 2017, Greg Kurz wrote:
> On Mon, 13 Mar 2017 16:55:59 -0700
> Stefano Stabellini wrote:
>
> > Once a request is completed, xen_9pfs_push_and_notify gets called. In
> > xen_9pfs_push_and_notify, update the indexes (data has already been
> > copied to the sg by the common code) and s
On Wed, 15 Mar 2017, Greg Kurz wrote:
> On Mon, 13 Mar 2017 16:55:58 -0700
> Stefano Stabellini wrote:
>
> > Implement xen_9pfs_init_in/out_iov_from_pdu and
> > xen_9pfs_pdu_vmarshal/vunmarshall by creating new sg pointing to the
> > data on the ring.
> >
> > This is safe as we only handle one r
On Wed, 15 Mar 2017, Greg Kurz wrote:
> On Mon, 13 Mar 2017 16:55:57 -0700
> Stefano Stabellini wrote:
>
> > Upon receiving an event channel notification from the frontend, schedule
> > the bottom half. From the bottom half, read one request from the ring,
> > create a pdu and call pdu_submit to
On Wed, 15 Mar 2017, Greg Kurz wrote:
> On Mon, 13 Mar 2017 16:55:56 -0700
> Stefano Stabellini wrote:
>
> > Write the limits of the backend to xenstore. Connect to the frontend.
> > Upon connection, allocate the rings according to the protocol
> > specification.
> >
> > Initialize a QEMUBH to s
flight 106682 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106682/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-credit2 15 guest-start/debian.repeat fail REGR. vs. 106574
Regressions which
2017-03-13 22:31 keltezéssel, Stefano Stabellini írta:
On Thu, 9 Mar 2017, Gémes Géza wrote:
Hi,
I've sent my last couple of days on trying to make raisin tests run on
different distributions. Tried Ubuntu 16.04, Ubuntu 14.04, CentOS 7 and CentOS
6.8 so far. The tests fail because of different
From: Oleksandr Tyshchenko
Update IOMMU mapping if the IOMMU doesn't share page table with the CPU.
The best place to do so on ARM is p2m_set_entry(). Use mfn as an indicator
of the required action. If mfn is valid call iommu_map_pages(),
otherwise - iommu_unmap_pages().
Signed-off-by: Oleksandr
From: Oleksandr Tyshchenko
Port Linux helper of_count_phandle_with_args for counting
number of phandles in a property.
Signed-off-by: Oleksandr Tyshchenko
---
xen/common/device_tree.c | 7 +++
xen/include/xen/device_tree.h | 19 +++
2 files changed, 26 insertions(+)
Hi, all.
The purpose of this patch series is to create a base for porting
any "Non-shared" IOMMUs to Xen on ARM. Saying "Non-shared" IOMMU I mean
the IOMMU that can't share the page table with the CPU.
Primarily, we are interested in IPMMU-VMSA and I hope that it will be the first
candidate.
It i
From: Oleksandr Tyshchenko
Extend the IOMMU code with new APIs and platform callbacks.
These new map_pages/unmap_pages API do almost the same thing
as existing map_page/unmap_page ones except the formers can
handle the number of pages. So do new platform callbacks.
Currently, this patch requires
From: Oleksandr Tyshchenko
The alloc_page_table callback is a mandatory thing
for the IOMMUs that don't share page table with the CPU on ARM.
The unshared IOMMUs have to perform all required actions here
to be ready to handle IOMMU mapping updates right after completing it.
The arch_iommu_popula
From: Oleksandr Tyshchenko
The presence of this flag lets us know that the guest
has devices which will most likely be used for passthrough.
In that case we have to call iommu_construct(), actually
what the real assign_device call usually does.
As iommu_domain_init() is called with forced to fal
From: Oleksandr Tyshchenko
Logic on ARM was changed a bit.
Taking into account that we are here because we have the IOMMU
that doesn't share page table with the CPU and need_iommu flag is set
just call arch_iommu_populate_page_table() to allow unshared IOMMU
to allocate resources.
No functional
From: Oleksandr Tyshchenko
This flag is intended to let Xen know that the guest has devices
which will most likely be used for passthrough.
The primary aim of this knowledge is to help the IOMMUs that don't
share page tables with the CPU be ready before P2M code starts
updating IOMMU mapping.
So,
From: Oleksandr Tyshchenko
The helper has the same purpose as existing for x86 one.
It is used for choosing IOMMU mapping attribute according to
the memory type.
Signed-off-by: Oleksandr Tyshchenko
---
xen/include/asm-arm/p2m.h | 34 ++
1 file changed, 34 insert
From: Oleksandr Tyshchenko
Not every integrated into ARM SoCs IOMMU can share page tables
with the CPU and as result the iommu_use_hap_pt(d) is not always true.
Reuse x86's iommu_hap_pt_share flag to indicate whether the IOMMU
page table is shared or not.
Now all IOMMU drivers on ARM are able to
Commit 82713ec8d2 ("x86: use native RDTSC(P) execution when guest and
host frequencies are the same") left out optimization for PV guests
when host and guest run at the same frequency.
For such a case we should be able not to use virtual TSC regardless
of whether we are runing before or after a mi
Hi all,
This patch series implements a new transport for 9pfs, aimed at Xen
systems.
The transport is based on a traditional Xen frontend and backend drivers
pair. This patch series implements the frontend, which typically runs in
a regular unprivileged guest.
I also sent a series that implement
Implement struct p9_trans_module create and close functions by looking
at the available Xen 9pfs frontend-backend connections. We don't expect
many frontend-backend connections, thus walking a list is OK.
Send requests to the backend by copying each request to one of the
available rings (each fron
Sync the ring.h file with upstream Xen, to introduce the new ring macros.
They will be used by the Xen transport for 9pfs.
Signed-off-by: Stefano Stabellini
CC: konrad.w...@oracle.com
CC: boris.ostrov...@oracle.com
CC: jgr...@suse.com
CC: gr...@kaod.org
---
NB: The new macros have not been commi
Introduce the Xen 9pfs transport driver: add struct xenbus_driver to
register as a xenbus driver and add struct p9_trans_module to register
as v9fs driver.
All functions are empty stubs for now.
Signed-off-by: Stefano Stabellini
Reviewed-by: Boris Ostrovsky
CC: gr...@kaod.org
CC: jgr...@suse.co
Implement functions to handle the xenbus handshake. Upon connection,
allocate the rings according to the protocol specification.
Initialize a work_struct and a wait_queue. The work_struct will be used
to schedule work upon receiving an event channel notification from the
backend. The wait_queue wi
This patch adds a Kconfig option and Makefile support for building the
9pfs Xen driver.
Signed-off-by: Stefano Stabellini
Reviewed-by: Juergen Gross
CC: gr...@kaod.org
CC: boris.ostrov...@oracle.com
CC: jgr...@suse.com
CC: Eric Van Hensbergen
CC: Ron Minnich
CC: Latchesar Ionkov
CC: v9fs-deve
Upon receiving a notification from the backend, schedule the
p9_xen_response work_struct. p9_xen_response checks if any responses are
available, if so, it reads them one by one, calling p9_client_cb to send
them up to the 9p layer (p9_client_cb completes the request). Handle the
ring following the
It uses the new ring.h macros to declare rings and interfaces.
Signed-off-by: Stefano Stabellini
CC: konrad.w...@oracle.com
CC: boris.ostrov...@oracle.com
CC: jgr...@suse.com
CC: gr...@kaod.org
---
include/xen/interface/io/9pfs.h | 40
1 file changed, 40
On Wed, 15 Mar 2017, Greg Kurz wrote:
> On Wed, 15 Mar 2017 11:36:12 -0700 (PDT)
> Stefano Stabellini wrote:
>
> > On Wed, 15 Mar 2017, Greg Kurz wrote:
> > > On Mon, 13 Mar 2017 16:55:53 -0700
> > > Stefano Stabellini wrote:
> > >
> > > > Do not use the ring.h header installed on the system.
On Wed, 15 Mar 2017, Greg Kurz wrote:
> On Mon, 13 Mar 2017 16:55:54 -0700
> Stefano Stabellini wrote:
>
> > It uses the new ring.h macros to declare rings and interfaces.
> >
> > Signed-off-by: Stefano Stabellini
> > CC: anthony.per...@citrix.com
> > CC: jgr...@suse.com
> > ---
> > hw/9pfs/xe
On Wed, 15 Mar 2017 11:36:12 -0700 (PDT)
Stefano Stabellini wrote:
> On Wed, 15 Mar 2017, Greg Kurz wrote:
> > On Mon, 13 Mar 2017 16:55:53 -0700
> > Stefano Stabellini wrote:
> >
> > > Do not use the ring.h header installed on the system. Instead, import
> > > the header into the QEMU codeba
On Wed, 15 Mar 2017, Juergen Gross wrote:
> On 14/03/17 22:22, Stefano Stabellini wrote:
> > Hi Juergen,
> >
> > thank you for the review!
> >
> > On Tue, 14 Mar 2017, Juergen Gross wrote:
> >> On 14/03/17 00:50, Stefano Stabellini wrote:
> >>> Implement functions to handle the xenbus handshake.
On Wed, 15 Mar 2017, Paolo Bonzini wrote:
> On 14/03/2017 21:23, Stefano Stabellini wrote:
> > On Tue, 14 Mar 2017, Stefano Stabellini wrote:
> >>> Then you add to Makefile:
> >>>
> >>> CONFIG_SOFTMMU := $(if $(filter %-softmmu,$(TARGET_DIRS)),y)
> >>> CONFIG_USER_ONLY := $(if $(filter %-user,$(T
On Wed, 15 Mar 2017, Greg Kurz wrote:
> On Mon, 13 Mar 2017 16:55:53 -0700
> Stefano Stabellini wrote:
>
> > Do not use the ring.h header installed on the system. Instead, import
> > the header into the QEMU codebase. This avoids problems when QEMU is
> > built against a Xen version too old to pr
flight 106676 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106676/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 105963
test-amd64-i386-xl-qemuu-
flight 106674 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106674/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl 11 guest-start fail REGR. vs. 59254
test-armhf-armhf-xl
Thank you so much Lars.
I used LibreOffice and I will test HTML format and inform you.
The structure that you listed was good and I hope Xen experts and developers
like you dedicate some hours at the weekends for update this book and add more
topics to it. I bet it is a good project for help begi
flight 106671 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106671/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail REGR. vs.
106652
Regression
On Wed, Mar 15, 2017 at 11:54:07AM -0500, Venu Busireddy wrote:
> On Wed, Mar 15, 2017 at 04:38:39PM +, Roger Pau Monn? wrote:
> > On Wed, Mar 15, 2017 at 10:11:35AM -0500, Venu Busireddy wrote:
> > > On Wed, Mar 15, 2017 at 12:56:50PM +, Roger Pau Monn? wrote:
> > > > On Wed, Mar 15, 2017
>>> On 15.03.17 at 17:46, wrote:
> On 03/15/2017 06:30 PM, Jan Beulich wrote:
> On 15.03.17 at 17:04, wrote:
>>> ---
>>> Changes since V1:
>>> - Added Andrew Cooper's credit, as he's kept the patch current
>>>througout non-trivial code changes since the initial patch.
>>> - Significantl
On Wed, Mar 15, 2017 at 04:38:39PM +, Roger Pau Monn? wrote:
> On Wed, Mar 15, 2017 at 10:11:35AM -0500, Venu Busireddy wrote:
> > On Wed, Mar 15, 2017 at 12:56:50PM +, Roger Pau Monn? wrote:
> > > On Wed, Mar 15, 2017 at 08:42:04AM -0400, Konrad Rzeszutek Wilk wrote:
> > > > On Wed, Mar 15
On 03/15/2017 05:42 AM, Juergen Gross wrote:
> On 14/03/17 18:35, Vitaly Kuznetsov wrote:
>> Changes since v2:
>> - Rebase to 4.11.0-rc1+
>> - XEN_HAVE_PVMMU moved to config XEN_PV [Juergen Gross]
>> - .pin_vcpu kept for x86_hyper_xen_hvm to support PVH Dom0 in future
>>[Juergen Gross]
>> - 'ex
>>> On 15.03.17 at 17:41, wrote:
> On 03/15/2017 12:02 PM, Jan Beulich wrote:
> On 15.03.17 at 16:26, wrote:
>>> On 15/03/17 15:23, Olaf Hering wrote:
On Wed, Mar 15, Olaf Hering wrote:
> On Wed, Mar 15, Andrew Cooper wrote:
>> As a crazy idea, doest this help?
>> tsc->i
>>> On 15.03.17 at 06:11, wrote:
> +static void update_irte(struct iremap_entry *entry,
> +const struct iremap_entry *new_ire)
> +{
> +if ( cpu_has_cx16 )
> +{
> +__uint128_t ret;
> +struct iremap_entry old_ire;
> +
> +old_ire = *entry;
> +
On 03/15/2017 06:30 PM, Jan Beulich wrote:
On 15.03.17 at 17:04, wrote:
>> ---
>> Changes since V1:
>> - Added Andrew Cooper's credit, as he's kept the patch current
>>througout non-trivial code changes since the initial patch.
>> - Significantly more patch testing (with XenServer).
>>
On 03/15/2017 12:02 PM, Jan Beulich wrote:
On 15.03.17 at 16:26, wrote:
>> On 15/03/17 15:23, Olaf Hering wrote:
>>> On Wed, Mar 15, Olaf Hering wrote:
>>>
On Wed, Mar 15, Andrew Cooper wrote:
> As a crazy idea, doest this help?
> tsc->incarnation = 0
>>> This does indeed help. O
>>> On 15.03.17 at 06:11, wrote:
> --- a/xen/drivers/passthrough/vtd/intremap.c
> +++ b/xen/drivers/passthrough/vtd/intremap.c
> @@ -552,11 +552,12 @@ static int msi_msg_to_remap_entry(
> struct msi_desc *msi_desc, struct msi_msg *msg)
> {
> struct iremap_entry *iremap_entry = NULL, *ir
On Wed, Mar 15, 2017 at 10:11:35AM -0500, Venu Busireddy wrote:
> On Wed, Mar 15, 2017 at 12:56:50PM +, Roger Pau Monn? wrote:
> > On Wed, Mar 15, 2017 at 08:42:04AM -0400, Konrad Rzeszutek Wilk wrote:
> > > On Wed, Mar 15, 2017 at 12:07:28PM +, Roger Pau Monn? wrote:
> > > > On Fri, Mar 10
>>> On 15.03.17 at 17:04, wrote:
> ---
> Changes since V1:
> - Added Andrew Cooper's credit, as he's kept the patch current
>througout non-trivial code changes since the initial patch.
> - Significantly more patch testing (with XenServer).
> - Restricted lock scope.
Not by much, as it seem
>>> On 15.03.17 at 16:53, wrote:
> On 15/03/17 16:43, Boris Ostrovsky wrote:
>> On 03/15/2017 11:26 AM, Andrew Cooper wrote:
>>> On 15/03/17 15:23, Olaf Hering wrote:
On Wed, Mar 15, Olaf Hering wrote:
> On Wed, Mar 15, Andrew Cooper wrote:
>> As a crazy idea, doest this help?
>>
LOCK-prefixed instructions are currenly allowed to run in parallel
in x86_emulate(), which can lead the guest into an undefined state.
This patch fixes the issue.
Signed-off-by: Razvan Cojocaru
Signed-off-by: Andrew Cooper
---
Changes since V1:
- Added Andrew Cooper's credit, as he's kept the
>>> On 15.03.17 at 16:26, wrote:
> On 15/03/17 15:23, Olaf Hering wrote:
>> On Wed, Mar 15, Olaf Hering wrote:
>>
>>> On Wed, Mar 15, Andrew Cooper wrote:
As a crazy idea, doest this help?
tsc->incarnation = 0
>> This does indeed help. One system shows now the results below, which
>> mea
Saving/restoring the physmap to/from xenstore was introduced to
QEMU majorly in order to cover up the VRAM region restore issue.
The sequence of restore operations implies that we should know
the effective guest VRAM address *before* we have the VRAM region
restored (which happens later). Unfortuna
Signed-off-by: Dario Faggioli
---
Cc: George Dunlap
Cc: Jan Beulich
---
Changes from v1:
* improved subject line.
---
xen/common/sched_credit2.c |2 --
1 file changed, 2 deletions(-)
diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
index af457c1..bb1c657 100644
--- a/xe
On Wed, Mar 15, 2017 at 09:53:02AM -0600, Jan Beulich wrote:
> >>> On 15.03.17 at 16:43, wrote:
...
> > We have seen something similar being caused by the superpage
> > attribute getting dropped when the domU was migrated. The new
> > copy of the domU only has 4K pages instead of 2MB pages eventua
On 15/03/17 16:43, Boris Ostrovsky wrote:
> On 03/15/2017 11:26 AM, Andrew Cooper wrote:
>> On 15/03/17 15:23, Olaf Hering wrote:
>>> On Wed, Mar 15, Olaf Hering wrote:
>>>
On Wed, Mar 15, Andrew Cooper wrote:
> As a crazy idea, doest this help?
> tsc->incarnation = 0
>>> This does ind
>>> On 15.03.17 at 16:43, wrote:
> On Wed, Mar 15, 2017 at 12:20:44PM +0100, Olaf Hering wrote:
>> After reports about degraded performance after a PV domU was migrated
>> from one dom0 to another it turned out that this issue happens with
>> every version of Xen and every version of domU kernel.
On 15/03/17 15:43, Alan Robinson wrote:
> Hi Olaf,
>
> On Wed, Mar 15, 2017 at 12:20:44PM +0100, Olaf Hering wrote:
>> After reports about degraded performance after a PV domU was migrated
>> from one dom0 to another it turned out that this issue happens with
>> every version of Xen and every versi
>>> On 15.03.17 at 14:48, wrote:
> On 03/15/2017 09:31 AM, Jan Beulich wrote:
> On 15.03.17 at 14:24, wrote:
>>> On 03/15/2017 06:28 AM, Jan Beulich wrote:
@@ -3716,9 +3720,9 @@ x86_emulate(
break;
case 0x9b: /* wait/fwait */
-fic.insn_bytes =
Hi Olaf,
On Wed, Mar 15, 2017 at 12:20:44PM +0100, Olaf Hering wrote:
> After reports about degraded performance after a PV domU was migrated
> from one dom0 to another it turned out that this issue happens with
> every version of Xen and every version of domU kernel.
>
> The used benchmark is 's
On 03/15/2017 11:26 AM, Andrew Cooper wrote:
> On 15/03/17 15:23, Olaf Hering wrote:
>> On Wed, Mar 15, Olaf Hering wrote:
>>
>>> On Wed, Mar 15, Andrew Cooper wrote:
As a crazy idea, doest this help?
tsc->incarnation = 0
>> This does indeed help. One system shows now the results below, w
>>> On 15.03.17 at 14:08, wrote:
> With that said, should I submit a new version of the original LOCK patch
> to have in the meantime (until the fix suggested by Andrew is
> implemented, and presumably to be reverted once it lands), or is it not
> worth xen-devel's extra time?
I think it would be
On 15/03/17 16:26, Andrew Cooper wrote:
> On 15/03/17 15:23, Olaf Hering wrote:
>> On Wed, Mar 15, Olaf Hering wrote:
>>
>>> On Wed, Mar 15, Andrew Cooper wrote:
As a crazy idea, doest this help?
tsc->incarnation = 0
>> This does indeed help. One system shows now the results below, which
On 15/03/17 15:23, Olaf Hering wrote:
> On Wed, Mar 15, Olaf Hering wrote:
>
>> On Wed, Mar 15, Andrew Cooper wrote:
>>> As a crazy idea, doest this help?
>>> tsc->incarnation = 0
> This does indeed help. One system shows now the results below, which
> means the performance goes down during migrati
On Wed, Mar 15, Olaf Hering wrote:
> On Wed, Mar 15, Andrew Cooper wrote:
> > As a crazy idea, doest this help?
> > tsc->incarnation = 0
This does indeed help. One system shows now the results below, which
means the performance goes down during migration (to localhost) and goes
back to normal aft
On Wed, Mar 15, 2017 at 12:56:50PM +, Roger Pau Monn? wrote:
> On Wed, Mar 15, 2017 at 08:42:04AM -0400, Konrad Rzeszutek Wilk wrote:
> > On Wed, Mar 15, 2017 at 12:07:28PM +, Roger Pau Monn? wrote:
> > > On Fri, Mar 10, 2017 at 10:28:43AM -0500, Konrad Rzeszutek Wilk wrote:
> > > > On Fri,
flight 106678 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106678/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail like 106650
test-armhf-armhf-libvirt 13
On Wed, Mar 15, 2017 at 09:42:53AM -0500, Doug Goldstein wrote:
> On 3/15/17 9:38 AM, Daniel Kiper wrote:
> > On Wed, Mar 15, 2017 at 09:27:27AM -0500, Doug Goldstein wrote:
> >> On 3/15/17 6:35 AM, Daniel Kiper wrote:
> >>> On Thu, Mar 09, 2017 at 02:02:49PM -0600, Doug Goldstein wrote:
> >>>
> >>
branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-xl-pvh-intel
testid guest-start
Tree: linux
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditio
flight 106693 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106693/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a
build-arm64 5 xen
On Wed, Mar 15, Andrew Cooper wrote:
> As a crazy idea, doest this help?
> tsc->incarnation = 0
Had to move to another testhost and this seems to help. Will do more testing
once the original testsystems are accessible again. Thanks!
Olaf
signature.asc
Description: PGP signature
__
On 3/15/17 9:38 AM, Daniel Kiper wrote:
> On Wed, Mar 15, 2017 at 09:27:27AM -0500, Doug Goldstein wrote:
>> On 3/15/17 6:35 AM, Daniel Kiper wrote:
>>> On Thu, Mar 09, 2017 at 02:02:49PM -0600, Doug Goldstein wrote:
>>>
>>> [...]
>>>
Still missing 'xl info'.
>>>
>>> Got Intel NUC5i3MYHE (inte
On Wed, Mar 15, 2017 at 09:27:27AM -0500, Doug Goldstein wrote:
> On 3/15/17 6:35 AM, Daniel Kiper wrote:
> > On Thu, Mar 09, 2017 at 02:02:49PM -0600, Doug Goldstein wrote:
> >
> > [...]
> >
> >> Still missing 'xl info'.
> >
> > Got Intel NUC5i3MYHE (internally it is NUC5i3MYBE board) into my hand
On 03/15/2017 02:42 PM, Jan Beulich wrote:
On 15.03.17 at 13:08, wrote:
>> On 15/03/17 07:49, Jan Beulich wrote:
>> On 14.03.17 at 22:07, wrote:
On 12/14/2016 09:37 AM, Razvan Cojocaru wrote:
> On 12/14/2016 09:14 AM, Jan Beulich wrote:
> On 13.12.16 at 23:02, wrote:
>>
On 3/15/17 6:35 AM, Daniel Kiper wrote:
> On Thu, Mar 09, 2017 at 02:02:49PM -0600, Doug Goldstein wrote:
>
> [...]
>
>> Still missing 'xl info'.
>
> Got Intel NUC5i3MYHE (internally it is NUC5i3MYBE board) into my hands.
> I have put 8 GiB RAM and 500 GB SATA 3 into it. Updated BIOS/EFI to 0041
On 03/13/2017 07:17 PM, Tamas K Lengyel wrote:
> On Mon, Mar 13, 2017 at 6:29 AM, Razvan Cojocaru
> wrote:
>> On 03/13/2017 02:19 PM, Jan Beulich wrote:
>> On 13.03.17 at 13:01, wrote:
On 03/10/2017 09:01 PM, Tamas K Lengyel wrote:
> On Fri, Mar 10, 2017 at 4:21 AM, Andrew Cooper
>>>
On 03/14/2017 01:05 PM, Thomas Garnier wrote:
> This patch aligns MODULES_END to the beginning of the Fixmap section.
> It optimizes the space available for both sections. The address is
> pre-computed based on the number of pages required by the Fixmap
> section.
>
> It will allow GDT remapping in
On 15/03/17 13:37, Jan Beulich wrote:
> In anticipation of further flavors (AVX, AVX-512) going to be added
> (which would make the current situation even worse), facilitate
> reduction of build time (and hence latency to availability of test
> results) via use of make's -j option.
>
> Signed-off-b
On 03/15/2017 09:31 AM, Jan Beulich wrote:
On 15.03.17 at 14:24, wrote:
>> On 03/15/2017 06:28 AM, Jan Beulich wrote:
>>> @@ -3716,9 +3720,9 @@ x86_emulate(
>>> break;
>>>
>>> case 0x9b: /* wait/fwait */
>>> -fic.insn_bytes = 1;
>>> host_and_vcpu_must_have(fp
In anticipation of further flavors (AVX, AVX-512) going to be added
(which would make the current situation even worse), facilitate
reduction of build time (and hence latency to availability of test
results) via use of make's -j option.
Signed-off-by: Jan Beulich
--- a/.gitignore
+++ b/.gitignor
>>> On 15.03.17 at 14:24, wrote:
> On 03/15/2017 06:28 AM, Jan Beulich wrote:
>> @@ -3716,9 +3720,9 @@ x86_emulate(
>> break;
>>
>> case 0x9b: /* wait/fwait */
>> -fic.insn_bytes = 1;
>> host_and_vcpu_must_have(fpu);
>> get_fpu(X86EMUL_FPU_wait, &fic);
>>
On 03/15/2017 06:28 AM, Jan Beulich wrote:
> When an FPU instruction with a memory destination fails during the
> memory write, it should not affect FPU register state. Due to the way
> we emulate FPU (and SIMD) instructions, we can only guarantee this by
> - backing out changes to the FPU register
On Tue, Mar 14, 2017 at 05:47:08AM -0600, Jan Beulich wrote:
> All,
>
> with the goal of releasing in about 3 weeks time, please point out
> backport candidates you find missing from the respective staging
> branch, but which you consider relevant.
It's maybe a little bit premature but I would li
On Wed, Mar 15, 2017 at 08:42:04AM -0400, Konrad Rzeszutek Wilk wrote:
> On Wed, Mar 15, 2017 at 12:07:28PM +, Roger Pau Monné wrote:
> > On Fri, Mar 10, 2017 at 10:28:43AM -0500, Konrad Rzeszutek Wilk wrote:
> > > On Fri, Mar 10, 2017 at 12:23:18PM +0900, Roger Pau Monné wrote:
> > > > On Thu,
On 15/03/17 13:08, Wei Liu wrote:
> On Wed, Mar 15, 2017 at 01:01:52PM +0100, Sander Eikelenboom wrote:
>> Hi Ian / Wei,
>>
>> Qemu-xen commits:
>> 021746c131cdfeab9d82ff918795a9f18d20d7ae PCMachineState: introduce
>> acpi_build_enabled field
>> 804ba7c10bbc66bb8a8aa73ecc60f620da7423d5 xen: Fix xe
On Wed, Mar 15, 2017 at 12:07:28PM +, Roger Pau Monné wrote:
> On Fri, Mar 10, 2017 at 10:28:43AM -0500, Konrad Rzeszutek Wilk wrote:
> > On Fri, Mar 10, 2017 at 12:23:18PM +0900, Roger Pau Monné wrote:
> > > On Thu, Mar 09, 2017 at 07:29:34PM -0500, Konrad Rzeszutek Wilk wrote:
> > > > On Thu,
>>> On 15.03.17 at 13:08, wrote:
> On 15/03/17 07:49, Jan Beulich wrote:
> On 14.03.17 at 22:07, wrote:
>>> On 12/14/2016 09:37 AM, Razvan Cojocaru wrote:
On 12/14/2016 09:14 AM, Jan Beulich wrote:
On 13.12.16 at 23:02, wrote:
>> On 13/12/2016 21:55, Razvan Cojocaru wrote:
Hi Mohsen,
> On 15 Mar 2017, at 09:50, Mohsen wrote:
>
> Dear Xen Project community members,
>
> I have written a Xen book recently (pdf attached) which is aimed at teaching
> Xen newbies. I would like to make the book available to the Xen Project under
> a CC-BY-SA-3.0 license. Ideally, I wo
flight 106690 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106690/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 1 build-check(1) blocked n/a
test-amd64-amd64-xl-qemuu-debianhvm
The current logic of using VT-d pi is when guest configurates the pirq's
destination vcpu to a single vcpu, the according IRTE is updated to
posted format. If the destination of the pirq is multiple vcpus, we just use
interrupt remapping. Obviously, we should fall back to remapping interrupt
when g
1 - 100 of 167 matches
Mail list logo
