[ Not relevant upstream, therefore no upstream commit. ]
To fix, use jiffies64_to_nsecs() directly instead of deriving the result
according to jiffies_to_usecs().
As the return type of jiffies_to_usecs() is 'unsigned int', when the return
value is more than the size of 'unsigned int', the
On 04/03/2019 21:47, Arnd Bergmann wrote:
> Building the privcmd code as a loadable module on ARM, we get
> a link error due to the private cache management functions:
>
> ERROR: "__sync_icache_dcache" [drivers/xen/xen-privcmd.ko] undefined!
>
> Move the code into a new file that is built along
Moving xen-devel to bcc and cc-ing win-pv-devel...
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf Of
> Steffen Einsle
> Sent: 04 March 2019 16:31
> To: xen-devel
> Subject: [Xen-devel] PV drivers 8.2.2. only testsigned?
>
> Hi there,
>
flight 133574 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133574/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemut-rhel6hvm-amd 12 guest-start/redhat.repeat fail REGR. vs.
129313
Tests which
flight 133573 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133573/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386-xl-xsm7 xen-boot fail pass in 133561
test-amd64-amd64-xl-shadow7
flight 133571 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133571/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-xsm 12 guest-start fail REGR. vs. 133555
> From: Paul Durrant [mailto:paul.durr...@citrix.com]
> Sent: Monday, March 4, 2019 4:44 PM
>
> > -Original Message-
> > From: Tian, Kevin [mailto:kevin.t...@intel.com]
> > Sent: 04 March 2019 03:01
> > To: Paul Durrant ; xen-devel (xen-
> de...@lists.xenproject.org) >
Hi Thomas,
On 3/2/19 7:43 AM, Thomas Gleixner wrote:
> On Thu, 28 Feb 2019, Dongli Zhang wrote:
>>
>> The root cause is that the return type of jiffies_to_usecs() is 'unsigned
>> int',
>> but not 'unsigned long'. As a result, the leading 32 bits are discarded.
>
> Errm. No. The root cause is
Hi Juergen,
On 3/4/19 4:14 PM, Juergen Gross wrote:
> On 01/03/2019 03:35, Dongli Zhang wrote:
>> This issue is only for stable 4.9.x (e.g., 4.9.160), while the root cause is
>> still in the lasted mainline kernel.
>>
>> This is obviated by new feature patch set ended with b672592f0221
>>
> Hi,
Hello,
> I??m using the NXP i.mx8qxp men board and want to create an Android domu on
> Xen,
> but this board doesn??t have IOMMU. Does anyone knows that can I passthrough
> GPU without IOMMU on it?
Device DMA-capable passthrough without IOMMU is not recommended as you would
undermine the
Hi Arnd,
On 2019-03-04 7:59 pm, Arnd Bergmann wrote:
This reverts commit b907e20508d0 ("swiotlb: remove SWIOTLB_MAP_ERROR"), which
introduced an overflow warning in configurations that have a larger
dma_addr_t than phys_addr_t:
In file included from include/linux/dma-direct.h:5,
Adding xen-devel to cc in case anyone there wants to comment on my latest
proposal...
On 2/20/19 5:20 PM, Jim Fehlig wrote:
There have been a few requests [1][2] to support Xen's max_grant_frames setting
in libvirt domXML, but I'm not quite sure how to model it. The documentation [3]
on this
On Mon, Mar 04, 2019 at 08:59:03PM +0100, Arnd Bergmann wrote:
> This reverts commit b907e20508d0 ("swiotlb: remove SWIOTLB_MAP_ERROR"), which
> introduced an overflow warning in configurations that have a larger
> dma_addr_t than phys_addr_t:
>
> In file included from
On Mon, Mar 4, 2019 at 10:19 PM Boris Ostrovsky
wrote:
>
> On 3/4/19 3:47 PM, Arnd Bergmann wrote:
> > Building the privcmd code as a loadable module on ARM, we get
> > a link error due to the private cache management functions:
> >
> > ERROR: "__sync_icache_dcache" [drivers/xen/xen-privcmd.ko]
On 3/4/19 3:47 PM, Arnd Bergmann wrote:
> Building the privcmd code as a loadable module on ARM, we get
> a link error due to the private cache management functions:
>
> ERROR: "__sync_icache_dcache" [drivers/xen/xen-privcmd.ko] undefined!
Can __sync_icache_dcache be exported in arm32, just like
The legacy hypercall handlers were originally added with
a comment explaining that "copying the argument structures in
HYPERVISOR_event_channel_op() and HYPERVISOR_physdev_op() into the local
variable is sufficiently safe" and only made sure to not write
past the end of the argument structure, the
Building the privcmd code as a loadable module on ARM, we get
a link error due to the private cache management functions:
ERROR: "__sync_icache_dcache" [drivers/xen/xen-privcmd.ko] undefined!
Move the code into a new file that is built along with privcmd.o
but is always built-in, even when the
This reverts commit b907e20508d0 ("swiotlb: remove SWIOTLB_MAP_ERROR"), which
introduced an overflow warning in configurations that have a larger
dma_addr_t than phys_addr_t:
In file included from include/linux/dma-direct.h:5,
from kernel/dma/swiotlb.c:23:
kernel/dma/swiotlb.c:
flight 133567 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133567/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-xsm 6 xen-install fail REGR. vs. 133555
flight 133572 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133572/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
freebsd 721f596ed864c16f2812e2ddf50329f051491b59
baseline version:
freebsd
On 04/03/2019 19:00, George Dunlap wrote:
> On 3/4/19 6:31 PM, Andrew Cooper wrote:
>> The issues are:
>> * dict.has_key() was completely removed in Py3
>> * dict.keys() is an iterable rather than list in Py3, so .sort() doesn't
>> work.
>> * list.sort(cmp=) was deprecated in Py2.4 and removed
This run is configured for baseline tests only.
flight 83700 xen-unstable real [real]
http://osstest.xensource.com/osstest/logs/83700/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64
On 3/4/19 6:31 PM, Andrew Cooper wrote:
> The issues are:
> * dict.has_key() was completely removed in Py3
> * dict.keys() is an iterable rather than list in Py3, so .sort() doesn't
> work.
> * list.sort(cmp=) was deprecated in Py2.4 and removed in Py3. Replace it
>with a key= sort
The issues are:
* dict.has_key() was completely removed in Py3
* dict.keys() is an iterable rather than list in Py3, so .sort() doesn't work.
* list.sort(cmp=) was deprecated in Py2.4 and removed in Py3. Replace it
with a key= sort instead.
This is all compatible with Py2.4 and later,
flight 133566 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133566/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt-pair 22 guest-migrate/src_host/dst_host fail REGR. vs.
132889
CC Paul
On Mon, Mar 04, 2019 at 05:31:09PM +0100, Steffen Einsle wrote:
> Hi there,
>
> after downloading the drivers from
> https://xenproject.org/windows-pv-drivers/ I discovered that the 8.2.2.
> driverset is only testsigned - making it difficult to install and use them.
> I understand that
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf Of
> Jan Beulich
> Sent: 25 February 2019 14:12
> To: Paul Durrant
> Cc: Stefano Stabellini ; Wei Liu
> ; Konrad Rzeszutek Wilk
> ; George Dunlap ; Andrew
> Cooper
> ; Ian Jackson ; Tim
>
On Mon, 2019-03-04 at 15:46 +, Wei Liu wrote:
> To me it is just a bit weird to guard with cur_depth -- if you really
> want to continue at all cost, why don't you make it really continue at
> all cost?
There isn't another early exit from the loop. It really does continue
at all costs.
The
Hi there,
after downloading the drivers from
https://xenproject.org/windows-pv-drivers/ I discovered that the 8.2.2.
driverset is only testsigned - making it difficult to install and use
them. I understand that signing is a complicated process and that
development build drivers are always
On Mon, Mar 4, 2019 at 9:01 AM George Dunlap wrote:
>
> On 2/19/19 11:48 AM, Razvan Cojocaru wrote:
> > On 2/12/19 7:01 PM, Tamas K Lengyel wrote:
> >> On Thu, Feb 7, 2019 at 9:06 AM Petre Ovidiu PIRCALABU
> >> wrote:
> >>>
> >>> On Thu, 2019-02-07 at 11:46 +, George Dunlap wrote:
> On
On Mon, Mar 04, 2019 at 05:17:06PM +0100, Olaf Hering wrote:
> Am Mon, 4 Mar 2019 14:54:01 +
> schrieb Wei Liu :
>
> > > > +/* Prepare environment for domcreate_stream_done */
> > > > +dcs->srs.ao = ao;
> > > > +dcs->srs.dcs = dcs;
> > > > +dcs->srs.fd = -1;
> > As far as I
Am Mon, 4 Mar 2019 14:54:01 +
schrieb Wei Liu :
> > > +/* Prepare environment for domcreate_stream_done */
> > > +dcs->srs.ao = ao;
> > > +dcs->srs.dcs = dcs;
> > > +dcs->srs.fd = -1;
> As far as I can tell only srs.dcs needs to be initialised before hand.
fd needs to be
On 2/19/19 11:48 AM, Razvan Cojocaru wrote:
> On 2/12/19 7:01 PM, Tamas K Lengyel wrote:
>> On Thu, Feb 7, 2019 at 9:06 AM Petre Ovidiu PIRCALABU
>> wrote:
>>>
>>> On Thu, 2019-02-07 at 11:46 +, George Dunlap wrote:
On 2/6/19 2:26 PM, Petre Ovidiu PIRCALABU wrote:
> On Wed,
On Mon, Mar 04, 2019 at 03:10:34PM +, David Woodhouse wrote:
> On Mon, 2019-03-04 at 15:51 +0100, Juergen Gross wrote:
> > On 04/03/2019 15:31, David Woodhouse wrote:
> > > On Mon, 2019-03-04 at 14:18 +, Wei Liu wrote:
> > > > CC Ian as well.
> > > >
> > > > It would be better if you run
Hi all,
Xen 4.12 rc4 is tagged. You can check that out from xen.git:
git://xenbits.xen.org/xen.git 4.12.0-rc4
For your convenience there is also a tarball at:
https://downloads.xenproject.org/release/xen/4.12.0-rc4/xen-4.12.0-rc4.tar.gz
And the signature is at:
On 04/03/2019 16:10, David Woodhouse wrote:
> On Mon, 2019-03-04 at 15:51 +0100, Juergen Gross wrote:
>> On 04/03/2019 15:31, David Woodhouse wrote:
>>> On Mon, 2019-03-04 at 14:18 +, Wei Liu wrote:
CC Ian as well.
It would be better if you run ./scripts/get_maintainers.pl on
On Mon, 2019-03-04 at 15:51 +0100, Juergen Gross wrote:
> On 04/03/2019 15:31, David Woodhouse wrote:
> > On Mon, 2019-03-04 at 14:18 +, Wei Liu wrote:
> > > CC Ian as well.
> > >
> > > It would be better if you run ./scripts/get_maintainers.pl on
> > > your
> > > patches in the future to CC
On Thu, Feb 28, 2019 at 05:40:18PM +, George Dunlap wrote:
> You'll get a better response rate if you actually cc' the tools maintainers.
> -G
>
> On Thu, Feb 28, 2019 at 4:22 PM Olaf Hering wrote:
> >
> > Am Thu, 28 Feb 2019 14:17:18 +0100
> > schrieb Olaf Hering :
> >
> > > In
On 04/03/2019 15:31, David Woodhouse wrote:
> On Mon, 2019-03-04 at 14:18 +, Wei Liu wrote:
>> CC Ian as well.
>>
>> It would be better if you run ./scripts/get_maintainers.pl on your
>> patches in the future to CC the correct people.
>
> Will do; thanks.
>
>> On Fri, Mar 01, 2019 at
On Mon, 2019-03-04 at 14:18 +, Wei Liu wrote:
> CC Ian as well.
>
> It would be better if you run ./scripts/get_maintainers.pl on your
> patches in the future to CC the correct people.
Will do; thanks.
> On Fri, Mar 01, 2019 at 12:16:56PM +, David Woodhouse wrote:
> > From: David
CC Ian as well.
It would be better if you run ./scripts/get_maintainers.pl on your
patches in the future to CC the correct people.
On Fri, Mar 01, 2019 at 12:16:56PM +, David Woodhouse wrote:
> From: David Woodhouse
>
> When recursing, a node sometimes disappears. Deal with it and move on
On 04/03/2019 10:31, Andy Shevchenko wrote:
> Switch to bitmap_zalloc() to show clearly what we are allocating.
> Besides that it returns pointer of bitmap type instead of opaque void *.
>
> Signed-off-by: Andy Shevchenko
Reviewed-by: Juergen Gross
Juergen
Julien Grall writes ("Re: [PATCH for-4.12 RFC] xen/console: Handle NUL
character in buffer sent via CONSOLEIO_write"):
> On 04/03/2019 11:21, George Dunlap wrote:
> > zsh is sending a NUL character to the console in the middle of the
> > buffer? Why would it do that? Is that defined behavior,
Hi,
On 04/03/2019 11:21, George Dunlap wrote:
On 3/1/19 10:59 PM, Daniel De Graaf wrote:
On 2/27/19 1:45 PM, Julien Grall wrote:
Hi Wei,
On 2/27/19 12:55 PM, Wei Liu wrote:
On Tue, Feb 26, 2019 at 11:03:51PM +, Julien Grall wrote:
After upgrading Debian to Buster, I started noticing
flight 83699 distros-debian-sid real [real]
http://osstest.xensource.com/osstest/logs/83699/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvopsbroken
build-i386
On 3/1/19 10:59 PM, Daniel De Graaf wrote:
> On 2/27/19 1:45 PM, Julien Grall wrote:
>> Hi Wei,
>>
>> On 2/27/19 12:55 PM, Wei Liu wrote:
>>> On Tue, Feb 26, 2019 at 11:03:51PM +, Julien Grall wrote:
After upgrading Debian to Buster, I started noticing console mangling
when using
On 03/03/2019 12:38, Jinch wrote:
Hi,
Hello,
I’m using the NXP i.mx8qxp men board and want to create an Android domu
on Xen,
but this board doesn’t have IOMMU. Does anyone knows that can I
passthrough GPU without IOMMU on it?
Device DMA-capable passthrough without IOMMU
>>> Roger Pau Monné 03/04/19 11:19 AM >>>
>On Sun, Mar 03, 2019 at 02:10:24AM +0100, Marek Marczykowski wrote:
>> On Thu, Feb 28, 2019 at 01:25:50PM +0100, Marek Marczykowski wrote:
>> > On Thu, Feb 28, 2019 at 03:58:37AM -0700, Jan Beulich wrote:
>> > > Another thing: You're also bypassing the
On Sun, Mar 03, 2019 at 02:10:24AM +0100, Marek Marczykowski wrote:
> On Thu, Feb 28, 2019 at 01:25:50PM +0100, Marek Marczykowski wrote:
> > On Thu, Feb 28, 2019 at 03:58:37AM -0700, Jan Beulich wrote:
> > > Another thing: You're also bypassing the MSI{,-X}-already-enabled
> > > checks that
flight 133563 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133563/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemut-rhel6hvm-amd 12 guest-start/redhat.repeat fail REGR. vs.
129313
Regressions
>>> George Dunlap 03/01/19 6:39 PM >>>
>On 3/1/19 5:12 PM, Jan Beulich wrote:
> George Dunlap 02/28/19 7:50 PM >>>
>>> +* Programmers can use ASSERT(), which will cause the check to be
>>> +executed in DEBUG builds, and cause the hypervisor to crash if it's
>>> +violated
>>
>> Is it perhaps
flight 133561 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133561/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 133282
Switch to bitmap_zalloc() to show clearly what we are allocating.
Besides that it returns pointer of bitmap type instead of opaque void *.
Signed-off-by: Andy Shevchenko
---
- added one more missed conversion
drivers/xen/xen-acpi-processor.c | 22 +++---
1 file changed, 11
Switch to bitmap_zalloc() to show clearly what we are allocating.
Besides that it returns pointer of bitmap type instead of opaque void *.
Signed-off-by: Andy Shevchenko
---
drivers/xen/xen-acpi-processor.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git
> -Original Message-
> From: Tian, Kevin [mailto:kevin.t...@intel.com]
> Sent: 04 March 2019 03:01
> To: Paul Durrant ; xen-devel
> (xen-devel@lists.xenproject.org) de...@lists.xenproject.org>
> Subject: RE: standalone PCI passthrough emulator
>
> > From: Paul Durrant
> > Sent:
On 03/03/2019 14:58, osstest service owner wrote:
> flight 133517 xen-unstable real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/133517/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-armhf-armhf-xl 5
On 2/28/19 11:00, Jan Beulich wrote:
On 27.02.19 at 14:01, wrote:
>> On 2/25/19 17:46, Jan Beulich wrote:
>>> I would really like to ask that I (or someone else) don't need to
>>> go through and list remaining version checks again - after all I
>>> had done so for v6 already, and I didn't go
On 01/03/2019 03:35, Dongli Zhang wrote:
> This issue is only for stable 4.9.x (e.g., 4.9.160), while the root cause is
> still in the lasted mainline kernel.
>
> This is obviated by new feature patch set ended with b672592f0221
> ("sched/cputime: Remove generic asm headers").
>
> After xen
58 matches
Mail list logo
