On 11/05/2017 03:44, Bhupinder Thakur wrote:
Hi Julien,
Hi Bhupinder,
I will resend the series keeping you and Stefano in cc.
No need to series your series :).
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https:/
flight 109300 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109300/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf ef810bc807188224a752ffbcf5e7f4b651291cee
baseline version:
ovmf bcd999d2377d1a34bb3b5
flight 109269 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109269/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-winxpsp3 16 guest-stop fail REGR. vs. 109165
Tests which did no
flight 109297 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109297/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 5 xen-buildfail REGR. vs. 107636
build-arm64
On 09/05/2017 21:04, Stefano Stabellini wrote:
> Assert that the return value is not an error. This issue was found by
> Coverity.
>
> CID: 1374831
>
> Signed-off-by: Stefano Stabellini
> CC: gr...@kaod.org
> CC: pbonz...@redhat.com
> CC: Eric Blake
Queued, thanks.
Paolo
> ---
> util/osli
>>> On 11.05.17 at 06:10, wrote:
> On Wed, May 10, 2017 at 04:47:49PM +0100, Wei Liu wrote:
>> On Wed, May 10, 2017 at 04:39:32PM +0100, Wei Liu wrote:
>> > On Wed, May 10, 2017 at 08:29:35AM -0600, Charles Arnold wrote:
>> > > I was asked the following question which I am posting to the list.
>>
On Wed, May 10, 2017 at 05:29:12PM +0100, Wei Liu wrote:
> On Wed, May 10, 2017 at 11:12:39AM +0100, Roger Pau Monne wrote:
> > Current code in backend_watch_callback forgets to remove a
> > libxl__ddomain_guest
> > from the list of tracked domains when the related data is freed, causing
> > deref
flight 71286 distros-debian-wheezy real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71286/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
build-arm64 2 hosts-allocate broken never pass
build-arm64-pvops
On 10/05/17 18:49, Gustavo A. R. Silva wrote:
>
> Hello everybody,
>
> While looking into Coverity ID 1350942 I ran into the following piece of
> code at drivers/block/xen-blkback/xenbus.c:490:
>
> 490static int xen_blkbk_remove(struct xenbus_device *dev)
> 491{
> 492struct backend_info
On Thu, May 11, 2017 at 06:14:42PM +1000, Jan Beulich wrote:
> >>> On 11.05.17 at 06:10, wrote:
> > On Wed, May 10, 2017 at 04:47:49PM +0100, Wei Liu wrote:
> >> On Wed, May 10, 2017 at 04:39:32PM +0100, Wei Liu wrote:
> >> > On Wed, May 10, 2017 at 08:29:35AM -0600, Charles Arnold wrote:
> >> > >
This run is configured for baseline tests only.
flight 71287 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71287/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
build-amd64-libvirt 5 libvirt-buildfai
Hello,
On 10/05/17 20:04, Julien Grall wrote:
On 05/10/2017 06:37 PM, Volodymyr Babchuk wrote:
Hi Julien,
Hi Volodymyr,
Returning back to Native apps, I think we can make ctx switch even
faster by dropping p2m code. Imagine that we already created stage 1
MMU for native application. Then to
On 05/05/17 15:48, Wei Liu wrote:
> Move the following emulation code from traps.c:
>
> 1. invalid op
> 2. rdtsc
> 3. privilege instructions
> 4. gate operation
> 5. pv cpuid emulation
>
> Export the emulate_* functions via pv/traps.h.
>
> No functional change.
>
> Signed-off-by: Wei Liu
As you a
On Fri, 2017-04-14 at 11:37 -0400, Boris Ostrovsky wrote:
> Instead of scrubbing pages during guest destruction (from
> free_heap_pages()) do this opportunistically, from the idle loop.
>
> Signed-off-by: Boris Ostrovsky
> ---
> Changes in v3:
> * If memory-only nodes exist, select the closest on
flight 109308 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109308/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf a6c31c6d6349a51041d8b77df375c340043e36bd
baseline version:
ovmf ef810bc807188224a752f
On 27/04/17 07:01, Juergen Gross wrote:
> When running as Xen pv guest X86_BUG_SYSRET_SS_ATTRS must not be set
> on AMD cpus.
>
> This bug/feature bit is kind of special as it will be used very early
> when switching threads. Setting the bit and clearing it a little bit
> later leaves a critical w
On Fri, Apr 28, 2017 at 09:31:14PM +0530, Bhupinder Thakur wrote:
>
> url: ssh://g...@git.linaro.org:/people/bhupinder.thakur/xen.git
I'm not sure if a ssh:// url is helpful...
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xe
On Fri, May 05, 2017 at 02:43:40PM +0100, Julien Grall wrote:
> On 05/05/17 08:10, Bhupinder Thakur wrote:
> > Hi Julien,
>
> Hi Bhupinder,
>
> > > > > Hi Jan,
> > > > >
> > > > > > > @@ -631,6 +632,9 @@ int arch_domain_create(struct domain *d,
> > > > > > > unsigned int domcr_flags,
> > > > > >
Commit 6d774a951696 ("x86/ioreq server: synchronously reset outstanding
p2m_ioreq_server entries when an ioreq server unmaps") introduced
p2m_finish_type_change(), which was meant to synchronously finish a
previously initiated type change over a gpfn range. It did this by
calling get_entry(), chec
On 10/05/17 16:11, Andre Przywara wrote:
Hi,
Hi Andre,
On 12/04/17 18:20, Julien Grall wrote:
On 12/04/17 01:44, Andre Przywara wrote:
+{
+ASSERT(spin_is_locked(&v->arch.vgic.lock));
The locking is likely to wrong here too (see patch #2). For instance
with a MOVI then INV on interr
On Thu, May 11, 2017 at 09:24:40AM +0100, Roger Pau Monne wrote:
> On Wed, May 10, 2017 at 05:29:12PM +0100, Wei Liu wrote:
> > On Wed, May 10, 2017 at 11:12:39AM +0100, Roger Pau Monne wrote:
> > > Current code in backend_watch_callback forgets to remove a
> > > libxl__ddomain_guest
> > > from th
Current code can free the libxl__device inside of the libxl__ddomain_device
before the addition has finished if a removal happens while an addition is
still in process:
backend_watch_callback
|
v
add_device
| backend_watch_callback
(
Current code in backend_watch_callback has two issues when manipulating the
dguest list:
1. backend_watch_callback forgets to remove a libxl__ddomain_guest from the
list of tracked domains when the related data is freed, causing dereferences
later on when the list is traversed. Make sure that a do
Hello,
The following two patches fix a race with concurrent device addition/removal
and two bugs related to manipulation of the list of active domains in the devd
subcommand.
IMHO they should be part of 4.9 because they are confined to devd code, and
without them devd is unusable (it's trivial to
On Wed, May 10, 2017 at 08:01:18PM +0530, Bhupinder Thakur wrote:
> Add two new domctl APIs to initialize and de-initialize vpl011. It takes the
> GFN and console
> backend domid as input and returns an event channel to be used for
> sending and receiving events from Xen.
>
> Xen will communicate
Roger Pau Monne writes ("[PATCH v2 1/2] libxl/devd: fix a race with concurrent
device addition/removal"):
> Current code can free the libxl__device inside of the libxl__ddomain_device
> before the addition has finished if a removal happens while an addition is
> still in process:
...
> Fix this by
On Wed, May 10, 2017 at 08:05:12PM +0530, Bhupinder Thakur wrote:
> libxl__device_console_add(gc, domid, &console, state, &device);
> @@ -1369,14 +1377,22 @@ static void domcreate_launch_dm(libxl__egc *egc,
> libxl__multidev *multidev,
> }
> case LIBXL_DOMAIN_TYPE_PV:
> {
>
On Wed, May 10, 2017 at 08:05:13PM +0530, Bhupinder Thakur wrote:
> Allocate a new gfn to be used as a ring buffer between xenconsole
> and Xen for sending/receiving pl011 data.
>
> Signed-off-by: Bhupinder Thakur
Acked-by: Wei Liu
___
Xen-devel mail
>>> On 12.05.17 at 04:42, wrote:
> Commit 6d774a951696 ("x86/ioreq server: synchronously reset outstanding
> p2m_ioreq_server entries when an ioreq server unmaps") introduced
> p2m_finish_type_change(), which was meant to synchronously finish a
> previously initiated type change over a gpfn range.
Roger Pau Monne writes ("[PATCH v2 2/2] libxl/devd: correctly manipulate the
dguest list"):
> Current code in backend_watch_callback has two issues when manipulating the
> dguest list:
...
> skip:
> libxl__nested_ao_free(nested_ao);
> +clean:
> if (ddev)
> free(ddev->dev);
Thi
On Wed, May 10, 2017 at 08:05:14PM +0530, Bhupinder Thakur wrote:
> Xenconsole supports only PV console currently. This patch adds support
> for supporting multiple consoles.
>
> This patch modifies different data structures and APIs used
> in xenconsole to support multiple consoles.
>
> Change s
On Wed, May 10, 2017 at 08:05:15PM +0530, Bhupinder Thakur wrote:
> Xenconsole supports only PV console currently. This patch adds support
> for vuart console, which allows emulated pl011 UART to be accessed
> as a console.
>
> Signed-off-by: Bhupinder Thakur
> ---
>
> One review comment was to
On Wed, May 10, 2017 at 08:05:16PM +0530, Bhupinder Thakur wrote:
> Add a new console type VUART to connect to guest's emualated vuart
> console.
>
> Signed-off-by: Bhupinder Thakur
> ---
> tools/console/client/main.c | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git
On Wed, May 10, 2017 at 08:05:17PM +0530, Bhupinder Thakur wrote:
> The SBSA uart node format is as specified in
> Documentation/devicetree/bindings/serial/arm_sbsa_uart.txt and given below:
>
> ARM SBSA defined generic UART
> --
> This UART uses a subset of the PL011 r
On Wed, May 10, 2017 at 07:58:01PM +0530, Bhupinder Thakur wrote:
> diff --git a/tools/xl/xl_parse.c b/tools/xl/xl_parse.c
> index 856a304..504ca7c 100644
> --- a/tools/xl/xl_parse.c
> +++ b/tools/xl/xl_parse.c
> @@ -916,6 +916,14 @@ void parse_config_data(const char *config_source,
> if (!xlu
On Wed, May 10, 2017 at 08:05:18PM +0530, Bhupinder Thakur wrote:
> 1. Update documentation for a new vuart option added.
> 2. Update documentation about SPI irq reserved for vpl011.
>
> Signed-off-by: Bhupinder Thakur
Acked-by: Wei Liu
___
Xen-devel
Please can you fold this following delta?
---
xen/arch/x86/pv/emulate_ops.c | 101 +-
1 file changed, 51 insertions(+), 50 deletions(-)
diff --git a/xen/arch/x86/pv/emulate_ops.c b/xen/arch/x86/pv/emulate_ops.c
index 97c8d14..9341dec 100644
--- a/xen/arch/x
Hi Oleksandr,
On 10/05/17 15:03, Oleksandr Tyshchenko wrote:
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_p
Hi Oleksandr,
On 10/05/17 15:03, Oleksandr Tyshchenko wrote:
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 t
Hi Julien,
On 11 May 2017 at 13:07, Julien Grall wrote:
> Looking again at the documentation and chatting with other ARM folks. I was
> wrong on some part, sorry for the confusion.
Thank you for this investigation. One can't fit whole ARMv8 TRM in one's head :)
> It turns out that if you don't
On Thu, May 11, 2017 at 02:04:09PM +0800, Chao Gao wrote:
> This number is used to calculate how many hvm vcpu on a pcpu on average.
>
> Signed-off-by: Chao Gao
> ---
> xen/common/domain.c | 8
> xen/include/xen/sched.h | 2 ++
> 2 files changed, 10 insertions(+)
>
> diff --git a/x
On Thu, May 11, 2017 at 12:35:11PM +0100, Wei Liu wrote:
> On Thu, May 11, 2017 at 02:04:09PM +0800, Chao Gao wrote:
> > This number is used to calculate how many hvm vcpu on a pcpu on average.
> >
> > Signed-off-by: Chao Gao
> > ---
> > xen/common/domain.c | 8
> > xen/include/xen/
Hi Oleksandr,
On 10/05/17 15:03, Oleksandr Tyshchenko wrote:
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 non-shared IOMMUs have to perform all required actions here
to be ready to handle IOMMU
On Thu, May 11, 2017 at 12:13:00PM +0100, Ian Jackson wrote:
> Roger Pau Monne writes ("[PATCH v2 2/2] libxl/devd: correctly manipulate the
> dguest list"):
> > Current code in backend_watch_callback has two issues when manipulating the
> > dguest list:
> ...
> > skip:
> > libxl__nested_ao_f
Hi Thomas and all,
Apologize for being an unqualified maintainer.
> -Original Message-
> From: Thomas Monjalon [mailto:tho...@monjalon.net]
> Sent: Friday, May 5, 2017 6:04 AM
> To: Joao Martins; Konrad Rzeszutek Wilk; Tan, Jianfeng
> Cc: Konrad Rzeszutek Wilk; d...@dpdk.org; Xen-devel
>
Hi Oleksandr,
On 10/05/17 15:03, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
This flag is intended to let Xen know that the guest has devices
which will most likely be used for passthrough and as the result
the use of IOMMU is expected for this domain.
The primary aim of this knowle
On Thu, May 11, 2017 at 12:06:08PM +0100, Ian Jackson wrote:
> Roger Pau Monne writes ("[PATCH v2 1/2] libxl/devd: fix a race with
> concurrent device addition/removal"):
> > Current code can free the libxl__device inside of the libxl__ddomain_device
> > before the addition has finished if a remov
Unavoidable crashes in netfront_resume() and netback_changed() after a
previous fail in talk_to_netback() (e.g. when we fail to read MAC from
xenstore) were discovered. The failure path in talk_to_netback() does
unregister/free for netdev but we don't reset drvdata and we try accessing
it after res
Hi Oleksandr,
On 10/05/17 15:03, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
We don't passthrough IOMMU device to DOM0 even if it is not used by
Xen. Therefore exposing the property that describes the IOMMU
master interfaces of the device does not make any sense.
Signed-off-by: Ole
On Mon, May 08, 2017 at 07:12:13AM +0200, Juergen Gross wrote:
> Revert commit 72a9b186292 ("xen: Remove event channel notification
> through Xen PCI platform device") as the original analysis was wrong
> that all the removed code isn't in use any more. As commit da72ff5bfcb0
> ("partially revert x
On Mon, May 08, 2017 at 08:12:47AM +0200, Juergen Gross wrote:
> Revert commit 72a9b186292 ("xen: Remove event channel notification
> through Xen PCI platform device") as the original analysis was wrong
> that all the removed code isn't in use any more. As commit da72ff5bfcb0
> ("partially revert x
On Mon, May 08, 2017 at 07:11:56AM +0200, Juergen Gross wrote:
> Revert commit 72a9b186292 ("xen: Remove event channel notification
> through Xen PCI platform device") as the original analysis was wrong
> that all the removed code isn't in use any more.
>
> It is still necessary for old Xen versio
On 12/04/17 15:44, Ian Jackson wrote:
> Greg KH writes ("Re: Please apply "partially revert "xen: Remove event
> channel...""):
>> On Wed, Apr 12, 2017 at 03:26:53PM +0200, Juergen Gross wrote:
>>> On 12/04/17 15:13, Greg KH wrote:
Is this still true? This long thread is totally confusing, i
On Mon, Apr 17, 2017 at 08:01:56PM +0800, Lan Tianyu wrote:
> On 2017年04月17日 19:08, Wei Liu wrote:
> > On Fri, Apr 14, 2017 at 11:38:15PM +0800, Lan, Tianyu wrote:
> >> Hi Paul:
> >>Sorry for later response.
> >>
> >> On 3/31/2017 3:57 AM, Chao Gao wrote:
> >>> On Wed, Mar 29, 2017 at 09:08:06A
On Wed, May 03, 2017 at 04:44:20PM +0800, Yi Sun wrote:
> This patch implements xl/xc changes to support get HW info
> for L2 CAT.
>
> 'xl psr-hwinfo' is updated to show both L3 CAT and L2 CAT
> info.
>
> Example(on machine which only supports L2 CAT):
> Cache Monitoring Technology (CMT):
> Enabl
On Wed, May 03, 2017 at 04:44:21PM +0800, Yi Sun wrote:
> This patch implements changes in xl/xc changes to support
> showing CBM of L2 CAT.
>
> The new level option is introduced to original CAT showing
> command in order to show CBM for specified level CAT.
> - 'xl psr-cat-show' is updated to sh
On 2017年05月11日 20:35, Wei Liu wrote:
> On Mon, Apr 17, 2017 at 08:01:56PM +0800, Lan Tianyu wrote:
>> On 2017年04月17日 19:08, Wei Liu wrote:
>>> On Fri, Apr 14, 2017 at 11:38:15PM +0800, Lan, Tianyu wrote:
Hi Paul:
Sorry for later response.
On 3/31/2017 3:57 AM, Chao Gao wrote:
This run is configured for baseline tests only.
flight 71288 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71288/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
build-amd64-libvirt 5 libvirt-buildfai
On Wed, May 03, 2017 at 04:44:22PM +0800, Yi Sun wrote:
> This patch implements the xl/xc changes to support set CBM
> for L2 CAT.
>
> The new level option is introduced to original CAT setting
> command in order to set CBM for specified level CAT.
> - 'xl psr-cat-set' is updated to set cache capa
On Thu, 11 May 2017, Juergen Gross wrote:
> On 27/04/17 07:01, Juergen Gross wrote:
> > When running as Xen pv guest X86_BUG_SYSRET_SS_ATTRS must not be set
> > on AMD cpus.
> >
> > This bug/feature bit is kind of special as it will be used very early
> > when switching threads. Setting the bit a
That function can return a whole slew of error codes. Translate them
to EXIT_FAILURE.
Signed-off-by: Wei Liu
---
Cc: Ian Jackson
Cc: Julien Grall
Cc: Roger Pau Monn??
---
tools/xl/xl_misc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/xl/xl_misc.c b/tools/xl/xl_m
flight 109292 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109292/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemuu-rhel6hvm-intel 6 xen-boot fail REGR. vs. 59254
test-amd64-amd64-xl
On 09/05/17 17:02, Jan Beulich wrote:
On 09.05.17 at 17:33, wrote:
>> On 09/05/17 17:32, Jan Beulich wrote:
>> On 09.05.17 at 17:25, wrote:
On 09/05/17 17:06, Jan Beulich wrote:
On 09.05.17 at 16:36, wrote:
>> On 09/05/17 16:23, Jan Beulich wrote:
>>> Since PV kern
On 09/05/17 16:23, Jan Beulich wrote:
On 09.05.17 at 17:10, wrote:
>> On 09/05/17 15:23, Jan Beulich wrote:
>>> Since PV kernels can't use large pages anywa, when the init-P2M support
>> anyway
> Already fixed after Alan pointed this out. Do I need to send v2
> because of this typo?
No. Ack
flight 109312 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109312/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 29dc8aa861fac78c6d62391dff312db934b755e3
baseline version:
ovmf a6c31c6d6349a51041d8b
On Thu, May 11, 2017 at 2:38 PM, Julien Grall wrote:
> Hi Oleksandr,
Hi, Julien
>
> On 10/05/17 15:03, Oleksandr Tyshchenko wrote:
>>
>> 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 n
flight 109296 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109296/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-credit2 6 xen-boot fail REGR. vs. 107358
Tests which are faili
On Thu, May 11, 2017 at 2:42 PM, Julien Grall wrote:
> Hi Oleksandr,
Hi Julien
>
>
> On 10/05/17 15:03, Oleksandr Tyshchenko wrote:
>>
>> From: Oleksandr Tyshchenko
>>
>> This flag is intended to let Xen know that the guest has devices
>> which will most likely be used for passthrough and as the
4.11-stable review patch. If anyone has any objections, please let me know.
--
From: Boris Ostrovsky
commit 84d582d236dc1f9085e741affc72e9ba061a67c2 upstream.
Recent discussion (http://marc.info/?l=xen-devel&m=149192184523741)
established that commit 72a9b186292d ("xen: Remove
On Thu, May 11, 2017 at 01:57:19PM +0100, Wei Liu wrote:
> That function can return a whole slew of error codes. Translate them
> to EXIT_FAILURE.
>
> Signed-off-by: Wei Liu
Acked-by: Roger Pau Monné
___
Xen-devel mailing list
Xen-devel@lists.xen.or
On Thu, May 11, 2017 at 2:58 PM, Julien Grall wrote:
> Hi Oleksandr,
Hi Julien
>
> On 10/05/17 15:03, Oleksandr Tyshchenko wrote:
>>
>> From: Oleksandr Tyshchenko
>>
>> We don't passthrough IOMMU device to DOM0 even if it is not used by
>> Xen. Therefore exposing the property that describes the
4.10-stable review patch. If anyone has any objections, please let me know.
--
From: Boris Ostrovsky
commit 84d582d236dc1f9085e741affc72e9ba061a67c2 upstream.
Recent discussion (http://marc.info/?l=xen-devel&m=149192184523741)
established that commit 72a9b186292d ("xen: Remove
On Thu, May 11, 2017 at 2:24 PM, Julien Grall wrote:
> Hi Oleksandr,
Hi Julien
>
> On 10/05/17 15:03, Oleksandr Tyshchenko wrote:
>>
>> 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()
>> diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
>> index 90e2b1f..a5f62b5 100644
>> --- a/xen/arch/x86/domain.c
>> +++ b/xen/arch/x86/domain.c
>> @@ -118,7 +118,8 @@ static void idle_loop(void)
>> {
>> if ( cpu_is_offline(smp_processor_id()) )
>> play_dead(
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Boris Ostrovsky
commit 84d582d236dc1f9085e741affc72e9ba061a67c2 upstream.
Recent discussion (http://marc.info/?l=xen-devel&m=149192184523741)
established that commit 72a9b186292d ("xen: Remove
Hi Vladimir,
On 11 May 2017 at 06:01, Vladimir 'phcoder' Serbinenko
wrote:
>
>
> On Tue, May 9, 2017, 11:02 Fu Wei wrote:
>>
>> Hi Vladimir
>>
>> On 9 May 2017 at 14:59, Vladimir 'phcoder' Serbinenko
>> wrote:
>> >
>> >
>> > Le Tue, May 2, 2017 à 9:06 AM, a écrit :
>> >>
>> >> From: Fu Wei
>>
Greetings,
My co-worker and I are looking into Xen Hypervisor. By any chance, do you or
any of your colleagues have technical material/ papers/ presentations detailing
how the hypercall interacts with the hypervisor?
Thank you in advance for any assistance,
- Rapidash
Some specific questions:
On Thu, May 11, 2017 at 2:28 PM, Julien Grall wrote:
> Hi Oleksandr,
Hi Julien
>
> On 10/05/17 15:03, Oleksandr Tyshchenko wrote:
>>
>> 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 alw
Ian Jackson writes ("Proposal to drop Windows XP tests from Xen Project CI"):
> Recently, the tests of Windows XP SP3 that are run by osstest, as part
> of the Xen Project's test suite, have started failing a lot more.
>
> It is not clear what has caused this. The failures are causing
> blockages
flight 109301 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109301/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail like 109246
test-armhf-armhf-libvirt 13 saveresto
Hi Juergen,
Quoting Juergen Gross :
On 10/05/17 18:49, Gustavo A. R. Silva wrote:
Hello everybody,
While looking into Coverity ID 1350942 I ran into the following piece of
code at drivers/block/xen-blkback/xenbus.c:490:
490static int xen_blkbk_remove(struct xenbus_device *dev)
491{
492
Hi Stefano,
On 10 May 2017 at 21:24, Stefano Stabellini wrote:
> I just want to point out that the comparision with tasklets is not
> helpful. Tasklets involve the idle vcpu, which we are trying to step away
> from because it increases irq latency. Tasklets don't provide any
> isolation. The cont
Add null check before calling xen_blkif_put() to avoid potential
null pointer dereference.
Addresses-Coverity-ID: 1350942
Cc: Juergen Gross
Signed-off-by: Gustavo A. R. Silva
---
drivers/block/xen-blkback/xenbus.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drive
Renaming the subject + adding more people in the conversation as this is
not related to only ARM anymore.
On 11/05/17 16:19, Volodymyr Babchuk wrote:
Hi Stefano,
On 10 May 2017 at 21:24, Stefano Stabellini wrote:
I just want to point out that the comparision with tasklets is not
helpful. Tas
This run is configured for baseline tests only.
flight 71289 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71289/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
build-amd64-libvirt 5 libvirt-buildfai
On Thu, 2017-05-11 at 10:19 -0400, Boris Ostrovsky wrote:
> > > diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
> > > index 90e2b1f..a5f62b5 100644
> > > --- a/xen/arch/x86/domain.c
> > > +++ b/xen/arch/x86/domain.c
> > > @@ -118,7 +118,8 @@ static void idle_loop(void)
> > > {
> > >
flight 109310 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109310/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 5 xen-buildfail REGR. vs. 107636
build-arm64
Wei Liu writes ("[PATCH for-4.9] xl: don't ignore return value from
libxl_device_events_handler"):
> That function can return a whole slew of error codes. Translate them
> to EXIT_FAILURE.
Acked-by: Ian Jackson
___
Xen-devel mailing list
Xen-devel@lis
The Requires line in this config file uses the wrong names for two dependencies.
The package config file for xenctrl is called 'xencontrol' and for blktapctl is
called 'xenblktapctl'. Running a command like 'pkg-config --exists xenlight'
will
fail without this fix.
Signed-off-by: Charles Arnold
On Thu, May 11, 2017 at 10:29:42AM -0600, Charles Arnold wrote:
> The Requires line in this config file uses the wrong names for two
> dependencies.
>
> The package config file for xenctrl is called 'xencontrol' and for blktapctl
> is
> called 'xenblktapctl'. Running a command like 'pkg-config -
On 11/05/17 16:35, Julien Grall wrote:
> On 11/05/17 16:19, Volodymyr Babchuk wrote:
>> Hi Stefano,
>>
>> On 10 May 2017 at 21:24, Stefano Stabellini
>> wrote:
>>> I just want to point out that the comparision with tasklets is not
>>> helpful. Tasklets involve the idle vcpu, which we are trying to
flight 109316 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109316/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf f4ac4354652b2bcf4f138b5ebd79b2f07710d4ef
baseline version:
ovmf 29dc8aa861fac78c6d623
On 05/11/2017 11:48 AM, Dario Faggioli wrote:
> On Thu, 2017-05-11 at 10:19 -0400, Boris Ostrovsky wrote:
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 90e2b1f..a5f62b5 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -118,7 +118,8 @@ sta
Otherwise a logdirty client can race with observing the page becoming dirty,
and copy the frame before the write is complete and end up with a stale
version.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Julien Grall
---
xen/arch/x86/mm.c | 10 --
1 file changed, 4 insertions(+)
On 11/05/17 16:35, Julien Grall wrote:
> Renaming the subject + adding more people in the conversation as this is
> not related to only ARM anymore.
>
> On 11/05/17 16:19, Volodymyr Babchuk wrote:
>> Hi Stefano,
>>
>> On 10 May 2017 at 21:24, Stefano Stabellini
>> wrote:
>>> I just want to point
Hi George,
On 11 May 2017 at 19:35, George Dunlap wrote:
> Even better would be to skip the module-loading step entirely, and just
> compile proprietary code directly into your Xen binary.
>
> Both solutions, unfortunately, are illegal.*
Look, I don't saying we want to produce closed-source modul
On Thu, May 11, 2017 at 6:14 PM, George Dunlap wrote:
> yourself at a risk of meeting a guy like Patrick McHardy[1], a private
> individual with copyright on the Linux kernel
This should be "copyright on *code in the* Linux Kernel". Obviously
he doesn't own a copyright on the whole thing, just a
Hi everyone,
I added the following sessions to the Design Part of the Summit: you can see
them via
https://xendeveloperanddesignsummit2017.sched.com/overview/type/Interactive+Design+%26+Problem+Solving+Session
(just showing Design sessions)
Please also make use of the "Add to my Sched(ule)" fe
On Thu, May 11, 2017 at 6:14 PM, Volodymyr Babchuk
wrote:
> Hi George,
>
> On 11 May 2017 at 19:35, George Dunlap wrote:
>> Even better would be to skip the module-loading step entirely, and just
>> compile proprietary code directly into your Xen binary.
>>
>> Both solutions, unfortunately, are i
The patch contains the updated version of rbtree implementation from linux
kernel tree containing the fixes so far handled.
Signed-off-by: Praveen Kumar
---
xen/common/rbtree.c| 748 +
xen/include/xen/compiler.h | 60 +++
xen/include/x
1 - 100 of 164 matches
Mail list logo
