On 15/05/17 22:35, Stefano Stabellini wrote:
> The pvcalls backend has one ioworker per cpu: the ioworkers are
> implemented as a cpu bound workqueue, and will deal with the actual
> socket and data ring reads/writes.
>
> ioworkers are global: we only have one set for all the frontends. They
> pro
Today disconnecting xen-blkback is broken in case there are still
I/Os in flight: xen_blkif_disconnect() will bail out early without
releasing all resources in the hope it will be called again when
the last request has terminated. This, however, won't happen as
xen_blkif_free() won't be called on t
There is no need to use xen_blkif_get()/xen_blkif_put() in the kthread
of xen-blkback. Thread stopping is synchronous and using the blkif
reference counting in the kthread will avoid to ever let the reference
count drop to zero at the end of an I/O running concurrent to
disconnecting and multiple r
Destroying a Xen guest domain while it was doing I/Os via xen-blkback
leaked several resources, including references of the guest's memory
pages.
This patch series addresses those leaks by correcting usage of
reference counts and the sequence when to free which resource.
The series applies on top
The be structure must nor be freed when freeing the blkif structure
isn't done. Otherwise a use-after-free of be when unmapping the ring
used for communicating with the frontend will occur in case of a
late call of xenblk_disconnect() (e.g. due to an I/O still active
when trying to disconnect).
Cc
Ok, it's NOT working after all. Trying to install a HVM causes a
reboot... so I guess there is more work left there after all. Would have
been too easy I guess ;)
Am 15.05.2017 um 21:20 schrieb Bjoern:
Hi,
I just completed getting Qubes-OS working with Ryzen and IOMMU - at
least it looks li
flight 109449 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109449/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386-xl-qemut-winxpsp3 16 guest-stop fail in 109428 pass in 109449
test-amd64-amd64-xl-qemut-win7-am
On Fri, May 12, 2017 at 10:31:28PM +1000, Jan Beulich wrote:
> >>> On 12.05.17 at 12:06, wrote:
> > On Fri, May 12, 2017 at 07:32:49PM +1000, Jan Beulich wrote:
> >> >>> On 11.05.17 at 11:02, wrote:
> >> > On Thu, May 11, 2017 at 06:14:42PM +1000, Jan Beulich wrote:
> >> >> Note that hvmloader's
On Mon, May 15, 2017 at 02:02:53AM -0600, Jan Beulich wrote:
> >>> On 14.05.17 at 00:36, wrote:
> > I haven't yet done as much experimentation as Andreas Pflug has, but I
> > can confirm I'm also running into this bug with Xen 4.4.1.
> >
> > I've only tried Linux kernel 3.16.43, but as Dom0:
> >
On 05/15/2017 03:51 PM, Gary R Hook wrote:
So I've been slogging through online docs and the code, trying to
understand where things stand with PVH.
I think my primary questions are:
1) How do I identify a PVHv2/HVMlite guest?
[root@dhcp-burlington7-2nd-B-east-10-152-55-52 ~]# dmesg | grep
On 05/15/2017 04:36 PM, Stefano Stabellini wrote:
Allocate a socket. Keep track of socket <-> ring mappings with a new data
structure, called sock_mapping. Implement the connect command by calling
inet_stream_connect, and mapping the new indexes page and data ring.
Associate the socket to an io
On 05/15/2017 04:35 PM, Stefano Stabellini wrote:
Just reply with success to the other end for now. Delay the allocation
of the actual socket to bind and/or connect.
Signed-off-by: Stefano Stabellini
CC: boris.ostrov...@oracle.com
CC: jgr...@suse.com
---
drivers/xen/pvcalls-back.c | 31 +
On 05/15/2017 04:35 PM, Stefano Stabellini wrote:
When the other end notifies us that there are commands to be read
(pvcalls_back_event), wake up the backend thread to parse the command.
The command ring works like most other Xen rings, so use the usual
ring macros to read and write to it. The
On 05/15/2017 04:35 PM, Stefano Stabellini wrote:
Introduce a per-frontend data structure named pvcalls_back_priv. It
contains pointers to the command ring, its event channel, a list of
active sockets and a tree of passive sockets (passing sockets need to be
looked up from the id on listen, acc
On 05/15/2017 04:35 PM, Stefano Stabellini wrote:
Introduce the code to handle xenbus state changes.
Implement the probe function for the pvcalls backend. Write the
supported versions, max-page-order and function-calls nodes to xenstore,
as required by the protocol.
Introduce stub functions f
On 05/15/2017 04:35 PM, Stefano Stabellini wrote:
The pvcalls backend has one ioworker per cpu: the ioworkers are
implemented as a cpu bound workqueue, and will deal with the actual
socket and data ring reads/writes.
ioworkers are global: we only have one set for all the frontends. They
proces
flight 109448 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109448/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-debianhvm-amd64 9 debian-hvm-install fail REGR. vs.
109428
test-amd64-i3
On 2017-05-16 10:49, Glenn Enright wrote:
On 15/05/17 21:57, Juergen Gross wrote:
On 13/05/17 06:02, Glenn Enright wrote:
On 09/05/17 21:24, Roger Pau Monné wrote:
On Mon, May 08, 2017 at 11:10:24AM +0200, Juergen Gross wrote:
On 04/05/17 00:17, Glenn Enright wrote:
On 04/05/17 04:58, Steven
On 15/05/17 21:57, Juergen Gross wrote:
On 13/05/17 06:02, Glenn Enright wrote:
On 09/05/17 21:24, Roger Pau Monné wrote:
On Mon, May 08, 2017 at 11:10:24AM +0200, Juergen Gross wrote:
On 04/05/17 00:17, Glenn Enright wrote:
On 04/05/17 04:58, Steven Haigh wrote:
On 04/05/17 01:53, Juergen G
On 5/8/2017 12:41 PM, Julien Grall wrote:
> Hi all,
>
> Xen 4.9 rc4 is tagged. You can check that out from xen.git:
>
> git://xenbits.xen.org/xen.git 4.9.0-rc4
>
Tested the release on Qualcomm Datacenter Technologies QDF2400 platform (Linux
kernel 4.11). Basic DOM0 boot works fine after
disa
This change adds calls to the SASL API to negotiate SASL auth and
includes SASL encode/decode into read and write flows if the SASL
mechanism is providing SSF.
The code is taken from upstream with minor adjustments for
compatibility with qemu-xen-traditional.
Signed-off-by: Simon Waterman
---
v
This change adjusts vnc.c for compatibility with the API defined
in vnc.h.
Signed-off-by: Simon Waterman
---
vnc.c | 212 +-
1 file changed, 27 insertions(+), 185 deletions(-)
diff --git a/vnc.c b/vnc.c
index 0e61197..728efec 10064
Add the SASL auth API to hook into vnc.c. Taken from upstream
with minor changes to remove ACL support, which isn't in
qemu-xen-traditional yet.
Signed-off-by: Simon Waterman
---
vnc-auth-sasl.h | 67 +
1 file changed, 67 insertions(+)
cr
This change adds build support for the SASL integration,
disabled by default.
Signed-off-by: Simon Waterman
---
Makefile.target | 6 ++
configure | 34 ++
2 files changed, 40 insertions(+)
diff --git a/Makefile.target b/Makefile.target
index 3c3db2b..a
Taken almost directly from upstream QEMU with minor changes:
1. Replace g_free etc. with standard equivalents
2. Remove ACL support, which is not in qemu-xen-traditional yet.
Signed-off-by: Simon Waterman
---
vnc-auth-sasl.c | 613
1 file
This patch series back-ports SASL authentication from
upstream QEMU to the VNC server in qemu-xen-traditional.
It enables authentication to the VNC console of a domain
to be controlled using any SASL mechanism when using an
IOEMU stubdom.
SASL can be used with or without X509 certificates.
The op
Expose minimum VNC API to support SASL auth. This is mainly the
VncState structure and a subset of the API funcs.
The layout of the file is modelled on the upstream QEMU vnc.h.
Signed-off-by: Simon Waterman
---
vnc.h | 231 +++---
1 f
Hi Daniel,
On 15 May 2017 at 21:46, Daniel Kiper wrote:
> Hi Julien,
>
> On Mon, May 15, 2017 at 02:43:28PM +0100, Julien Grall wrote:
>> Hi Daniel,
>>
>> On 15/05/17 14:38, Daniel Kiper wrote:
>> >On Sun, May 14, 2017 at 03:43:44PM +0800, fu@linaro.org wrote:
>> >>From: Fu Wei
>> >>
>> >>Th
Time to wire up all the call sites that request a shutdown or
reset to use the enum added in the previous patch.
It would have been less churn to keep the common case with no
arguments as meaning guest-triggered, and only modified the
host-triggered code paths, via a wrapper function, but then we'
We want to track why a guest was shutdown; in particular, being able
to tell the difference between a guest request (such as ACPI request)
and host request (such as SIGINT) will prove useful to libvirt.
Since all requests eventually end up changing shutdown_requested in
vl.c, the logical change is
On 05/15/2017 03:28 PM, Konrad Rzeszutek Wilk wrote:
> Hey Jens,
>
> Could you kindly pull:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
> stable/for-jens-4.12
>
> which has one tiny fix:
>
> Thanks!
>
> Gustavo A. R. Silva (1):
> block: xen-blkback: add null check
Hey Jens,
Could you kindly pull:
git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
stable/for-jens-4.12
which has one tiny fix:
Thanks!
Gustavo A. R. Silva (1):
block: xen-blkback: add null check to avoid null pointer dereference
drivers/block/xen-blkback/xenbus.c | 8
On Thu, May 11, 2017 at 10:27:35AM -0500, Gustavo A. R. Silva wrote:
> Add null check before calling xen_blkif_put() to avoid potential
> null pointer dereference.
>
Applied to 'stable/for-jens-4.12' and will push soon to Jens.
> Addresses-Coverity-ID: 1350942
> Cc: Juergen Gross
> Signed-off-b
Release both active and passive sockets. For active sockets, make sure
to avoid possible conflicts with the ioworker reading/writing to those
sockets concurrently. Set map->release to let the ioworker know
atomically that the socket will be released soon, then wait until the
ioworker removed the so
The pvcalls backend has one ioworker per cpu: the ioworkers are
implemented as a cpu bound workqueue, and will deal with the actual
socket and data ring reads/writes.
ioworkers are global: we only have one set for all the frontends. They
process requests on their wqs list in order, once they are d
Allocate a socket. Track the allocated passive sockets with a new data
structure named sockpass_mapping. It contains an unbound workqueue to
schedule delayed work for the accept and poll commands. It also has a
reqcopy field to be used to store a copy of a request for delayed work.
Reads/writes to
Introduce a xenbus backend for the pvcalls protocol, as defined by
https://xenbits.xen.org/docs/unstable/misc/pvcalls.html.
This patch only adds the stubs, the code will be added by the following
patches.
Signed-off-by: Stefano Stabellini
CC: boris.ostrov...@oracle.com
CC: jgr...@suse.com
---
d
Implement the accept command by calling inet_accept. To avoid blocking
in the kernel, call inet_accept(O_NONBLOCK) from a workqueue, which get
scheduled on sk_data_ready (for a passive socket, it means that there
are connections to accept).
Use the reqcopy field to store the request. Accept the ne
When an active socket has data available, add the relative sock_mapping
to the ioworker list, increment the io and read counters, and schedule
the ioworker.
Implement the read function by reading from the socket, writing the data
to the data ring.
Set in_error on error.
Signed-off-by: Stefano St
Implement backend_disconnect. Call pvcalls_back_release_active on active
sockets and pvcalls_back_release_passive on passive sockets.
Implement module_exit by calling backend_disconnect on frontend
connections.
Signed-off-by: Stefano Stabellini
CC: boris.ostrov...@oracle.com
CC: jgr...@suse.com
When the other end notifies us that there is data to be written
(pvcalls_back_conn_event), add the relative sock_mapping to the ioworker
list, increment the io and write counters, and schedule the ioworker.
Implement the write function called by ioworker by reading the data from
the data ring, wri
Call inet_listen to implement the listen command.
Signed-off-by: Stefano Stabellini
CC: boris.ostrov...@oracle.com
CC: jgr...@suse.com
---
drivers/xen/pvcalls-back.c | 23 ++-
1 file changed, 22 insertions(+), 1 deletion(-)
diff --git a/drivers/xen/pvcalls-back.c b/drivers/x
We have one ioworker per cpu core. Each ioworker gets assigned active
sockets randomly. Once a socket is assigned to an ioworker, it remains
tied to it until is released.
Each ioworker goes through the list of outstanding read/write requests
by walking a list of struct sock_mapping. Once a request
Allocate a socket. Keep track of socket <-> ring mappings with a new data
structure, called sock_mapping. Implement the connect command by calling
inet_stream_connect, and mapping the new indexes page and data ring.
Associate the socket to an ioworker randomly.
When an active socket is closed (sk_
Introduce the code to handle xenbus state changes.
Implement the probe function for the pvcalls backend. Write the
supported versions, max-page-order and function-calls nodes to xenstore,
as required by the protocol.
Introduce stub functions for disconnecting/connecting to a frontend.
Signed-off
Also add pvcalls-back to the Makefile.
Signed-off-by: Stefano Stabellini
CC: boris.ostrov...@oracle.com
CC: jgr...@suse.com
---
drivers/xen/Kconfig | 12
drivers/xen/Makefile | 1 +
2 files changed, 13 insertions(+)
diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index f15
Implement poll on passive sockets by requesting a delayed response with
mappass->reqcopy, and reply back when there is data on the passive
socket.
Poll on active socket is unimplemented as by the spec, as the frontend
should just wait for events and check the indexes on the indexes page.
Only sup
When the other end notifies us that there are commands to be read
(pvcalls_back_event), wake up the backend thread to parse the command.
The command ring works like most other Xen rings, so use the usual
ring macros to read and write to it. The functions implementing the
commands are empty stubs f
Introduce a per-frontend data structure named pvcalls_back_priv. It
contains pointers to the command ring, its event channel, a list of
active sockets and a tree of passive sockets (passing sockets need to be
looked up from the id on listen, accept and poll commands, while active
sockets only on re
Just reply with success to the other end for now. Delay the allocation
of the actual socket to bind and/or connect.
Signed-off-by: Stefano Stabellini
CC: boris.ostrov...@oracle.com
CC: jgr...@suse.com
---
drivers/xen/pvcalls-back.c | 31 ++-
1 file changed, 30 inserti
Hi all,
this series introduces the backend for the newly introduced PV Calls
procotol.
PV Calls is a paravirtualized protocol that allows the implementation of
a set of POSIX functions in a different domain. The PV Calls frontend
sends POSIX function calls to the backend, which implements them an
Introduce the C header file which defines the PV Calls interface. It is
imported from xen/include/public/io/pvcalls.h.
Signed-off-by: Stefano Stabellini
CC: konrad.w...@oracle.com
CC: boris.ostrov...@oracle.com
CC: jgr...@suse.com
---
include/xen/interface/io/pvcalls.h | 117
So I've been slogging through online docs and the code, trying to
understand where things stand with PVH.
I think my primary questions are:
1) How do I identify a PVHv2/HVMlite guest?
2) Or, perhaps more importantly, what distinguishes said guest?
I've got Xen 4.9 unstable built/installed/bo
Time to wire up all the call sites that request a shutdown or
reset to use the enum added in the previous patch.
It would have been less churn to keep the common case with no
arguments as meaning guest-triggered, and only modified the
host-triggered code paths, via a wrapper function, but then we'
We want to track why a guest was shutdown; in particular, being able
to tell the difference between a guest request (such as ACPI request)
and host request (such as SIGINT) will prove useful to libvirt.
Since all requests eventually end up changing shutdown_requested in
vl.c, the logical change is
Hi,
I just completed getting Qubes-OS working with Ryzen and IOMMU - at
least it looks like it to me and ran out of the box BIOS wise.
All that was required is a small patch in
xen/arch/x86/oprofile/nmi_int.c - Ryzen family 17h is the same as 15h.
Without that, "xl dmesg" under Ubuntu 17.04
flight 109441 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109441/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-winxpsp3 17 guest-start/win.repeat fail REGR. vs.
109165
Tests which ar
> -Original Message-
> From: Daniel Kiper [mailto:daniel.ki...@oracle.com]
> Sent: Monday, May 15, 2017 6:13 AM
> To: Bill Jacobs (billjac) ; george.dun...@citrix.com
> Cc: xen-devel@lists.xen.org; xen-us...@lists.xen.org
> Subject: Re: [Xen-users] UEFI Secure Boot Xen 4.9
>
> Hey,
>
>
On Mon, May 15, 2017 at 02:37:33PM +0100, Julien Grall wrote:
> Hi Roger,
>
> On 11/05/17 12:43, Roger Pau Monne wrote:
> > 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/remov
flight 109445 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109445/
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
flight 109446 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109446/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-credit2 7 host-ping-check-xen fail REGR. vs. 109161
test-amd64-i386-xl-q
On 2017-05-13 19:17, PGNet Dev wrote:
On 5/13/17 3:15 PM, Valentin Vidic wrote:
Try booting without 'hpet=force,verbose clocksource=hpet' and it should
select xen by default:
Nope. Well, not quite ...
With both
'hpet=force,verbose clocksource=hpet'
removed, I end up with
ca
On Mon, 15 May 2017, Jan Beulich wrote:
> >>> On 15.05.17 at 12:21, wrote:
> > On 05/15/2017 09:52 AM, Jan Beulich wrote:
> > On 15.05.17 at 10:20, wrote:
> >>> On 15/05/2017 09:08, Jan Beulich wrote:
> >>> On 12.05.17 at 19:01, wrote:
> >
On Mon, 15 May 2017, George Dunlap wrote:
> On Fri, May 12, 2017 at 7:47 PM, Volodymyr Babchuk
> wrote:
> >> Regarding modules (#3): The problem that loadable modules were
> >> primarily introduced to solve in Linux wasn't "How to deal with
> >> proprietary drivers", or even "how to deal with out-
On Mon, 15 May 2017, George Dunlap wrote:
> [Reducing CC list now that we're off the topic of modules]
>
> On Fri, May 12, 2017 at 8:04 PM, Volodymyr Babchuk
> wrote:
> > Stefano,
> >
> > On 12 May 2017 at 21:43, Stefano Stabellini wrote:
> >
> >> On the topic of the technical reasons for being
Committers,
It looks like osstest is a bit behind because of ARM64 boxes (they are
fully loaded) and XP testing (they now have been removed see [1]).
I'd like to cut the next rc when staging == master, so please stop
committing today.
Ian forced pushed osstest today, so hopefully we can get
Hi,
On 15/05/17 18:11, Feng Kan wrote:
On Mon, May 15, 2017 at 7:53 AM, Julien Grall wrote:
Hello Feng,
On 13/05/17 01:26, Feng Kan wrote:
The pa_range_info table contain incorrect root_order and t0sz which
prevent 42 bit PA systems from booting dom0.
As I mentioned in the previous threa
On Mon, May 15, 2017 at 7:53 AM, Julien Grall wrote:
> Hello Feng,
>
> On 13/05/17 01:26, Feng Kan wrote:
>>
>> The pa_range_info table contain incorrect root_order and t0sz which
>> prevent 42 bit PA systems from booting dom0.
>
>
> As I mentioned in the previous thread [1], this is not a bug. Wh
On Mon, May 15, 2017 at 01:02:48AM -0600, Jan Beulich wrote:
> >>> On 12.05.17 at 18:20, wrote:
> > On Fri, May 12, 2017 at 12:52:54AM -0600, Jan Beulich wrote:
> >> The rule for headers++.chk wants to move headers++.chk.new to the
> >> designated target, which means we have to create that file in
On Sat, May 13, 2017 at 10:28:27AM +0800, Zhongze Liu wrote:
> 2017-05-13 1:51 GMT+08:00 Wei Liu :
> > Hi Zhongze
> >
> > This is a nice write-up. Some comments below. Feel free to disagree with
> > what I say below, this is more a discussion than picking on your design
> > or plan.
> >
>
> HI, We
On Mon, May 15, 2017 at 04:29:31PM +0100, Julien Grall wrote:
> Hi George,
>
> CC Ian and Wei for feedback on the error.
>
No you didn't. ;p
I've tracked down the issue. Trying to work out a fix at the moment.
The culprit is: stubdom build runs before tools build. The link farm
rune in tools/i
On Mon, May 15, 2017 at 04:48:47PM +0100, George Dunlap wrote:
>On Thu, May 11, 2017 at 7:04 AM, Chao Gao wrote:
>> Currently, a blocked vCPU is put in its pCPU's pi blocking list. If
>> too many vCPUs are blocked on a given pCPU, it will incur that the list
>> grows too long. After a simple analy
On Thu, May 11, 2017 at 7:04 AM, Chao Gao wrote:
> Currently, a blocked vCPU is put in its pCPU's pi blocking list. If
> too many vCPUs are blocked on a given pCPU, it will incur that the list
> grows too long. After a simple analysis, there are 32k domains and
> 128 vcpu per domain, thus about 4M
On 15/05/17 16:31, Jan Beulich wrote:
On 15.05.17 at 14:50, wrote:
>> --- a/xen/arch/x86/traps.c
>> +++ b/xen/arch/x86/traps.c
>> @@ -633,9 +633,12 @@ void pv_inject_event(const struct x86_event *event)
>> const struct trap_info *ti;
>> const uint8_t vector = event->vector;
>>
>>> On 15.05.17 at 14:50, wrote:
> do_guest_trap() is now functionally equivelent to pv_inject_hw_exception(),
> but with a less useful API as it requires the error code parameter to be
> passed implicitly via cpu_user_regs.
>
> Extend pv_inject_event() with a further assertion which checks that
>>> On 15.05.17 at 14:50, wrote:
> --- a/xen/arch/x86/traps.c
> +++ b/xen/arch/x86/traps.c
> @@ -633,9 +633,12 @@ void pv_inject_event(const struct x86_event *event)
> const struct trap_info *ti;
> const uint8_t vector = event->vector;
> const bool use_error_code =
> +(event
Hi George,
CC Ian and Wei for feedback on the error.
On 15/05/17 14:04, George Dunlap wrote:
On Sun, May 14, 2017 at 10:50 AM, Steven Haigh wrote:
On 10/05/17 23:02, Steven Haigh wrote:
On 10/05/17 01:20, M A Young wrote:
On Tue, 9 May 2017, Steven Haigh wrote:
I'm trying to use the same
On 11/05/17 07:04, Chao Gao wrote:
> This patch adds TRC_HVM_PI_LIST_ADD to track adding one entry to
> the per-pcpu blocking list. Also introduce a 'counter' to track
> the number of entries in the list.
So first of all, you have the importance of the order here backwards.
The most important thin
On 08/02/17 07:46, Tian, Kevin wrote:
>> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
>> Sent: Tuesday, February 07, 2017 12:55 AM
>>
>> * Latch current once at the start.
>> * Avoid the memory operand read for INVEPT_ALL_CONTEXT. Experimentally,
>> this
>>is how hardware behaves,
Hello Feng,
On 13/05/17 01:26, Feng Kan wrote:
The pa_range_info table contain incorrect root_order and t0sz which
prevent 42 bit PA systems from booting dom0.
As I mentioned in the previous thread [1], this is not a bug. What you
configure below is the stage-2 page table and not the hypervis
On Thu, May 11, 2017 at 7:04 AM, Chao Gao wrote:
> This patch intruduces a 'refcnt' field in vmx_pi_blocking to track
> the reference count of 'pi_desc' of the vCPU. And change this field
> every time we re-program one IRTE.
>
> Signed-off-by: Chao Gao
> ---
> xen/arch/x86/hvm/vmx/vmx.c
On Mon, May 15, 2017 at 2:35 PM, Andrew Cooper
wrote:
> On 15/05/17 11:27, George Dunlap wrote:
>> On Fri, May 12, 2017 at 12:05 PM, Andrew Cooper
>> wrote:
>>> Citrix Netscalar SDX boxes have more MSI-X interrupts than fit in the
>>> cumulative IDTs of a top end dual-socket Xeon server systems.
>>> On 15.05.17 at 16:13, wrote:
> On 15/05/17 13:28, Jan Beulich wrote:
> On 15.05.17 at 12:21, wrote:
>>> On Zhongze proposal, the share page will be mapped at the a specific
>>> address in the guest memory. I agree this will require some work in the
>>> toolstack, on the hypervisor side we
On 15/05/17 16:22, Vitaly Kuznetsov wrote:
> Juergen Gross writes:
>
>> Lguest and Xen pv-guests are the only users of pv_mmu_ops (with the
>> one exception of the .exit_mmap member, which is being used by Xen
>> HVM-guests, too).
>>
>> As it is possible now to build a kernel without Xen pv-guest
>>> On 15.05.17 at 15:08, wrote:
> On 15/05/17 11:19, Jan Beulich wrote:
>> >>> On 15.05.17 at 12:08, wrote:
>> On 12.05.17 at 19:35, wrote:
--- a/xen/include/asm-x86/string.h
+++ b/xen/include/asm-x86/string.h
@@ -2,13 +2,23 @@
#define __X86_STRING_H__
#de
Juergen Gross writes:
> Lguest and Xen pv-guests are the only users of pv_mmu_ops (with the
> one exception of the .exit_mmap member, which is being used by Xen
> HVM-guests, too).
>
> As it is possible now to build a kernel without Xen pv-guest support
> while keeping PVH and PVHVM support, I th
Hi Jan,
On 15/05/17 13:28, Jan Beulich wrote:
On 15.05.17 at 12:21, wrote:
On 05/15/2017 09:52 AM, Jan Beulich wrote:
On 15.05.17 at 10:20, wrote:
On 15/05/2017 09:08, Jan Beulich wrote:
On 12.05.17 at 19:01, wrote:
1. Motivation and D
populate_physmap() calls alloc_heap_pages() per requested
extent. alloc_heap_pages() invalidates the entire icache per
extent. During domain creation, the icache invalidations can be deffered
until all the extents have been allocated as there is no risk of
executing stale instructions from the icac
When toolstack requests flushing the caches, flush_page_to_ram() is
called for each page of the requested domain. This needs to unnecessary
icache invalidation operations.
Let's take the responsibility of performing icache operations and use
the recently introduced flag to prevent redundant icache
flush_page_to_ram() unconditionally drops the icache. In certain
situations this leads to execessive icache flushes when
flush_page_to_ram() ends up being repeatedly called in a loop.
Introduce a parameter to allow callers of flush_page_to_ram() to take
responsibility of synchronising the icache.
Hi,
This series was previously posted as an RFC[0]. An issue was discovered
in the RFC related to delaying icache invalidations when the domain is
active. Accordingly, Patch 3 has been modified to avoid per-page
icache invalidations only during domain creation.
Changes from RFC:
* Fixed coding s
Lguest and Xen pv-guests are the only users of pv_mmu_ops (with the
one exception of the .exit_mmap member, which is being used by Xen
HVM-guests, too).
As it is possible now to build a kernel without Xen pv-guest support
while keeping PVH and PVHVM support, I thought about putting most
pv_mmu_ops
Looks like I've got Konrad's email wrong. Please ignore this
thread. I'll repost with the right address. :(
Apologies for the spam.
Punit
Punit Agrawal writes:
> Hi,
>
> This series was previously posted as an RFC[0]. An issue was discovered
> in the RFC related to delaying icache invalidatio
Hi,
This series was previously posted as an RFC[0]. An issue was discovered
in the RFC related to delaying icache invalidations when the domain is
active. Accordingly, Patch 3 has been modified to avoid per-page
icache invalidations only during domain creation.
Changes from RFC:
* Fixed coding s
populate_physmap() calls alloc_heap_pages() per requested
extent. alloc_heap_pages() invalidates the entire icache per
extent. During domain creation, the icache invalidations can be deffered
until all the extents have been allocated as there is no risk of
executing stale instructions from the icac
When toolstack requests flushing the caches, flush_page_to_ram() is
called for each page of the requested domain. This needs to unnecessary
icache invalidation operations.
Let's take the responsibility of performing icache operations and use
the recently introduced flag to prevent redundant icache
flush_page_to_ram() unconditionally drops the icache. In certain
situations this leads to execessive icache flushes when
flush_page_to_ram() ends up being repeatedly called in a loop.
Introduce a parameter to allow callers of flush_page_to_ram() to take
responsibility of synchronising the icache.
Hi Jan,
On 12/05/17 07:52, Jan Beulich wrote:
The rule for headers++.chk wants to move headers++.chk.new to the
designated target, which means we have to create that file in the first
place.
Signed-off-by: Jan Beulich
Release-acked-by: Julien Grall
Cheers,
--- a/xen/include/Makefile
+++
Hi Juergen,
On 12/05/17 14:10, Juergen Gross wrote:
blktap2 is optional, so there should be no pkg-config file requiring
xenblktapctl if it isn't enabled for the build.
Add a filter mechanism to tools/Rules.mk to filter out optional
libraries.
Signed-off-by: Juergen Gross
Release-acked-by:
Hi,
On 12/05/17 17:23, Wei Liu wrote:
On Fri, May 12, 2017 at 04:21:06PM +0100, Wei Liu wrote:
They are generated by ./configure. Having them linked can cause race
between tools build and stubdom build.
Signed-off-by: Wei Liu
FTR Juergen told me on IRC:
Reviewed-by: Juergen Gross
Releas
1 - 100 of 156 matches
Mail list logo
