flight 131191 xen-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131191/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stopfail REGR. vs. 129676
Tests which ar
In commit efe9cba66c ("x86emul: VME and PVI modes require a #GP(0) check
first thing") I neglected the fact that the retire flags get zapped only
in x86_decode(), which hasn't been invoked yet at the point of the #GP(0)
check added. Move output state initialization into a helper function,
and invok
The check needs to happen whenever EVEX.b (SDM nomenclature) is clear,
not just in the memory operand case.
Signed-off-by: Jan Beulich
---
v2: Clarify naming (to address apparent disconnect between description
and code change).
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/
There are a number of exception condition related errata on SandyBridge
CPUs, some of which are unexpected #UD (others, of no interest here, are
lack of mandated exceptions, or exceptions of unexpected type). Annotate
the one workaround we already have, and add two more.
Due to the exception recov
flight 131190 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131190/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qcow2 7 xen-boot fail REGR. vs. 125898
test-amd64-amd64-py
Ping?
On Fri, Oct 26, Olaf Hering wrote:
> A given Qemu version can not predict what version of Xen it will run on.
> There are some checks in configure to decide what Xen libraries and
> functions are available. How exactly these functions must be accessed
> has to be decided by configure and t
On Mon, 10 Dec 2018 16:12:57 +0100
Andrea Righi wrote:
> Blacklist symbols in Xen probe-prohibited areas, so that user can see
> these prohibited symbols in debugfs.
>
> See also: a50480cb6d61.
Looks good to me, thanks!
Acked-by: Masami Hiramatsu
>
> Signed-off-by: Andrea Righi
> ---
> ar
On 12/10/18 6:59 PM, Razvan Cojocaru wrote:
> On 12/10/18 6:49 PM, Roger Pau Monné wrote:
>> On Mon, Dec 10, 2018 at 06:01:49PM +0200, Razvan Cojocaru wrote:
>>> diff --git a/xen/include/asm-arm/vm_event.h b/xen/include/asm-arm/vm_event.h
>>> index 66f2474..b63249e 100644
>>> --- a/xen/include/asm-
On Tue, Dec 11, 2018 at 12:01:53PM +0200, Razvan Cojocaru wrote:
> On 12/10/18 6:59 PM, Razvan Cojocaru wrote:
> > On 12/10/18 6:49 PM, Roger Pau Monné wrote:
> >> On Mon, Dec 10, 2018 at 06:01:49PM +0200, Razvan Cojocaru wrote:
> >>> diff --git a/xen/include/asm-arm/vm_event.h
> >>> b/xen/include
On 12/11/18 12:14 PM, Roger Pau Monné wrote:
> On Tue, Dec 11, 2018 at 12:01:53PM +0200, Razvan Cojocaru wrote:
>> On 12/10/18 6:59 PM, Razvan Cojocaru wrote:
>>> On 12/10/18 6:49 PM, Roger Pau Monné wrote:
On Mon, Dec 10, 2018 at 06:01:49PM +0200, Razvan Cojocaru wrote:
> diff --git a/xen
flight 131205 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131205/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
freebsd f71d2bdf0c00378411ab60ec1ab76196b920e666
baseline version:
freebsd 3c25eec2c35
On Tue, 25 Apr 2017 at 19:35, Stefano Stabellini wrote:
>
> From: Juergen Gross
>
> Instead of trying to guess the Xen version to use by compiling various
> test programs first just ask the system via pkg-config. Only if it
> can't return the version fall back to the test program scheme.
>
> If c
On Tue, Dec 11, 2018 at 10:34:52AM +, Peter Maydell wrote:
> On Tue, 25 Apr 2017 at 19:35, Stefano Stabellini
> wrote:
> >
> > From: Juergen Gross
> >
> > Instead of trying to guess the Xen version to use by compiling various
> > test programs first just ask the system via pkg-config. Only i
Not all of the code duplicated from xen_disk.c is required as the basis for
the new dataplane implementation so this patch removes extraneous code,
along with the legacy #includes and calls to the legacy xen_pv_printf()
function. Error messages are changed to be reported using error_report().
NOTE
This patch adds the basic boilerplate for a 'XenBus' object that will act
as a parent to 'XenDevice' PV backends.
A new 'XenBridge' object is also added to connect XenBus to the system bus.
The XenBus object is instantiated by a new xen_bus_init() function called
from the same sites as the legacy
This patch adds new XenDevice-s: 'xen-disk' and 'xen-cdrom', both derived
from a common 'xen-block' parent type. These will eventually replace the
'xen_disk' (note the underscore rather than hyphen) legacy PV backend but
it is illustrative to build up the implementation incrementally, along with
th
This patch adds a new source module, xen-bus-helper.c, which builds on
basic libxenstore primitives to provide functions to create (setting
permissions appropriately) and destroy xenstore areas, and functions to
'printf' and 'scanf' nodes therein. The main xen-bus code then uses
these primitives [1
The legacy PV backend infrastructure provides functions to bind, unbind
and send notifications to event channnels. Similar functionality will be
required by XenDevice implementations so this patch adds the necessary
support.
Signed-off-by: Paul Durrant
Reviewed-by: Stefano Stabellini
---
Cc: Ant
This series introduces a new QOM compliant framework for Xen PV backends.
This is achieved by first moving the current non-compliant framework aside,
before building up a new framework incrementally.
This series was prompted by a thread [1] started by Kevin Wolf in response
to patches against xen_
The legacy PV backend infrastructure provides functions to map, unmap and
copy pages granted by frontends. Similar functionality will be required
by XenDevice implementations so this patch adds the necessary support.
Signed-off-by: Paul Durrant
Reviewed-by: Anthony Perard
---
Cc: Stefano Stabell
A Xen PV frontend communicates its state to the PV backend by writing to
the 'state' key in the frontend area in xenstore. It is therefore
necessary for a XenDevice implementation to be notified whenever the
value of this key changes.
This patch adds code to do this as follows:
- an 'fd handler'
The new xen-block XenDevice implementation requires the same core
dataplane as the legacy xen_disk implementation it will eventually replace.
This patch therefore copies the legacy xen_disk.c source module into a new
dataplane/xen-block.c source module as the basis for the new dataplane and
adjusts
...and xen_backend.h to xen-legacy-backend.h
Rather than attempting to convert the existing backend infrastructure to
be QOM compliant (which would be hard to do in an incremental fashion),
subsequent patches will introduce a completely new framework for Xen PV
backends. Hence it is necessary to r
...and wire in the dataplane.
This patch adds the remaining code to make the xen-block XenDevice
functional. The parameters that a block frontend expects to find are
populated in the backend xenstore area, and the 'ring-ref' and
'event-channel' values specified in the frontend xenstore area are
ma
This is a purely cosmetic patch that purges remaining use of 'blk' and
'ioreq' in local function names, and then makes sure all functions are
prefixed with 'xen_block_'.
No functional change.
Signed-off-by: Paul Durrant
Acked-by: Anthony Perard
---
Cc: Stefano Stabellini
Cc: Stefan Hajnoczi
C
This is a purely cosmetic patch that substitutes the old 'struct XenBlkDev'
name with 'XenBlockDataPlane' and 'blkdev' field/variable names with
'dataplane', and then does necessary fix-up to adhere to coding style.
No functional change.
Signed-off-by: Paul Durrant
Acked-by: Anthony Perard
---
This is a purely cosmetic patch that purges the name 'ioreq' from struct,
variable and field names. (This name has been problematic for a long time
as 'ioreq' is the name used for generic I/O requests coming from Xen).
The patch replaces 'struct ioreq' with a new 'XenBlockRequest' type and
'ioreq'
I have made many significant contributions to the Xen code in QEMU,
particularly the recent patches introducing a new PV device framework.
I intend to make further significant contributions, porting other PV back-
ends to the new framework with the intent of eventually removing the
legacy code. It
This patch adds the transformations necessary to get dataplane/xen-block.c
to build against the new XenBus/XenDevice framework. MAINTAINERS is also
updated due to the introduction of dataplane/xen-block.h.
NOTE: Existing data structure names are retained for the moment. These will
be modifie
...that maintains compatibility with existing Xen toolstacks.
Xen toolstacks instantiate PV backends by simply writing information into
xenstore and expecting a backend implementation to be watching for this.
This patch adds a new 'xen-backend' module to allow individual XenDevice
implementations
This backend has now been replaced by the 'xen-qdisk' XenDevice.
Signed-off-by: Paul Durrant
Acked-by: Anthony Perard
---
Cc: Kevin Wolf
Cc: Max Reitz
Cc: Stefano Stabellini
---
hw/block/Makefile.objs |1 -
hw/block/xen_disk.c| 1011
2
This patch adds a creator function for XenBlockDevice-s so that they can
be created automatically when the Xen toolstack instantiates a new
PV backend. When the XenBlockDevice is created this way it is also
necessary to create a drive which matches the configuration that the Xen
toolstack has writt
Ping? This has acks from Andy and Brian now, but has not been committed. Is
there anything holding it up?
> -Original Message-
> From: Paul Durrant [mailto:paul.durr...@citrix.com]
> Sent: 28 November 2018 09:56
> To: xen-devel@lists.xenproject.org
> Cc: Paul Durrant ; Suravee Suthikulpan
On Mon, Dec 10, 2018 at 11:33:09AM -0800, Lars Kurth wrote:
> This patch makes a few clarifications which were discussed on
> IRC recently.
>
> Specifically:
> - Highlight the principle that license deviations
> should be brought to the attention of maintainers
> - Add a requirement for GPLv2
>>> On 11.12.18 at 12:00, wrote:
> Ping? This has acks from Andy and Brian now, but has not been committed. Is
> there anything holding it up?
I keep overlooking it when checking what is ready to be committed,
sorry.
Jan
___
Xen-devel mailing list
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 11 December 2018 11:22
> To: Paul Durrant
> Cc: Brian Woods ; Suravee Suthikulpanit
> ; xen-devel de...@lists.xenproject.org>
> Subject: Re: [Xen-devel] [PATCH v3] amd-iommu: remove page merging code
>
> >>> On
Hi Lars,
On 10/12/2018 19:33, Lars Kurth wrote:
This patch makes a few clarifications which were discussed on
IRC recently.
Specifically:
- Highlight the principle that license deviations
should be brought to the attention of maintainers
- Add a requirement for GPLv2 compatibility
- Restruct
flight 131225 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131225/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
The out label is followed by a semicolon only. Use return directly.
Signed-off-by: Wei Liu
---
xen/arch/x86/apic.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/xen/arch/x86/apic.c b/xen/arch/x86/apic.c
index 7120107b0c..b06eedf326 100644
--- a/xen/arch/x86/apic.c
+++ b/
Wei Liu (2):
xen: clean up common/page_alloc.c
xen: simplify {check,poison}_one_page
xen/common/page_alloc.c | 56 -
1 file changed, 27 insertions(+), 29 deletions(-)
--
2.11.0
___
Xen-devel mailin
Use __map_domain_page macro to deal with page_info directly.
No functional change.
Signed-off-by: Wei Liu
---
xen/common/page_alloc.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index 677a8e18ce..2c6509e3a0 100644
-
Remove trailing whitespaces. Turn bool_t into bool. Annotate a section
for CONFIG_SEPARATE_XENHEAP.
Signed-off-by: Wei Liu
---
xen/common/page_alloc.c | 50 -
1 file changed, 25 insertions(+), 25 deletions(-)
diff --git a/xen/common/page_alloc.c b
Hi,
On 11/12/2018 10:21, Razvan Cojocaru wrote:
On 12/11/18 12:14 PM, Roger Pau Monné wrote:
On Tue, Dec 11, 2018 at 12:01:53PM +0200, Razvan Cojocaru wrote:
On 12/10/18 6:59 PM, Razvan Cojocaru wrote:
On 12/10/18 6:49 PM, Roger Pau Monné wrote:
On Mon, Dec 10, 2018 at 06:01:49PM +0200, Razv
Hi Andrew,
On 07/12/2018 15:24, Andrew Cooper wrote:
On 07/12/2018 15:09, Julien Grall wrote:
Hi Andrew,
On 07/12/2018 13:45, Andrew Cooper wrote:
A large amount of the information here is obsolete since Xen 4.7
To being with, however, this patch marks a change in style for section
headings,
On Mon, Dec 10, 2018 at 11:33:28AM +0100, Roger Pau Monné wrote:
> On Thu, Dec 06, 2018 at 12:42:15PM +, Wei Liu wrote:
> > On Wed, Dec 05, 2018 at 03:55:00PM +0100, Roger Pau Monne wrote:
> > > Current approximation of paging memory usage is based on the required
> > > amount when running in s
On 10/12/2018 12:23, Andrii Anisov wrote:
Hello Julien,
On 10.12.18 13:54, Julien Grall wrote:
What are the numbers without Xen?
Good question. Didn't try. At least putchar should be implemented for that.
I think we need the baremetal numbers to be able to compare properly the old and
new
On 12/11/18 1:59 PM, Julien Grall wrote:
> Hi,
>
> On 11/12/2018 10:21, Razvan Cojocaru wrote:
>> On 12/11/18 12:14 PM, Roger Pau Monné wrote:
>>> On Tue, Dec 11, 2018 at 12:01:53PM +0200, Razvan Cojocaru wrote:
On 12/10/18 6:59 PM, Razvan Cojocaru wrote:
> On 12/10/18 6:49 PM, Roger Pau
flight 131192 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131192/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-examine 8 reboot fail REGR. vs. 128858
test-amd64-i386-xl-q
Hi. While I review the result of my research, suddenly a good idea comes
up, and I am looking for how to make threads in Xen like kthread in Linux
kernel.
However, after googling and searching for the source code by grep, I have
found only some information regarding stub domain and daemons, such a
>>> On 11.12.18 at 12:55, wrote:
> The out label is followed by a semicolon only. Use return directly.
>
> Signed-off-by: Wei Liu
Acked-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/
On Tue, 4 Dec 2018 18:20:11 +0400
Marc-André Lureau wrote:
> Instead of registering compat properties as globals, let's keep them
> in their own array, to avoid mixing with user globals.
>
> Introduce object_apply_global_props() function, to apply compatibility
> properties from a GPtrArray.
>
On Tue, Dec 11, 2018 at 09:40:35PM +0900, Minjun Hong wrote:
> Hi. While I review the result of my research, suddenly a good idea comes
> up, and I am looking for how to make threads in Xen like kthread in Linux
> kernel.
>
> However, after googling and searching for the source code by grep, I hav
On Mon, Dec 10, 2018 at 11:05:34AM -0800, Maran Wilson wrote:
> For certain applications it is desirable to rapidly boot a KVM virtual
> machine. In cases where legacy hardware and software support within the
> guest is not needed, Qemu should be able to boot directly into the
> uncompressed Linux
On Tue, Dec 11, 2018 at 01:17:06PM +, Wei Liu wrote:
> On Tue, Dec 11, 2018 at 09:40:35PM +0900, Minjun Hong wrote:
> > Hi. While I review the result of my research, suddenly a good idea comes
> > up, and I am looking for how to make threads in Xen like kthread in Linux
> > kernel.
> >
> > How
On Mon, Dec 10, 2018 at 11:07:28AM -0800, Maran Wilson wrote:
> In order to pave the way for hypervisors other than Xen to use the PVH
> entry point for VMs, we need to factor the PVH entry code into Xen specific
> and hypervisor agnostic components. The first step in doing that, is to
> create a n
flight 131198 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131198/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-xtf-amd64-amd64-3 69 xtf/test-hvm64-xsa-278 fail REGR. vs. 130985
Tests which did no
Hi Christoffer,
On 05/12/2018 22:35, Christopher Clark wrote:
On Wed, Dec 5, 2018 at 9:20 AM Julien Grall wrote:
On 04/12/2018 09:08, Christopher Clark wrote:
On Sun, Dec 2, 2018 at 12:11 PM Julien Grall wrote:
On 01/12/2018 01:32, Christopher Clark wrote:
diff --git a/xen/include/public/a
On Wed, Dec 05, 2018 at 10:37:24PM +, Liam Merwick wrote:
> From: Liam Merwick
>
> The x86/HVM direct boot ABI permits Qemu to be able to boot directly
> into the uncompressed Linux kernel binary without the need to run firmware.
>
> https://xenbits.xen.org/docs/unstable/misc/pvh.html
Hi Christopher,
On 04/12/2018 09:03, Christopher Clark wrote:
On Sun, Dec 2, 2018 at 11:55 AM Julien Grall wrote:
Hi,
On 01/12/2018 01:33, Christopher Clark wrote:
* x86 PV domains are notified via event channel.
PV guests are known to have the event channel software present in the guest
k
On Wed, Dec 05, 2018 at 10:37:25PM +, Liam Merwick wrote:
> From: Liam Merwick
>
> Add support to read the PVH Entry address from an ELF note in the
> uncompressed kernel binary (as defined by the x86/HVM direct boot ABI).
> This 32-bit entry point will be used by QEMU to load the kernel in t
Hi Andrii,
On 28/11/2018 21:32, Andrii Anisov wrote:
From: Andrii Anisov
This action is excessive because for an invalid LR there is no need
to write another invalid value to a register. So we can skip it here,
saving a peripheral register access.
Signed-off-by: Andrii Anisov
---
xen/arch/
Hi Andrii,
On 28/11/2018 21:32, Andrii Anisov wrote:
From: Andrii Anisov
An IRQ assigned to guest always has an action. This removes
another odd check on guest IRQ path.
And you can't see any potential race in that code happening in the future?
Also getting an unknown
interrupt is very unl
Hi Stefano,
On 03/12/2018 21:03, Stefano Stabellini wrote:
From: "Edgar E. Iglesias"
From: Edgar E. Iglesias
Introduce platform_smc as a way to handle firmware calls that Xen does
not know about in a platform specific way. This is particularly useful
for implementing the SiP (SoC implementat
>>> On 10.12.18 at 18:04, wrote:
> See the code comment for a full discussion, but in short: guests which
> currently run under Xen don't move the window, because moving it has never
> worked properly. Implementing support for moving the window is never going to
> work architecturally unless we s
On 11/12/2018 14:01, Stefan Hajnoczi wrote:
On Wed, Dec 05, 2018 at 10:37:24PM +, Liam Merwick wrote:
From: Liam Merwick
The x86/HVM direct boot ABI permits Qemu to be able to boot directly
into the uncompressed Linux kernel binary without the need to run firmware.
https://xenbi
On Tue, Dec 11, 2018 at 02:57:29PM +, Liam Merwick wrote:
>
>
> On 11/12/2018 14:01, Stefan Hajnoczi wrote:
> > On Wed, Dec 05, 2018 at 10:37:24PM +, Liam Merwick wrote:
> > > From: Liam Merwick
> > >
> > > The x86/HVM direct boot ABI permits Qemu to be able to boot directly
> > > into
Hi Stefano,
On 03/12/2018 21:03, Stefano Stabellini wrote:
From: "Edgar E. Iglesias"
From: Edgar E. Iglesias
Introduce zynqmp_eemi: a function responsible for implementing access
controls over the firmware calls. Only calls that are allowed are
forwarded to the firmware.
Signed-off-by: Edga
Am Fri, 23 Nov 2018 15:54:49 +
schrieb Anthony PERARD :
> On Thu, Nov 22, 2018 at 11:03:45AM +0100, Olaf Hering wrote:
> > qemu-system-i386: block/block-backend.c:903: blk_get_attached_dev_id:
> > Assertion `!blk->legacy_dev' failed.
> xen-disk (qdisk) is currently using legacy stuff in QEMU,
>>> On 05.12.18 at 15:54, wrote:
> To note it's calculating the approximate amount of memory required by
> shadow paging.
I don't understand this logic, and ...
> @@ -325,7 +325,7 @@ unsigned long __init dom0_compute_nr_pages(
> break;
>
> /* Reserve memory for shadow or
On Tue, Dec 11, 2018 at 10:47:03AM +, Paul Durrant wrote:
> This patch adds new XenDevice-s: 'xen-disk' and 'xen-cdrom', both derived
> from a common 'xen-block' parent type. These will eventually replace the
> 'xen_disk' (note the underscore rather than hyphen) legacy PV backend but
> it is il
>>> On 05.12.18 at 15:55, wrote:
> +unsigned long __init dom0_hap_pages(const struct domain *d,
> +unsigned long nr_pages)
> +{
> +/*
> + * Attempt to account for at least some of the MMIO regions by adding the
> + * size of the holes in the memory m
On Tue, Dec 11, 2018 at 10:47:04AM +, Paul Durrant wrote:
> This patch adds a new source module, xen-bus-helper.c, which builds on
> basic libxenstore primitives to provide functions to create (setting
> permissions appropriately) and destroy xenstore areas, and functions to
> 'printf' and 'sca
On Tue, Dec 11, 2018 at 08:08:51AM -0700, Jan Beulich wrote:
> >>> On 05.12.18 at 15:54, wrote:
> > To note it's calculating the approximate amount of memory required by
> > shadow paging.
>
> I don't understand this logic, and ...
>
> > @@ -325,7 +325,7 @@ unsigned long __init dom0_compute_nr_p
Hi,
On 03/12/2018 21:03, Stefano Stabellini wrote:
From: "Edgar E. Iglesias"
From: Edgar E. Iglesias
Introduce zynqmp specific defines for the firmware calls.
See EEMI:
https://www.xilinx.com/support/documentation/user_guides/ug1200-eemi-api.pdf
The error codes are described, under XIlPM Er
On Tue, Dec 11, 2018 at 10:47:05AM +, Paul Durrant wrote:
> A Xen PV frontend communicates its state to the PV backend by writing to
> the 'state' key in the frontend area in xenstore. It is therefore
> necessary for a XenDevice implementation to be notified whenever the
> value of this key cha
On Tue, Dec 11, 2018 at 10:47:07AM +, Paul Durrant wrote:
> The legacy PV backend infrastructure provides functions to bind, unbind
> and send notifications to event channnels. Similar functionality will be
> required by XenDevice implementations so this patch adds the necessary
> support.
>
>
On Tue, Dec 11, 2018 at 10:47:09AM +, Paul Durrant wrote:
> v2:
> - Leave existing boilerplate alone, other than removing the now-incorrect
>description
> ---
> hw/block/dataplane/xen-block.c | 409
> ++---
> 1 file changed, 16 insertions(+), 393 delet
What are the live time rules of ioreq->buf?
In my testing the memory usage of qemu is constantly growing from about
250MB to several GB after a few days.
Some debugging shows that ioreq_runio_qemu_aio() overwrites ioreq->buf,
which contributes to the leak. In addition, ioreq_reset() also just
glo
>>> On 11.12.18 at 16:19, wrote:
> On Tue, Dec 11, 2018 at 08:08:51AM -0700, Jan Beulich wrote:
>> >>> On 05.12.18 at 15:54, wrote:
>> > To note it's calculating the approximate amount of memory required by
>> > shadow paging.
>>
>> I don't understand this logic, and ...
>>
>> > @@ -325,7 +325,
On Tue, Dec 11, 2018 at 08:19:34AM -0700, Jan Beulich wrote:
> >>> On 05.12.18 at 15:55, wrote:
> > +unsigned long __init dom0_hap_pages(const struct domain *d,
> > +unsigned long nr_pages)
> > +{
> > +/*
> > + * Attempt to account for at least some of t
Hi,
On 03/12/2018 21:03, Stefano Stabellini wrote:
From: "Edgar E. Iglesias"
From: Edgar E. Iglesias
Introduce data structs to implement basic access controls.
Introduce the following three functions:
domain_has_node_access: check access to the node
domain_has_reset_access: check access to
> -Original Message-
> From: Anthony PERARD [mailto:anthony.per...@citrix.com]
> Sent: 11 December 2018 15:30
> To: Paul Durrant
> Cc: qemu-de...@nongnu.org; qemu-bl...@nongnu.org; xen-
> de...@lists.xenproject.org; Kevin Wolf ; Stefano
> Stabellini ; Stefan Hajnoczi
> ; Max Reitz
> Subje
> -Original Message-
> From: Anthony PERARD [mailto:anthony.per...@citrix.com]
> Sent: 11 December 2018 15:17
> To: Paul Durrant
> Cc: qemu-de...@nongnu.org; qemu-bl...@nongnu.org; xen-
> de...@lists.xenproject.org; Kevin Wolf ; Max Reitz
> ; Stefano Stabellini
> Subject: Re: [PATCH v3 03
On Fri, Dec 07, Olaf Hering wrote:
> [ the math added to xen-tscmode.7 suggests that a domU should see a time
> drift, which ntpd corrects. But the actual correction reported in
> ntp.drift is entirely different than the one calculated in the
> example. To me it is unclear why the example is
> -Original Message-
> From: Anthony PERARD [mailto:anthony.per...@citrix.com]
> Sent: 11 December 2018 15:25
> To: Paul Durrant
> Cc: qemu-de...@nongnu.org; qemu-bl...@nongnu.org; xen-
> de...@lists.xenproject.org
> Subject: Re: [PATCH v3 07/18] xen: add event channel interface for
> XenD
Hi Stefano,
On 03/12/2018 21:03, Stefano Stabellini wrote:
From: "Edgar E. Iglesias"
From: Edgar E. Iglesias
zynqmp_eemi uses the defined functions and structs to decide whether to
make a call to the firmware, or to simply return a predefined value.
Signed-off-by: Edgar E. Iglesias
Signed-
This series introduces a new QOM compliant framework for Xen PV backends.
This is achieved by first moving the current non-compliant framework aside,
before building up a new framework incrementally.
This series was prompted by a thread [1] started by Kevin Wolf in response
to patches against xen_
The legacy PV backend infrastructure provides functions to bind, unbind
and send notifications to event channnels. Similar functionality will be
required by XenDevice implementations so this patch adds the necessary
support.
Signed-off-by: Paul Durrant
Reviewed-by: Anthony Perard
---
Cc: Stefano
A Xen PV frontend communicates its state to the PV backend by writing to
the 'state' key in the frontend area in xenstore. It is therefore
necessary for a XenDevice implementation to be notified whenever the
value of this key changes.
This patch adds code to do this as follows:
- an 'fd handler'
This patch adds the basic boilerplate for a 'XenBus' object that will act
as a parent to 'XenDevice' PV backends.
A new 'XenBridge' object is also added to connect XenBus to the system bus.
The XenBus object is instantiated by a new xen_bus_init() function called
from the same sites as the legacy
Not all of the code duplicated from xen_disk.c is required as the basis for
the new dataplane implementation so this patch removes extraneous code,
along with the legacy #includes and calls to the legacy xen_pv_printf()
function. Error messages are changed to be reported using error_report().
NOTE
The legacy PV backend infrastructure provides functions to map, unmap and
copy pages granted by frontends. Similar functionality will be required
by XenDevice implementations so this patch adds the necessary support.
Signed-off-by: Paul Durrant
Reviewed-by: Anthony Perard
---
Cc: Stefano Stabell
This patch adds new XenDevice-s: 'xen-disk' and 'xen-cdrom', both derived
from a common 'xen-block' parent type. These will eventually replace the
'xen_disk' (note the underscore rather than hyphen) legacy PV backend but
it is illustrative to build up the implementation incrementally, along with
th
This patch adds a new source module, xen-bus-helper.c, which builds on
basic libxenstore primitives to provide functions to create (setting
permissions appropriately) and destroy xenstore areas, and functions to
'printf' and 'scanf' nodes therein. The main xen-bus code then uses
these primitives [1
The new xen-block XenDevice implementation requires the same core
dataplane as the legacy xen_disk implementation it will eventually replace.
This patch therefore copies the legacy xen_disk.c source module into a new
dataplane/xen-block.c source module as the basis for the new dataplane and
adjusts
...and xen_backend.h to xen-legacy-backend.h
Rather than attempting to convert the existing backend infrastructure to
be QOM compliant (which would be hard to do in an incremental fashion),
subsequent patches will introduce a completely new framework for Xen PV
backends. Hence it is necessary to r
This patch adds the transformations necessary to get dataplane/xen-block.c
to build against the new XenBus/XenDevice framework. MAINTAINERS is also
updated due to the introduction of dataplane/xen-block.h.
NOTE: Existing data structure names are retained for the moment. These will
be modifie
...and wire in the dataplane.
This patch adds the remaining code to make the xen-block XenDevice
functional. The parameters that a block frontend expects to find are
populated in the backend xenstore area, and the 'ring-ref' and
'event-channel' values specified in the frontend xenstore area are
ma
I have made many significant contributions to the Xen code in QEMU,
particularly the recent patches introducing a new PV device framework.
I intend to make further significant contributions, porting other PV back-
ends to the new framework with the intent of eventually removing the
legacy code. It
...that maintains compatibility with existing Xen toolstacks.
Xen toolstacks instantiate PV backends by simply writing information into
xenstore and expecting a backend implementation to be watching for this.
This patch adds a new 'xen-backend' module to allow individual XenDevice
implementations
1 - 100 of 154 matches
Mail list logo
