flight 94518 xen-4.5-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94518/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt5 libvirt-build fail REGR. vs. 93989
build-amd64-libvi
The length checks on the grant table copy_ops for setting hash key and
hash mapping are checking the local 'len' value which is correct in
the case of the former but not the latter. This was picked up by
static analysis checks.
This patch replaces checks of 'len' with 'copy_op.len' in both cases
t
Propagate the IOMMU Device-TLB flush error up to the ept_set_entry(),
when VT-d shares EPT page table.
Signed-off-by: Quan Xu
Acked-by: Kevin Tian
CC: Jun Nakajima
CC: Kevin Tian
CC: George Dunlap
CC: Jan Beulich
CC: Andrew Cooper
CC: Feng Wu
---
xen/arch/x86/mm/p2m-ept.c | 2 +-
xen/i
Propagate the IOMMU Device-TLB flush error up to ME phantom function
mapping and unmapping.
Signed-off-by: Quan Xu
CC: Jan Beulich
CC: Kevin Tian
CC: Feng Wu
---
xen/drivers/passthrough/vtd/extern.h | 3 ++-
xen/drivers/passthrough/vtd/iommu.c | 8
xen/drivers/passthrough/vtd/qui
This patch set is a prereq patch set for Patch:'VT-d Device-TLB flush issue'.
While IOMMU Device-TLB flush timed out, xen calls panic() at present. However
the existing panic()
is going to be eliminated, so we must propagate the IOMMU Device-TLB flush
error up to the call trees.
This patch set
The propagation value from IOMMU flush interfaces may be positive, which
indicates callers need to flush cache, not one of faliures.
when the propagation value is positive, this patch fixes this flush issue
as follows:
- call iommu_flush_write_buffer() to flush cache.
- return zero.
Signed-of
Propagate the IOMMU Device-TLB flush error up to the iommu_iotlb_flush{,_all}.
This patch fixes the top level ones (this patch doesn't fix the leaf ones but
the next patch does).
Signed-off-by: Quan Xu
Reviewed-by: Jan Beulich
CC: Stefano Stabellini
CC: Julien Grall
CC: Jan Beulich
CC: Kevi
Propagate the IOMMU Device-TLB flush error up to IOMMU suspending.
Signed-off-by: Quan Xu
CC: Jan Beulich
CC: Liu Jinsong
CC: Keir Fraser
CC: Andrew Cooper
CC: Suravee Suthikulpanit
CC: Stefano Stabellini
CC: Julien Grall
CC: Kevin Tian
CC: Feng Wu
---
xen/arch/x86/acpi/power.c
Propagate the IOMMU Device-TLB flush error up to IOMMU mapping.
Signed-off-by: Quan Xu
Acked-by: Kevin Tian
CC: Suravee Suthikulpanit
CC: Stefano Stabellini
CC: Julien Grall
CC: Kevin Tian
CC: Feng Wu
CC: Jan Beulich
---
xen/drivers/passthrough/amd/pci_amd_iommu.c | 17 +++--
Propagate the IOMMU Device-TLB flush error up to IOMMU unmapping.
Signed-off-by: Quan Xu
Acked-by: Kevin Tian
Reviewed-by: Jan Beulich
CC: Stefano Stabellini
CC: Julien Grall
CC: Kevin Tian
CC: Feng Wu
CC: Jan Beulich
CC: Andrew Cooper
---
xen/drivers/passthrough/arm/smmu.c|
Treat IOMMU mapping and unmapping failures as a fatal to the DomU
If IOMMU mapping and unmapping failed, crash the DomU and propagate
the error up to the call trees.
No spamming can occur. For DomU, we avoid logging any message
for already dying domains. For Dom0, that'll still be more verbose
tha
When IOMMU mapping is failed, we issue a best effort rollback, stopping
IOMMU mapping, unmapping the previous IOMMU maps and then reporting the
error up to the call trees. When rollback is not feasible (in early
initialization phase or trade-off of complexity) for the hardware domain,
we do things
Propagate the IOMMU Device-TLB flush error up to the iommu_iotlb_flush{,_all}.
This patch fixes the leaf ones.
Signed-off-by: Quan Xu
Acked-by: Kevin Tian
CC: Stefano Stabellini
CC: Julien Grall
CC: Jan Beulich
CC: Kevin Tian
CC: Feng Wu
---
xen/drivers/passthrough/arm/smmu.c | 13 +
On 17/05/16 22:50, Ed Swierk wrote:
> I added some more instrumentation and discovered that the result of
> xen_count_remap_pages() (0x85dea) is one less than the actual number
> of pages remapped by xen_set_identity_and_remap() (0x85deb).
>
> The two functions differ in their handling of a xen_e8
On May 17, 2016 8:37 PM, Jan Beulich wrote:
> >>> On 22.04.16 at 12:54, wrote:
> > --- a/xen/drivers/passthrough/vtd/qinval.c
> > +++ b/xen/drivers/passthrough/vtd/qinval.c
> > @@ -33,6 +33,8 @@ integer_param("vtd_qi_timeout", vtd_qi_timeout);
> >
> > #define IOMMU_QI_TIMEOUT (vtd_qi_timeout * MI
>>> On 06.04.16 at 01:38, wrote:
> I'm running Xen 4.6.1 with Alpine Linux 3.3.3 in dom0. In a HVM domU
> with vga="qxl", Xorg will segfault instantly if tried started. Multiple
> Linux distros have been tested and Xorg segfaults in all.
>
> Attached are a full backtrace from domU generated by
>>> On 18.05.16 at 04:15, wrote:
> On 5/12/16 4:03 AM, Jan Beulich wrote:
> On 11.05.16 at 19:35, wrote:
>>> On 5/11/16 4:47 AM, Jan Beulich wrote:
>>> On 10.05.16 at 23:05, wrote:
> --- a/xen/Kconfig.debug
> +++ b/xen/Kconfig.debug
> @@ -1,6 +1,13 @@
>
> menu "Deb
>>> On 18.05.16 at 04:16, wrote:
> On 5/12/16 4:04 AM, Jan Beulich wrote:
> On 11.05.16 at 19:37, wrote:
>>> On 5/11/16 4:45 AM, Jan Beulich wrote:
>>> On 10.05.16 at 23:05, wrote:
> --- a/xen/Kconfig.debug
> +++ b/xen/Kconfig.debug
> @@ -15,4 +15,11 @@ config DEBUG
>
>>> On 18.05.16 at 10:53, wrote:
> On May 17, 2016 8:37 PM, Jan Beulich wrote:
>> >>> On 22.04.16 at 12:54, wrote:
>> > -static void queue_invalidate_iotlb(struct iommu *iommu,
>> > -u8 granu, u8 dr, u8 dw, u16 did, u8 am, u8 ih, u64 addr)
>> > +static int __must_check queue_invalidate_iotlb_
On Wed, May 18, 2016 at 08:53:01AM +0100, Paul Durrant wrote:
> The length checks on the grant table copy_ops for setting hash key and
> hash mapping are checking the local 'len' value which is correct in
> the case of the former but not the latter. This was picked up by
> static analysis checks.
>
flight 94522 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94522/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 92452
test-amd64-amd64-xl-qemuu-win7-amd
On Tue, May 17, 2016 at 08:05:23PM +0800, Big Strong wrote:
> Is there a libxc function to translate the
> virtual address of malloc() to physical address?
Only to answer this question: no. There isn't one.
Wei.
___
Xen-devel mailing list
Xen-devel@lis
On Monday 16 May 2016 12:08:17 Stefano Stabellini wrote:
> On Wed, 11 May 2016, Arnd Bergmann wrote:
> > The XEN UEFI code has become available on the ARM architecture
> > recently, but now causes a link-time warning:
> >
> > ld: warning: drivers/xen/efi.o uses 2-byte wchar_t yet the output is to
On Tue, 17 May 2016, Julien Grall wrote:
> Hi Stefano,
>
> On 17/05/16 13:27, Stefano Stabellini wrote:
> > On Tue, 17 May 2016, Julien Grall wrote:
> > > On 17/05/16 12:24, Stefano Stabellini wrote:
> > > > I think you are right. Especially with backports in mind, it would be
> > > > better to in
>>> On 18.05.16 at 10:08, wrote:
> --Changes in v5:
>
> patch 1:
> * add the missing blank line.
> * add comments.
> * if iommu_flush_context_device failed, continue to flush IOMMU IOTLB on a
> best effort basis.
> * __defer__ to:
> - rename __intel_iommu_iotlb_flush to iommu_flush
Hi Stefano,
On 18/05/2016 11:10, Stefano Stabellini wrote:
All right, so the use case that should haved worked before (but didn't
because the implementation was broken) and wouldn't work anymore with
this patch is the following:
- vcpu1 asks region1 to be mapped at gpaddrA
the mapping fails a
>>> On 17.05.16 at 17:57, wrote:
> Patches pulled in:
> lib/sys.c: enclose file_types in define guards
> build: change MINI-OS_ROOT to MINIOS_ROOT
>
> Signed-off-by: Wei Liu
Applied, but in the future please submit patches against staging-4.6:
I had to fix up patch context to account fo
flight 94545 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94545/
Perfect :-)
All tests in this flight passed
version targeted for testing:
xen c32381352cce9744e640bf239d2704dae4af4fc7
baseline version:
xen 4f6aea066fe2cf3bf4
Wei Liu,
can I go ahead and commit this to staging? Do you approve it for 4.7?
On Mon, 16 May 2016, Julien Grall wrote:
> Hello,
>
> This small series fixes potential deadlock and the removal of unrelated
> mapping when the P2M code fails to insert/allocate mappings.
>
> This series contains bu
On Wed, May 18, 2016 at 04:31:22AM -0600, Jan Beulich wrote:
> >>> On 17.05.16 at 17:57, wrote:
> > Patches pulled in:
> > lib/sys.c: enclose file_types in define guards
> > build: change MINI-OS_ROOT to MINIOS_ROOT
> >
> > Signed-off-by: Wei Liu
>
> Applied, but in the future please su
On 18/05/2016 11:10, Stefano Stabellini wrote:
I realize that this is an unimportant case and not worth supporting. I,
for one, would prefer not to have to think about implementation halves
of apply_p2m_changes going forward so I would prefer a different patch.
That said, I still retract my com
* Stefano Stabellini wrote:
> On Tue, 17 May 2016, David Vrabel wrote:
> > On 17/05/16 11:12, Stefano Stabellini wrote:
> > > On Sat, 14 May 2016, Matt Fleming wrote:
> > >> Folks,
> > >>
> > >> Please pull the following branch which contains support for Xen on ARM
> > >> EFI platforms.
> > >>
>
On Wed, May 18, 2016 at 11:39:56AM +0100, Stefano Stabellini wrote:
> Wei Liu,
>
> can I go ahead and commit this to staging? Do you approve it for 4.7?
>
Release-acked-by: Wei Liu
> On Mon, 16 May 2016, Julien Grall wrote:
> > Hello,
> >
> > This small series fixes potential deadlock and the
On Wed, 18 May, at 12:46:38PM, Ingo Molnar wrote:
>
> I have no particular objections, since this seems to be Xen-next merged to
> the EFI
> tree that is already upstream, plus this single commit on top of t:
>
> 11ee5491e5ff Xen: EFI: Parse DT parameters for Xen specific UEFI
>
> Which, if
On 18/05/2016 11:39, Stefano Stabellini wrote:
Wei Liu,
can I go ahead and commit this to staging? Do you approve it for 4.7?
I will resend a new version of patch #2 with a summary of the discussion
we had. You can go ahead to apply #1, assuming Wei gives a release-acked.
Cheers,
--
Juli
This run is configured for baseline tests only.
flight 44427 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/44427/
Perfect :-)
All tests in this flight passed
version targeted for testing:
ovmf b41ef32518095f783d0c2343b496cc857c6f3dff
baseline version:
ovm
flight 44428 distros-debian-squeeze real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/44428/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf 4 capture-logs !broken
Signed-off-by: Anthony PERARD
---
Config.mk | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Config.mk b/Config.mk
index 05bcadc..bdc8e45 100644
--- a/Config.mk
+++ b/Config.mk
@@ -271,7 +271,7 @@ SEABIOS_UPSTREAM_URL ?= git://xenbits.xen.org/seabios.git
MINIOS_UPSTREAM_URL ?=
On Wed, May 18, 2016 at 12:35:22PM +0100, Anthony PERARD wrote:
> Signed-off-by: Anthony PERARD
Ack + queued.
Thanks
> ---
> Config.mk | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Config.mk b/Config.mk
> index 05bcadc..bdc8e45 100644
> --- a/Config.mk
> +++ b/Confi
On Fri, May 13, 2016 at 12:11 AM, AnhNN wrote:
> Hi,
>
> I have some questions about MMU update operation.
> I add some logging in function do_mmu_update (in file /xen/arch/x86/mm.c),
> and start Windows 7 32 bit HVM guest.
> After guest started, I look at log and see that MMU update has been call
flight 94527 xen-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94527/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 15 guest-localmigrate/x10 fail REGR. vs.
93932
Regressions
On 17/05/16 22:50, Ed Swierk wrote:
> I added some more instrumentation and discovered that the result of
> xen_count_remap_pages() (0x85dea) is one less than the actual number
> of pages remapped by xen_set_identity_and_remap() (0x85deb).
>
> The two functions differ in their handling of a xen_e8
On May 18, 2016 5:29 PM, Jan Beulich wrote:
> >>> On 18.05.16 at 10:53, wrote:
> > On May 17, 2016 8:37 PM, Jan Beulich wrote:
> >> >>> On 22.04.16 at 12:54, wrote:
> >> > -static void queue_invalidate_iotlb(struct iommu *iommu,
> >> > -u8 granu, u8 dr, u8 dw, u16 did, u8 am, u8 ih, u64 addr
On May 18, 2016 6:21 PM, Jan Beulich wrote:
> >>> On 18.05.16 at 10:08, wrote:
> > --Changes in v5:
> >
> > patch 1:
> > * add the missing blank line.
> > * add comments.
> > * if iommu_flush_context_device failed, continue to flush IOMMU IOTLB on
> a best effort basis.
> > * __defer__ to
With CONFIG_PARAVIRT_TIME_ACCOUNTING the kernel is capable to account
for time a thread wasn't able to run due to hypervisor scheduling.
Add support in Xen arch independent time handling for this feature by
moving it out of the arm arch into drivers/xen.
Signed-off-by: Juergen Gross
---
arch/arm
On 17/05/16 11:33, George Dunlap wrote:
> On Mon, May 16, 2016 at 11:33 PM, Boris Ostrovsky
> wrote:
>> On 05/16/2016 05:38 PM, Tony S wrote:
>>> The issue behind it is that the process execution calculation(e.g.,
>>> delta_exec) in virtualized environment should not be calculated as it
>>> did in
This run is configured for baseline tests only.
flight 44426 xen-4.4-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/44426/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvops 4 capture-logs
On May 17, 2016 3:48 PM, Jan Beulich wrote:
> >>> On 17.05.16 at 05:19, wrote:
> >> From: Xu, Quan
> >> Sent: Monday, May 16, 2016 11:26 PM
> >>
> >> On May 13, 2016 11:28 PM, Jan Beulich wrote:
> >> > >>> On 22.04.16 at 12:54, wrote:
> >> > > --- a/docs/misc/xen-command-line.markdown
> >> > >
flight 94547 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94547/
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 May 17, 2016 10:00 PM, Jan Beulich wrote:
> >>> On 22.04.16 at 12:54, wrote:
> > --- a/xen/drivers/passthrough/vtd/qinval.c
> > +++ b/xen/drivers/passthrough/vtd/qinval.c
> > @@ -206,10 +206,71 @@ static int invalidate_sync(struct iommu *iommu)
> > return 0;
> > }
> >
> > +static void de
On Wed, May 18, 2016 at 3:48 AM, Wei Liu wrote:
> On Tue, May 17, 2016 at 08:05:23PM +0800, Big Strong wrote:
>> Is there a libxc function to translate the
>> virtual address of malloc() to physical address?
>
> Only to answer this question: no. There isn't one.
>
> Wei.
Technically there is! The
On Wed, May 18, 2016 at 07:14:23AM -0600, Tamas K Lengyel wrote:
> On Wed, May 18, 2016 at 3:48 AM, Wei Liu wrote:
> > On Tue, May 17, 2016 at 08:05:23PM +0800, Big Strong wrote:
> >> Is there a libxc function to translate the
> >> virtual address of malloc() to physical address?
> >
> > Only to a
The following libraries are checked:
1. libxc, version number bumped
2. libxl, version number bumped
3. libxlu, no development in 4.7 cycle, version number not bumped
4. libs/*, new in 4.7 cycle, version number not bumped
5. libxenstore, no development in 4.7 cycle, version number not bumped
6. lib
On Wed, May 18, 2016 at 02:32:15PM +0100, Wei Liu wrote:
> The following libraries are checked:
> 1. libxc, version number bumped
> 2. libxl, version number bumped
> 3. libxlu, no development in 4.7 cycle, version number not bumped
> 4. libs/*, new in 4.7 cycle, version number not bumped
> 5. libxe
The following libraries are checked:
1. libxc, version number bumped
2. libxl, version number bumped
3. libxlu, no development in 4.7 cycle, but depends on libxl, version
number bumped
4. libs/*, new in 4.7 cycle, version numbers not bumped
5. libxenstore, no development in 4.7 cycle, version nu
On Fri, May 13, 2016 at 6:25 PM, Andrew Cooper
wrote:
> hostmode->p2m_ga_to_gfn() is a plain PT walker, and is not appropriate for a
> general L1 p2m walk. It is fine for AMD as NPT share the same format as
> normal pagetables. For Intel EPT however, it is wrong.
>
> The translation ends up corr
On Fri, May 13, 2016 at 06:25:41PM +0100, Andrew Cooper wrote:
> hostmode->p2m_ga_to_gfn() is a plain PT walker, and is not appropriate for a
> general L1 p2m walk. It is fine for AMD as NPT share the same format as
> normal pagetables. For Intel EPT however, it is wrong.
>
> The translation end
Saving a guest (xl save) crashes dom0, log below.
Paul, this seems to be happening in the code that you modified
recently. If you don't have time I can look at this but it will
probably have to wait until tomorrow.
-boris
[ 176.347760] BUG: unable to handle kernel NULL pointer dereference at
This run is configured for baseline tests only.
flight 44429 seabios real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/44429/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop
> -Original Message-
> From: Boris Ostrovsky [mailto:boris.ostrov...@oracle.com]
> Sent: 18 May 2016 14:54
> To: xen-devel; Paul Durrant
> Subject: Saving a guest crashes dom0
>
> Saving a guest (xl save) crashes dom0, log below.
>
> Paul, this seems to be happening in the code that you m
> -Original Message-
> From: Paul Durrant
> Sent: 18 May 2016 15:18
> To: 'Boris Ostrovsky'; xen-devel
> Subject: RE: Saving a guest crashes dom0
>
> > -Original Message-
> > From: Boris Ostrovsky [mailto:boris.ostrov...@oracle.com]
> > Sent: 18 May 2016 14:54
> > To: xen-devel; Pa
flight 94530 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94530/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt-xsm 7 host-ping-check-xen fail REGR. vs. 94506
test-armhf-armhf-xl
> > -Original Message-
> > From: Paul Durrant
> > Sent: 18 May 2016 15:18
> > To: 'Boris Ostrovsky'; xen-devel
> > Subject: RE: Saving a guest crashes dom0
> >
> > > -Original Message-
> > > From: Boris Ostrovsky [mailto:boris.ostrov...@oracle.com]
> > > Sent: 18 May 2016 14:54
> >
On Tue, May 17, 2016 at 09:11:16PM -0500, Doug Goldstein wrote:
> On 5/16/16 10:58 AM, Konrad Rzeszutek Wilk wrote:
> > Hey,
> >
> > These four little cleanups move the bulk of tmem control ops
> > from tmem.c to tmem_control.c.
> >
> > Last release I moved the control tmem ops from being part of
Konrad Rzeszutek Wilk writes ("Re: [Xen-devel] [PATCH for-qemu-trad] Fix build
with newer version of GNUTLS"):
> On Thu, May 05, 2016 at 11:14:44AM +0100, Wei Liu wrote:
> > Provide compatibility layer for QEMU traditional. This commit is in fact
> > backport of two upstream QEMU commits:
> > 1. f
On 17.05.2016 17:34, Jan Beulich wrote:
We use xenified kernels based on kernel 3.4 for years and benchmarks
showed that they are faster than the pvops (vanilla) kernels.
But what is the current state in terms of performance and features?
I'm not sure what you expect here. Up to openSUSE 42.1 an
Nice implementation. I tested it and it fixes the problem on the affected
system.
Just a minor typo in a comment: "it's duty" should be "its duty".
--Ed
On Wed, May 18, 2016 at 4:44 AM, Juergen Gross wrote:
> On 17/05/16 22:50, Ed Swierk wrote:
> > I added some more instrumentation and discov
On 13/05/16 10:32, Jan Beulich wrote:
> Hi George,
>
> after quite a bit of debugging on 4.6.1 I learned that said commit
> ("x86/P2M: consolidate handling of types not requiring a valid MFN")
> is more than just cleanup: Since p2m_set_entry() happily performs
> arithmetic on the passed in MFN, sh
Instead of having two functions for cycling through the E820 map in
order to count to be remapped pages and remap them later, just use one
function with a caller supplied sub-function called for each region to
be processed. This eliminates the possibility of a mismatch between
both loops which show
Wei Liu writes ("Re: [PATCH v2 for-4.7 12/14] libxl: fix passing the type
argument to xc_psr_*"):
> On Thu, Apr 28, 2016 at 06:29:03PM +0100, Ian Jackson wrote:
> > I'm very much against introducing casts which are not absolutely
> > necessary. Casts are a big hammer which can suppress important
On 18/05/16 16:39, Ed Swierk wrote:
> Nice implementation. I tested it and it fixes the problem on the
> affected system.
>
> Just a minor typo in a comment: "it's duty" should be "its duty".
Thanks. Corrected and sent to lkml.
Juergen
___
Xen-devel
On 05/18/2016 08:15 AM, Juergen Gross wrote:
> }
>
> +void __init xen_time_setup_guest(void)
> +{
> + pv_time_ops.steal_clock = xen_steal_clock;
> +
> + static_key_slow_inc(¶virt_steal_enabled);
> + /*
> + * We can't set paravirt_steal_rq_enabled as this would require the
> +
flight 94533 qemu-upstream-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94533/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-pvops 3 host-install(3) broken REG
George Dunlap writes ("Re: [Xen-devel] [PATCH] MAINTAINERS: put docs/man/ under
tool stack"):
> On Mon, May 9, 2016 at 10:57 AM, Jan Beulich wrote:
> > Right now there's only tool stack related documentation there.
> >
> > Signed-off-by: Jan Beulich
>
> Acked-by: George Dunlap
>
> But I guess
This in particular prevents updating guest IP when handling the retry
needed to forward the memory access to qemu.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -4178,6 +4178,8 @@ x86_emulate(
if ( !rc && (b & 1)
On Tue, May 17, 2016 at 09:01:00PM -0500, Doug Goldstein wrote:
> On 5/17/16 8:57 PM, Doug Goldstein wrote:
> > On 5/16/16 10:58 AM, Konrad Rzeszutek Wilk wrote:
> >> And adjust the macro: atomic_inc_and_max to update the structure.
> >>
> >> Sadly one entry: pool->pgp_count cannot use this macro a
On 18/05/16 16:46, Boris Ostrovsky wrote:
> On 05/18/2016 08:15 AM, Juergen Gross wrote:
>> }
>>
>> +void __init xen_time_setup_guest(void)
>> +{
>> +pv_time_ops.steal_clock = xen_steal_clock;
>> +
>> +static_key_slow_inc(¶virt_steal_enabled);
>> +/*
>> + * We can't set paravirt_
On Wed, 2016-05-18 at 14:24 +0200, Juergen Gross wrote:
> On 17/05/16 11:33, George Dunlap wrote:
> > > Looks like CONFIG_PARAVIRT_TIME_ACCOUNTING is used for adjusting
> > > process
> > > times. KVM uses it but Xen doesn't.
> > Is someone on the Linux side going to put this on their to-do list
> >
On 05/18/2016 10:27 AM, Paul Durrant wrote:
> This should fix the problem for you:
Yes, that does it. Thanks.
-boris
>
> diff --git a/drivers/net/xen-netback/interface.c
> b/drivers/net/xen-netback/interface.c
> index 1c7f49b..83deeeb 100644
> --- a/drivers/net/xen-netback/interface.c
> +++ b
flight 94551 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94551/
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 18/05/16 15:49, Jan Beulich wrote:
> This in particular prevents updating guest IP when handling the retry
> needed to forward the memory access to qemu.
>
> Signed-off-by: Jan Beulich
Oops.
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xe
> -Original Message-
> From: Boris Ostrovsky [mailto:boris.ostrov...@oracle.com]
> Sent: 18 May 2016 15:57
> To: Paul Durrant; xen-devel
> Subject: Re: Saving a guest crashes dom0
>
> On 05/18/2016 10:27 AM, Paul Durrant wrote:
> > This should fix the problem for you:
>
>
> Yes, that doe
>>> On 18.05.16 at 14:53, wrote:
> On May 17, 2016 3:48 PM, Jan Beulich wrote:
>> >>> On 17.05.16 at 05:19, wrote:
>> >> From: Xu, Quan
>> >> Sent: Monday, May 16, 2016 11:26 PM
>> >>
>> >> On May 13, 2016 11:28 PM, Jan Beulich wrote:
>> >> > >>> On 22.04.16 at 12:54, wrote:
>> >> > > --- a/d
On Wed, May 18, 2016 at 03:45:22PM +0100, Ian Jackson wrote:
> Wei Liu writes ("Re: [PATCH v2 for-4.7 12/14] libxl: fix passing the type
> argument to xc_psr_*"):
> > On Thu, Apr 28, 2016 at 06:29:03PM +0100, Ian Jackson wrote:
> > > I'm very much against introducing casts which are not absolutely
A domain with a frontend that does not implement a control ring has been
seen to cause a crash during domain save. This was apparently because
the call to xenvif_deinit_hash() in xenvif_disconnect_ctrl() is made
regardless of whether a control ring was connected, and hence
xenvif_hash_init() was ca
On Wed, May 18, 2016 at 08:49:01AM -0600, Jan Beulich wrote:
> This in particular prevents updating guest IP when handling the retry
> needed to forward the memory access to qemu.
>
> Signed-off-by: Jan Beulich
Release-acked-by: Wei Liu
>
> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
> +++ b
>>> On 18.05.16 at 16:39, wrote:
> On 17.05.2016 17:34, Jan Beulich wrote:
>>> We use xenified kernels based on kernel 3.4 for years and benchmarks
>>> showed that they are faster than the pvops (vanilla) kernels.
>>> But what is the current state in terms of performance and features?
>> I'm not s
>>> On 18.05.16 at 16:41, wrote:
> On 13/05/16 10:32, Jan Beulich wrote:
>> Hi George,
>>
>> after quite a bit of debugging on 4.6.1 I learned that said commit
>> ("x86/P2M: consolidate handling of types not requiring a valid MFN")
>> is more than just cleanup: Since p2m_set_entry() happily perfo
On 05/18/2016 10:53 AM, Juergen Gross wrote:
> On 18/05/16 16:46, Boris Ostrovsky wrote:
>> On 05/18/2016 08:15 AM, Juergen Gross wrote:
>>> }
>>>
>>> +void __init xen_time_setup_guest(void)
>>> +{
>>> + pv_time_ops.steal_clock = xen_steal_clock;
>>> +
>>> + static_key_slow_inc(¶virt_steal_e
In commit 31268fea (libxl: fix passing the type argument to xc_psr_*),
casting to xc psr type was done at each call site.
This patch consolidates casting into a function to avoid casting at each
conversion point. Each call site remains more type safe.
Signed-off-by: Wei Liu
Acked-by: Ian Jackson
On Wed, May 18, 2016 at 03:55:42PM +0100, Paul Durrant wrote:
> A domain with a frontend that does not implement a control ring has been
> seen to cause a crash during domain save. This was apparently because
> the call to xenvif_deinit_hash() in xenvif_disconnect_ctrl() is made
> regardless of whe
On 18/05/16 17:25, Boris Ostrovsky wrote:
> On 05/18/2016 10:53 AM, Juergen Gross wrote:
>> On 18/05/16 16:46, Boris Ostrovsky wrote:
>>> On 05/18/2016 08:15 AM, Juergen Gross wrote:
}
+void __init xen_time_setup_guest(void)
+{
+ pv_time_ops.steal_clock = xen_steal_cloc
On 18/05/16 16:42, Juergen Gross wrote:
> On 18/05/16 17:25, Boris Ostrovsky wrote:
>> On 05/18/2016 10:53 AM, Juergen Gross wrote:
>>> On 18/05/16 16:46, Boris Ostrovsky wrote:
On 05/18/2016 08:15 AM, Juergen Gross wrote:
> }
>
> +void __init xen_time_setup_guest(void)
> +{
On 18/05/16 17:45, David Vrabel wrote:
> On 18/05/16 16:42, Juergen Gross wrote:
>> On 18/05/16 17:25, Boris Ostrovsky wrote:
>>> On 05/18/2016 10:53 AM, Juergen Gross wrote:
On 18/05/16 16:46, Boris Ostrovsky wrote:
> On 05/18/2016 08:15 AM, Juergen Gross wrote:
>> }
>>
>>
On 05/18/2016 11:45 AM, David Vrabel wrote:
> On 18/05/16 16:42, Juergen Gross wrote:
>> On 18/05/16 17:25, Boris Ostrovsky wrote:
>>> On 05/18/2016 10:53 AM, Juergen Gross wrote:
On 18/05/16 16:46, Boris Ostrovsky wrote:
> On 05/18/2016 08:15 AM, Juergen Gross wrote:
>> }
>>
>>
On 18/05/16 16:51, Juergen Gross wrote:
> On 18/05/16 17:45, David Vrabel wrote:
>> On 18/05/16 16:42, Juergen Gross wrote:
>>> On 18/05/16 17:25, Boris Ostrovsky wrote:
On 05/18/2016 10:53 AM, Juergen Gross wrote:
> On 18/05/16 16:46, Boris Ostrovsky wrote:
>> On 05/18/2016 08:15 AM,
On 18/05/16 17:53, Boris Ostrovsky wrote:
> On 05/18/2016 11:45 AM, David Vrabel wrote:
>> On 18/05/16 16:42, Juergen Gross wrote:
>>> On 18/05/16 17:25, Boris Ostrovsky wrote:
On 05/18/2016 10:53 AM, Juergen Gross wrote:
> On 18/05/16 16:46, Boris Ostrovsky wrote:
>> On 05/18/2016 08:
On Wed, May 18, 2016 at 8:57 AM, Dario Faggioli
wrote:
> On Wed, 2016-05-18 at 14:24 +0200, Juergen Gross wrote:
>> On 17/05/16 11:33, George Dunlap wrote:
>> > > Looks like CONFIG_PARAVIRT_TIME_ACCOUNTING is used for adjusting
>> > > process
>> > > times. KVM uses it but Xen doesn't.
>> > Is some
On Wed, 2016-05-18 at 16:53 +0200, Juergen Gross wrote:
> On 18/05/16 16:46, Boris Ostrovsky wrote:
> >
> > Won't we be accounting for stolen cycles twice now --- once from
> > steal_account_process_tick()->steal_clock() and second time from
> > do_stolen_accounting()?
> Uuh, yes.
>
> I guess I s
On 05/18/2016 12:00 PM, Juergen Gross wrote:
> On 18/05/16 17:53, Boris Ostrovsky wrote:
>> On 05/18/2016 11:45 AM, David Vrabel wrote:
>>> On 18/05/16 16:42, Juergen Gross wrote:
On 18/05/16 17:25, Boris Ostrovsky wrote:
> On 05/18/2016 10:53 AM, Juergen Gross wrote:
>> On 18/05/16 16
1 - 100 of 152 matches
Mail list logo
