>>> On 11.12.18 at 19:16, wrote:
> BTW: Apart from the fact its ugly and take a lng time to complete, do you
> have any practical isssues you want to highlight? maybe that can
> help upstream as well.
The situation for a kernel and a hypervisor might be different here
(but in the Linux case
On Wed, Dec 05, 2018 at 09:01:33AM -0500, Boris Ostrovsky wrote:
>On 12/5/18 4:32 AM, Roger Pau Monné wrote:
>> On Wed, Dec 05, 2018 at 10:19:17AM +0800, Chao Gao wrote:
>>> I find some pass-thru devices don't work any more across guest reboot.
>>> Assigning it to another guest also meets the same
flight 131223 xen-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131223/
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
On Tue, Dec 11, 2018 at 10:01:11AM -0700, Jan Beulich wrote:
On 28.11.18 at 06:34, wrote:
>> This patch ports microcode improvement patches from linux kernel.
>>
>> Before you read any further: the early loading method is still the
>> preferred one and you should always do that. The
On Tue, Dec 11, 2018 at 10:03:10AM -0700, Jan Beulich wrote:
On 15.11.18 at 02:10, wrote:
>> I find some pass-thru devices don't work any more across guest
>> reboot. Assigning it to another domain also meets the same issue. And
>> the only way to make it work again is un-binding and binding
flight 131208 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131208/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR.
vs. 129313
branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-xl-qemuu-ovmf-amd64
testid xen-boot
Tree: linux
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu
flight 131204 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131204/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 7 xen-boot fail REGR. vs.
131145
flight 131219 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131219/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 131183
test-armhf-armhf-libvirt 14
flight 131246 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131246/
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
On Tue, 11 Dec 2018, Julien Grall wrote:
> 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
On Tue, Dec 4, 2018 at 4:00 AM Christopher Clark
wrote:
>
> On Mon, Dec 3, 2018 at 8:49 AM Chris Patterson wrote:
> >
> > > == Future items
> > >
> > > The Linux device driver used to test this software is derived from the
> > > OpenXT v4v Linux device driver, available at:
> > >
flight 131211 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131211/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm6 xen-buildfail REGR. vs. 129475
build-i386
On 11/12/2018 20:19, Stefano Stabellini wrote:
> On Tue, 11 Dec 2018, Julien Grall wrote:
>> Hi Stefano,
>>
>> On 11/12/2018 18:50, Stefano Stabellini wrote:
>>> On Tue, 11 Dec 2018, Julien Grall wrote:
Hi Stefano,
On 03/12/2018 21:03, Stefano Stabellini wrote:
> From: "Edgar
On Tue, 11 Dec 2018, Julien Grall wrote:
> Hi Stefano,
>
> On 11/12/2018 18:50, Stefano Stabellini wrote:
> > On Tue, 11 Dec 2018, Julien Grall wrote:
> > > Hi Stefano,
> > >
> > > On 03/12/2018 21:03, Stefano Stabellini wrote:
> > > > From: "Edgar E. Iglesias"
> > > >
> > > > From: Edgar E.
On Tue, Dec 11, 2018 at 1:18 PM Chris Brannon wrote:
>
> Christopher Clark writes:
>
> > On Tue, Dec 4, 2018 at 10:11 AM Chris Brannon wrote:
> >>
> >> Hi,
> >> I set up a network driver domain for a dom0; it uses HVM
> >> virtualization. It worked very well when not using a device model
> >>
flight 131239 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131239/
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
On 12/11/2018 5:18 AM, Borislav Petkov wrote:
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
On Tue, 11 Dec 2018, Julien Grall wrote:
> On 11/12/2018 18:39, Stefano Stabellini wrote:
> > On Tue, 11 Dec 2018, Julien Grall wrote:
> > > On 10/12/2018 12:23, Andrii Anisov wrote:
> > > > Hello Julien,
> > > >
> > > > On 10.12.18 13:54, Julien Grall wrote:
> > > > > What are the numbers
On Tue, 11 Dec 2018, Julien Grall wrote:
> 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:
> >
Hi Stefano,
On 11/12/2018 18:50, Stefano Stabellini wrote:
On Tue, 11 Dec 2018, Julien Grall wrote:
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
On 11/12/2018 18:39, Stefano Stabellini wrote:
On Tue, 11 Dec 2018, Julien Grall wrote:
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
On Tue, 11 Dec 2018, Julien Grall wrote:
> 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
On Tue, 11 Dec 2018, Julien Grall wrote:
> 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
On 12/11/2018 9:11 AM, Stefano Garzarella wrote:
Hi Liam,
in order to support PVH also with SeaBIOS, I'm going to work on a new
option rom (like linuxboot/multiboot) that can be used in this case.
That is awesome. Yes, please keep us posted when you have something working.
Just FYI, before
On Tue, Dec 11, 2018 at 10:01:11AM -0700, Jan Beulich wrote:
> >>> On 28.11.18 at 06:34, wrote:
> > This patch ports microcode improvement patches from linux kernel.
> >
> > Before you read any further: the early loading method is still the
> > preferred one and you should always do that. The
Christopher Clark writes:
> On Tue, Dec 4, 2018 at 10:11 AM Chris Brannon wrote:
>>
>> Hi,
>> I set up a network driver domain for a dom0; it uses HVM
>> virtualization. It worked very well when not using a device model
>> stubdomain, but when I requested the use of a device model stubdomain
On Fri, Oct 26, 2018 at 05:20:47AM -0600, Jan Beulich wrote:
> >>> On 26.10.18 at 12:51, wrote:
> > On 10/26/2018 10:56 AM, Jan Beulich wrote:
> > On 26.10.18 at 11:28, wrote:
> >>> On Fri, Oct 26, 2018 at 03:16:15AM -0600, Jan Beulich wrote:
> >>> On 25.10.18 at 18:29, wrote:
> > A
Patchew URL: https://patchew.org/QEMU/20181211160224.22181-1-o...@aepfle.de/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Message-id: 20181211160224.22181-1-o...@aepfle.de
Subject: [Qemu-devel] [PATCH v1] xen_disk: fix memory leak
Type:
>>> On 15.11.18 at 02:10, wrote:
> I find some pass-thru devices don't work any more across guest
> reboot. Assigning it to another domain also meets the same issue. And
> the only way to make it work again is un-binding and binding it to
> pciback. Someone reported this issue one year ago [1].
>
>>> On 28.11.18 at 06:34, wrote:
> This patch ports microcode improvement patches from linux kernel.
>
> Before you read any further: the early loading method is still the
> preferred one and you should always do that. The following patch is
> improving the late loading mechanism for long
On Tue, 2018-12-11 at 12:27 +, Julien Grall wrote:
> On 10/12/2018 12:23, Andrii Anisov wrote:
> > 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
On Tue, Dec 11, 2018 at 03:57:38PM +, Paul Durrant wrote:
> ...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'
On Tue, Dec 11, 2018 at 03:57:39PM +, Paul Durrant wrote:
> ...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
>>> On 11.12.18 at 12:56, wrote:
> Use __map_domain_page macro to deal with page_info directly.
>
> No functional change.
>
> Signed-off-by: Wei Liu
Acked-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
>>> On 11.12.18 at 12:56, wrote:
> Remove trailing whitespaces. Turn bool_t into bool. Annotate a section
> for CONFIG_SEPARATE_XENHEAP.
>
> Signed-off-by: Wei Liu
Acked-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
>>> On 10.12.18 at 12:52, wrote:
> The intention of this patch was to remove the calls to nsvm_{rd,wr}msr() from
> the default cases of svm_msr_{read,write}_intercept(), but it has turned into
> a more corrective patch than just code motion.
>
> First, collect the VM_CR bit definitions next to
flight 131234 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131234/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt18 guest-start/debian.repeat fail REGR. vs. 131225
Tests which
Hi Stefano,
On 07/12/2018 21:43, Stefano Stabellini wrote:
On Tue, 4 Dec 2018, Julien Grall wrote:
At the moment, the implementation of Set/Way operations will go through
all the entries of the guest P2M and flush them. However, this is very
expensive and may render unusable a guest OS using
>>> On 11.12.18 at 16:36, wrote:
> 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)
>> > +{
>> > +/*
>> > +
> -Original Message-
> From: Olaf Hering [mailto:o...@aepfle.de]
> Sent: 11 December 2018 16:08
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; qemu-de...@nongnu.org
> Subject: Re: [Xen-devel] memory leak in block/xen_disk in qemu-3.x
>
> On Tue, Dec 11, Paul Durrant wrote:
>
>
On Tue, Dec 11, 2018 at 10:47:14AM +, Paul Durrant wrote:
> ...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'
Hi,
On 07/12/2018 22:11, Stefano Stabellini wrote:
On Fri, 7 Dec 2018, Julien Grall wrote:
@@ -1547,6 +1551,25 @@ int p2m_cache_flush_range(struct domain *d, gfn_t
start, gfn_t end)
while ( gfn_x(start) < gfn_x(end) )
{
+ /*
+ * Cleaning the cache for the P2M may
On Tue, Dec 11, Paul Durrant wrote:
> > -Original Message-
> > From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
> > Of Olaf Hering
> > Sent: 11 December 2018 15:31
> > To: xen-devel@lists.xenproject.org; qemu-de...@nongnu.org
> > Subject: [Xen-devel] memory leak
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
> Of Olaf Hering
> Sent: 11 December 2018 15:08
> To: Anthony Perard
> Cc: xen-devel@lists.xenproject.org
> Subject: Re: [Xen-devel] qemu assert in staging during HVM live migration
>
> Am
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
> Of Olaf Hering
> Sent: 11 December 2018 15:31
> To: xen-devel@lists.xenproject.org; qemu-de...@nongnu.org
> Subject: [Xen-devel] memory leak in block/xen_disk in qemu-3.x
>
> What are the
There are some code paths that clobber ioreq->buf, which leads to a huge
memory leak after a few hours of runtime. One code path is
qemu_aio_complete, which might be called recursive. Another one is
ioreq_reset, which might clobber ioreq->buf as well.
Add wrappers to free ioreq->buf before
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'
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
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
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
...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
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
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
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
...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
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
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
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
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().
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 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
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:
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'
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
> -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
>
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
> -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
> -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
>
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
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
>>> 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
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
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
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: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
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
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
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
>>> 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
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
>>> 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
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
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:
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
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.
>>> 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
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
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
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
---
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
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
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 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
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
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
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.
> >
> >
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
1 - 100 of 148 matches
Mail list logo
