On Tue, Jan 8, 2019 at 2:54 PM Jason Andryuk wrote:
>
> On Mon, Jan 7, 2019 at 2:43 AM Christopher Clark
> wrote:
> >
> > Initialises basic data structures and performs teardown of argo state
> > for domain shutdown.
> >
> > Inclusion of the Argo implementation is dependent on CONFIG_ARGO.
> >
>
flight 131846 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131846/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i3866 xen-buildfail REGR. vs. 129475
build-i386-xsm
flight 131791 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131791/
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 broken in
131775
branch xen-unstable
xenbranch xen-unstable
job build-amd64
testid xen-build
Tree: ovmf https://github.com/tianocore/edk2.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
*** Found and reproduced
flight 131838 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131838/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i3866 xen-buildfail REGR. vs. 129475
build-i386-xsm
flight 131801 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131801/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 131788
test-armhf-armhf-libvirt 14
flight 131811 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131811/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i3866 xen-buildfail REGR. vs. 129475
build-i386-xsm
On Mon, Jan 7, 2019 at 2:43 AM Christopher Clark
wrote:
>
> Initialises basic data structures and performs teardown of argo state
> for domain shutdown.
>
> Inclusion of the Argo implementation is dependent on CONFIG_ARGO.
>
> Introduces a new Xen command line parameter 'argo': bool to
flight 131787 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131787/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-livepatch broken
Tests which are
branch xen-unstable
xenbranch xen-unstable
job build-i386
testid xen-build
Tree: ovmf https://github.com/tianocore/edk2.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
*** Found and reproduced
On Tue, Jan 8, 2019 at 2:09 PM Ross Philipson wrote:
>
> On 01/07/2019 02:42 AM, Christopher Clark wrote:
> > Initialises basic data structures and performs teardown of argo state
> > for domain shutdown.
> >
> > Inclusion of the Argo implementation is dependent on CONFIG_ARGO.
> >
> > Introduces
On 01/07/2019 02:42 AM, Christopher Clark wrote:
> Initialises basic data structures and performs teardown of argo state
> for domain shutdown.
>
> Inclusion of the Argo implementation is dependent on CONFIG_ARGO.
>
> Introduces a new Xen command line parameter 'argo': bool to enable/disable
>
On Sun, 6 Jan 2019, Christopher Clark wrote:
> ARM port of c/s bb544585: "introduce guest_handle_for_field()"
>
> This helper turns a field of a GUEST_HANDLE into a GUEST_HANDLE.
>
> Signed-off-by: Christopher Clark
> Reviewed-by: Paul Durrant
Reviewed-by: Stefano Stabellini
> ---
>
flight 131829 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131829/
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
flight 131786 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131786/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-arndale broken
test-amd64-amd64-xl-qemut-win10-i386
On Tue, 8 Jan 2019, Jan Beulich wrote:
> >>> On 08.01.19 at 09:30, wrote:
> >> -Original Message-
> > [snip]
> >> >
> >> > The use of iommu_use_hap_pt() here is indeed a problem, but I think it
> >> would be sufficient to move the line "hd->status =
> >> IOMMU_STATUS_initializing" to
Hi,
Sorry for the formatting.
On Tue, 8 Jan 2019, 13:09 Stefano Stabellini,
wrote:
> On Tue, 8 Jan 2019, Stefano Stabellini wrote:
> > On Tue, 8 Jan 2019, Jan Beulich wrote:
> > > >>> On 07.01.19 at 19:29, wrote:
> > > > On Mon, 7 Jan 2019, Jan Beulich wrote:
> > > >> >>> On 04.01.19 at
On Tue, 8 Jan 2019, Jan Beulich wrote:
> >>> On 07.01.19 at 20:16, wrote:
> > On Mon, 7 Jan 2019, Jan Beulich wrote:
> >> >>> On 03.01.19 at 20:19, wrote:
> >> > --- a/xen/common/virtual_region.c
> >> > +++ b/xen/common/virtual_region.c
> >> > @@ -119,7 +119,11 @@ void __init
On Tue, 8 Jan 2019, Stefano Stabellini wrote:
> On Tue, 8 Jan 2019, Jan Beulich wrote:
> > >>> On 07.01.19 at 19:29, wrote:
> > > On Mon, 7 Jan 2019, Jan Beulich wrote:
> > >> >>> On 04.01.19 at 18:05, wrote:
> > >> > I realize that you are not convinced by these arguments, but let's find
> > >>
Hi all,
just before XMas Stefano (Xilinx), Alex (EPAM), Artem (EPAM), Matt (Arm),
Guilio (Xilinx) and Munakata San (Renesas) and me had a quick call see whether
from a Xen Project community perspective, it would be possible to make
significant progress towards making more easily Xen Safety
On Tue, 8 Jan 2019, Jan Beulich wrote:
> >>> On 07.01.19 at 20:33, wrote:
> > On Mon, 7 Jan 2019, Jan Beulich wrote:
> >> >>> On 03.01.19 at 20:19, wrote:
> >> > --- a/xen/arch/x86/alternative.c
> >> > +++ b/xen/arch/x86/alternative.c
> >> > @@ -194,7 +194,7 @@ void init_or_livepatch
On Tue, 8 Jan 2019, Jan Beulich wrote:
> >>> On 07.01.19 at 19:29, wrote:
> > On Mon, 7 Jan 2019, Jan Beulich wrote:
> >> >>> On 04.01.19 at 18:05, wrote:
> >> > I realize that you are not convinced by these arguments, but let's find
> >> > a way forward. My preference would be to have SYMBOL
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2018-19967 / XSA-282
version 2
guest use of HLE constructs may lock up host
UPDATES IN VERSION 2
CVE assigned.
ISSUE DESCRIPTION
>>> On 08.01.19 at 17:37, wrote:
> On 1/8/19 6:27 PM, Jan Beulich wrote:
> On 19.12.18 at 19:52, wrote:
>>> Signed-off-by: Petre Pircalabu
>>
>> An empty description is not helpful. The immediate question is: Why?
>> We don't do this for other interface versions. I'm unconvinced a
>>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2018-19965 / XSA-279
version 3
x86: DoS from attempting to use INVPCID with a non-canonical addresses
UPDATES IN VERSION 3
CVE assigned.
ISSUE DESCRIPTION
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2018-19964 / XSA-277
version 3
x86: incorrect error handling for guest p2m page removals
UPDATES IN VERSION 3
CVE assigned.
ISSUE DESCRIPTION
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2018-19966 / XSA-280
version 3
Fix for XSA-240 conflicts with shadow paging
UPDATES IN VERSION 3
CVE assigned.
ISSUE DESCRIPTION
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2018-19961,CVE-2018-19962 / XSA-275
version 3
insufficient TLB flushing / improper large page mappings with AMD IOMMUs
UPDATES IN VERSION 3
CVEs assigned.
ISSUE
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2018-19963 / XSA-276
version 3
resource accounting issues in x86 IOREQ server handling
UPDATES IN VERSION 3
CVE assigned.
ISSUE DESCRIPTION
On 1/8/19 6:27 PM, Jan Beulich wrote:
On 19.12.18 at 19:52, wrote:
Signed-off-by: Petre Pircalabu
An empty description is not helpful. The immediate question is: Why?
We don't do this for other interface versions. I'm unconvinced a
special purpose piece of information like this one belongs
>>> On 19.12.18 at 19:52, wrote:
> Signed-off-by: Petre Pircalabu
An empty description is not helpful. The immediate question is: Why?
We don't do this for other interface versions. I'm unconvinced a
special purpose piece of information like this one belongs into the
rather generic version
> -Original Message-
> From: Petre Ovidiu PIRCALABU [mailto:ppircal...@bitdefender.com]
> Sent: 08 January 2019 16:14
> To: Paul Durrant ; xen-devel@lists.xenproject.org
> Cc: Stefano Stabellini ; Wei Liu
> ; Razvan Cojocaru ; Konrad
> Rzeszutek Wilk ; George Dunlap
> ; Andrew Cooper ; Ian
>>> On 19.12.18 at 19:52, wrote:
> @@ -796,7 +787,7 @@ struct xen_domctl_gdbsx_domstatus {
> * EXDEV - guest has PoD enabled
> * EBUSY - guest has or had paging enabled, ring buffer still active
> */
> -#define XEN_DOMCTL_VM_EVENT_OP_PAGING1
> +#define XEN_VM_EVENT_TYPE_PAGING
>>> On 28.12.18 at 13:39, wrote:
> Future changes are going to want to use cpu_bug_* in a mannor similar to
> Linux. Introduce one bug word, and generalise the calculation of
> NCAPINTS.
As said elsewhere, unless for the purpose of alternatives patching
I'm not convinced of the benefits of this
>>> On 28.12.18 at 13:39, wrote:
> This reduces the complexity of init_amd(), and collects related
> workarounds together.
>
> It also offers us the opportunity to stop performing workarounds when
> virtualised - doing so is wasteful, as it all involves poking MSRs which
> no hypervisor will let
On Tue, 2019-01-08 at 15:08 +, Paul Durrant wrote:
> >
> >
> > Also, for the current vm_event implementation, other than using the
> > hvm_params to specify the ring page gfn, I couldn't see any reason
> > why
> > it should be limited to HVM guests only. Is it feasible to assume
> > the
> >
>>> On 08.01.19 at 16:45, wrote:
> Currently dma_bitsize is zero by default on single NUMA node machines.
> This makes all alloc_domheap_pages() calls with MEMF_no_dma return NULL.
>
> There is only 1 user of MEMF_no_dma: dom0_memflags, which are used
> during memory allocation for Dom0. Failing
>>> On 07.01.19 at 08:42, wrote:
> A convenience for working on development of the argo subsystem:
> setting a #define variable enables additional debug messages.
>
> Signed-off-by: Christopher Clark
Acked-by: Jan Beulich
with one further remark:
> --- a/xen/common/argo.c
> +++
>>> On 07.01.19 at 08:42, wrote:
> Defines CONFIG_ARGO when enabled. Default: disabled.
>
> When the Kconfig option is enabled, the Argo hypercall implementation
> will be included, allowing use of the hypervisor-mediated interdomain
> communication mechanism.
>
> Argo is implemented for x86
Currently dma_bitsize is zero by default on single NUMA node machines.
This makes all alloc_domheap_pages() calls with MEMF_no_dma return NULL.
There is only 1 user of MEMF_no_dma: dom0_memflags, which are used
during memory allocation for Dom0. Failing allocation with default
dom0_memflags is
Am 08.01.2019 um 15:20 hat Paul Durrant geschrieben:
> > -Original Message-
> > From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
> > Of Paul Durrant
> > Sent: 08 January 2019 14:11
> > To: Anthony Perard
> > Cc: 'Kevin Wolf' ; Stefano Stabellini
> > ;
Currently the viridian_domain and viridian_vcpu structures are inline in
the hvm_domain and hvm_vcpu structures respectively. Subsequent patches
will need to add sizable extra fields to the viridian structures which
will cause the PAGE_SIZE limit of the overall vcpu structure to be
exceeded. This
Currently the time module lacks vcpu context save helpers and the synic
module lacks domain context save helpers. These helpers are not yet
required but subsequent patches will require at least some of them so this
patch completes the set to avoid introducing them in an ad-hoc way.
Signed-off-by:
This patch introduces an implementation of the SCONTROL, SVERSION, SIEFP,
SIMP, EOM and SINT0-15 SynIC MSRs. No message source is added and, as such,
nothing will yet generate a synthetic interrupt. A subsequent patch will
add an implementation of synthetic timers which will need the
This patch simply adds domain and vcpu init/deinit hooks into the synic
and time modules and wires them into viridian_[domain|vcpu]_[init|deinit]().
Only one of the hooks is currently needed (to unmap the 'VP Assist' page)
but subsequent patches will make use of the others.
NOTE: To perform the
Whilst the reference tsc page does not currently need to be kept mapped
after it is initially set up (or updated after migrate), the code can
be simplified by using the common guest page map/unmap and dump functions.
New functionality added by a subsequent patch will also require the page to
kept
This patch introduces an implementation of the STIMER0-15_CONFIG/COUNT MSRs
and hence a the first SynIC message source.
The new (and documented) 'stimer' viridian enlightenment group may be
specified to enable this feature.
NOTE: It is necessary for correct operation that timer expiration and
This patch adds domain and vcpu init hooks for viridian features. The init
hooks do not yet do anything; the functionality will be added to by
subsequent patches.
NOTE: This patch also removes the call from the domain deinit function to
the vcpu deinit function, as this is not necessary.
...from arch_domain_shutdown/pause/unpause().
A subsequent patch will introduce an implementaion of synthetic timers
which will also need freeze/thaw hooks, so make the exported hooks more
generic and call through to (re-named and static) time_ref_count_freeze/thaw
functions.
NOTE: This patch
This is currently a fairly large feature gap between Xen and KVM.
Paul Durrant (8):
viridian: add init hooks
viridian: separately allocate domain and vcpu structures
viridian: extend init/deinit hooks into synic and time modules
viridian: add missing context save helpers into synic and
> -Original Message-
> From: Petre Ovidiu PIRCALABU [mailto:ppircal...@bitdefender.com]
> Sent: 08 January 2019 14:50
> To: Paul Durrant ; xen-devel@lists.xenproject.org
> Cc: Stefano Stabellini ; Wei Liu
> ; Razvan Cojocaru ; Konrad
> Rzeszutek Wilk ; George Dunlap
> ; Andrew Cooper ; Ian
On Wed, 2019-01-02 at 11:11 +, Wei Liu wrote:
> On Wed, Dec 19, 2018 at 08:52:05PM +0200, Petre Pircalabu wrote:
> > Define the type for each of the supported vm_event rings (paging,
> > monitor and sharing) and replace the ring param field with this
> > type.
> >
> > Replace
This patch adds create and destroy function for XenBlockDevice-s so that
they can be created automatically when the Xen toolstack instantiates a new
PV backend via xenstore. When the XenBlockDevice is created this way it is
also necessary to create a 'drive' which matches the configuration that
...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
...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
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 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 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 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 files
On Thu, 2018-12-20 at 12:05 +, Paul Durrant wrote:
> > -Original Message-
> >
> > The memory for the asynchronous ring and the synchronous channels
> > will
> > be allocated from domheap and mapped to the controlling domain
> > using the
> > foreignmemory_map_resource interface.
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
...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
On 02/01/2019 13:18, Stefan Hajnoczi wrote:
On Fri, Dec 21, 2018 at 08:03:52PM +, Liam Merwick wrote:
@@ -1336,7 +1470,7 @@ void pc_memory_init(PCMachineState *pcms,
int linux_boot, i;
MemoryRegion *ram, *option_rom_mr;
MemoryRegion *ram_below_4g, *ram_above_4g;
-
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().
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 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
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
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
On 02/01/2019 13:12, Stefan Hajnoczi wrote:
On Fri, Dec 21, 2018 at 08:03:50PM +, Liam Merwick wrote:
+while (note_type != elf_note_type) {
+nhdr_namesz = nhdr->n_namesz;
+nhdr_descsz = nhdr->n_descsz;
+
+elf_note_entry_offset = nhdr_size +
+
On 02/01/2019 13:06, Stefan Hajnoczi wrote:
On Fri, Dec 21, 2018 at 08:03:49PM +, Liam Merwick wrote:
diff --git a/include/hw/elf_ops.h b/include/hw/elf_ops.h
index 74679ff8da3a..37d20a3800c1 100644
--- a/include/hw/elf_ops.h
+++ b/include/hw/elf_ops.h
@@ -266,6 +266,7 @@ fail:
}
Hi Stefano,
[ Catching up on mail after vacation ]
On 03/01/2019 17:22, Stefano Garzarella wrote:
Hi Liam, Hi Maran,
I'm writing the optionrom to do PVH boot also with SeaBIOS.
It is almost complete and I'm testing it, but I have some issue with
QEMU -initrd parameter.
(It works correctly
> I've tested your patch and it does seem like the best way forward. I'll
> squash it in. Do you want me to put your S-o-b on the combined patch?
You can, I'll have to add it anyway when I'll prepare the pull request.
Thanks,
--
Anthony PERARD
___
On 1/7/19 8:30 PM, Eduardo Habkost wrote:
> Instead of verbose arrays with 4 lines for each entry, make each
> entry take only one line. This makes long arrays that couldn't
> fit in the screen become short and readable.
And we'll thank you for the next git diff :)
> -Original Message-
> From: Anthony PERARD [mailto:anthony.per...@citrix.com]
> Sent: 08 January 2019 13:28
> To: Paul Durrant
> Cc: 'Kevin Wolf' ; qemu-de...@nongnu.org; qemu-
> bl...@nongnu.org; xen-devel@lists.xenproject.org; Max Reitz
> ; Stefano Stabellini
> Subject: Re: [PATCH v7
On 1/7/19 8:30 PM, Eduardo Habkost wrote:
> stringify() is useful when we need to use macros in compat_props
> (like when we set virtio-baloon-pci.class=PCI_CLASS_MEMORY_RAM at
> pc_i440fx_1_0_machine_options()), but it is pointless when we are
> already providing a number literal.
>
> Replace
Hi all,
I noticed that I hadn't updated all the times in the meeting invite block.
>
> == Dial-in Information ==
>
> ## Future Community Call schedule
> Jan 9, Feb 13, Mar 12
>
> ## Meeting time
> 15:00 - 16:00 UTC
This is wrong and should read 16:00 - 17:00
>8:00 - 9:00 EDT
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
> Of Paul Durrant
> Sent: 08 January 2019 14:11
> To: Anthony Perard
> Cc: 'Kevin Wolf' ; Stefano Stabellini
> ; qemu-bl...@nongnu.org; qemu-de...@nongnu.org;
> Max Reitz ;
> -Original Message-
> From: Anthony PERARD [mailto:anthony.per...@citrix.com]
> Sent: 08 January 2019 13:28
> To: Paul Durrant
> Cc: 'Kevin Wolf' ; qemu-de...@nongnu.org; qemu-
> bl...@nongnu.org; xen-devel@lists.xenproject.org; Max Reitz
> ; Stefano Stabellini
> Subject: Re: [PATCH v7
flight 131792 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131792/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt 7 xen-boot fail REGR. vs. 131766
Tests which did not
branch xen-unstable
xenbranch xen-unstable
job build-amd64-xsm
testid xen-build
Tree: ovmf https://github.com/tianocore/edk2.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
*** Found and
On Tue, Jan 08, 2019 at 01:07:49PM +, Paul Durrant wrote:
> > -Original Message-
> > From: Kevin Wolf [mailto:kw...@redhat.com]
> > Sent: 08 January 2019 12:53
> > To: Paul Durrant
> > Cc: Anthony Perard ; qemu-de...@nongnu.org;
> > qemu-bl...@nongnu.org;
> -Original Message-
> From: Kevin Wolf [mailto:kw...@redhat.com]
> Sent: 08 January 2019 12:53
> To: Paul Durrant
> Cc: Anthony Perard ; qemu-de...@nongnu.org;
> qemu-bl...@nongnu.org; xen-devel@lists.xenproject.org; Max Reitz
> ; Stefano Stabellini
> Subject: Re: [PATCH v7 16/18] xen:
Am 04.01.2019 um 17:40 hat Paul Durrant geschrieben:
> > -Original Message-
> > From: Anthony PERARD [mailto:anthony.per...@citrix.com]
> > Sent: 04 January 2019 16:31
> > To: Paul Durrant
> > Cc: qemu-de...@nongnu.org; qemu-bl...@nongnu.org; xen-
> > de...@lists.xenproject.org; Kevin
Did anyone have any agenda items *NOT* related to 4.12?
As an aside: I added the following to the agenda
* 4.12 what headline features made it
* Face 2 face to discuss a plan and implications for safety certification
(separate e-mail will follow today)
Regards
Lars
> On 7 Jan 2019, at 18:33,
flight 131796 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131796/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i3866 xen-buildfail REGR. vs. 129475
build-i386-xsm
flight 131803 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131803/
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 07/01/2019 12:05, Jan Beulich wrote:
On 07.01.19 at 12:27, wrote:
>> Currently dma_bitsize is zero by default on single NUMA node machines.
>> This makes all alloc_domheap_pages() calls with MEMF_no_dma return NULL.
>>
>> There is only 1 user of MEMF_no_dma: dom0_memflags, which are used
On Mon, 7 Jan 2019 17:30:20 -0200
Eduardo Habkost wrote:
> Instead of verbose arrays with 4 lines for each entry, make each
> entry take only one line. This makes long arrays that couldn't
> fit in the screen become short and readable.
>
> Signed-off-by: Eduardo Habkost
> ---
>
On Tue, 8 Jan 2019 07:45:43 +0100
Gerd Hoffmann wrote:
> Hi,
>
> > +{ "migration", "decompress-error-check", "off" },
> > +{ "hda-audio", "use-timer", "false" },
> > +{ "cirrus-vga", "global-vmstate", "true" },
> > +{ "VGA", "global-vmstate", "true" },
> > +{
flight 131782 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131782/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemut-rhel6hvm-amd broken
test-armhf-armhf-xl-vhd
On Mon, 7 Jan 2019 17:30:19 -0200
Eduardo Habkost wrote:
> stringify() is useful when we need to use macros in compat_props
> (like when we set virtio-baloon-pci.class=PCI_CLASS_MEMORY_RAM at
> pc_i440fx_1_0_machine_options()), but it is pointless when we are
> already providing a number
On Mon, 7 Jan 2019 17:30:18 -0200
Eduardo Habkost wrote:
> The macro is only used in one place, where the purpose of the
> value is obvious. Eliminate the macro so we don't need to rely
> on stringify().
>
> Signed-off-by: Eduardo Habkost
> ---
> include/hw/pci-host/spapr.h | 1 -
>
>>> On 02.01.19 at 13:44, wrote:
> On Fri, Dec 28, 2018 at 01:04:03PM +0100, Roger Pau Monne wrote:
>> This implies there's no need to forcefully reserve the VGA MMIO
>> region, since the memory map provided will be correct.
>>
>> Reported-by: Andrew Cooper
>> Signed-off-by: Roger Pau Monné
>
Hi Roger,
On 01/07/2019 11:27 PM, Roger Pau Monné wrote:
> On Mon, Jan 07, 2019 at 10:07:34PM +0800, Dongli Zhang wrote:
>>
>>
>> On 01/07/2019 10:05 PM, Dongli Zhang wrote:
>>>
>>>
>>> On 01/07/2019 08:01 PM, Roger Pau Monné wrote:
On Mon, Jan 07, 2019 at 01:35:59PM +0800, Dongli Zhang
Commit fd35f32b4b ("tools/x86emul: Use struct cpuid_policy in the
userspace test harnesses") didn't account for the dependencies of
cpuid-autogen.h to potentially change between incremental builds.
Putting the make invocation to produce the header together with the
directory tree creation
flight 131788 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131788/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 131743
test-armhf-armhf-libvirt 14
1 - 100 of 113 matches
Mail list logo
