>>> On 04.01.19 at 11:33, wrote:
> passthrough/x86 is tied to the x86 code, and as such put it under x86
> maintainership.
It is tied to both, so at the very least I object to ...
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -257,6 +257,7 @@ F:xen/drivers/passthrough/
> X:
>>> On 28.12.18 at 12:18, wrote:
> --- a/xen/arch/x86/hvm/dom0_build.c
> +++ b/xen/arch/x86/hvm/dom0_build.c
> @@ -60,6 +60,18 @@ static struct acpi_madt_interrupt_override __initdata
> *intsrcovr;
> static unsigned int __initdata acpi_nmi_sources;
> static struct acpi_madt_nmi_source
>>> 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 apply_alternatives(struct
> alt_instr *start,
> * So be careful if you want to change the scan order to any other
> * order.
> */
>>> On 02.01.19 at 11:43, wrote:
> On Mon, Dec 31, 2018 at 05:34:25PM +, Andrew Cooper wrote:
>> /* Sanity check, name should be "GNU" for ld-generated build-id. */
>> -if ( strncmp(ELFNOTE_NAME(n), "GNU", n->namesz) != 0 )
>> +if ( memcmp(ELFNOTE_NAME(n), "GNU", 4) != 0 )
>
>
Hi,
I just joined this list and am referring to
https://lists.xenproject.org/archives/html/xen-devel/2018-12/msg00938.html
We have experienced several crashes of a recent Debian 9 Dom0 on new
hardware with Xen version "4.8.4+xsa273+shim4.10.1+xsa273-1+deb9u10".
After reporting it within Debian
On Mon, Jan 07, 2019 at 01:35:58PM +0800, Dongli Zhang wrote:
> As 'be->blkif' is used for many times in connect_ring(), the stack variable
> 'blkif' is added to substitute 'be-blkif'.
>
> Suggested-by: Paul Durrant
> Signed-off-by: Dongli Zhang
Reviewed-by: Roger Pau Monné
On 01/07/2019 08:01 PM, Roger Pau Monné wrote:
> On Mon, Jan 07, 2019 at 01:35:59PM +0800, Dongli Zhang wrote:
>> The xenstore 'ring-page-order' is used globally for each blkback queue and
>> therefore should be read from xenstore only once. However, it is obtained
>> in read_per_ring_refs()
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
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:
...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
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
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
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().
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
> -Original Message-
> From: Wei Liu [mailto:wei.l...@citrix.com]
> Sent: 07 January 2019 15:48
> To: Paul Durrant
> Cc: Wei Liu ; xen-devel@lists.xenproject.org; Roger
> Pau Monne ; Jan Beulich ; Andrew
> Cooper
> Subject: Re: [PATCH 5/8] viridian: use viridian_map/unmap_guest_page()
Add a verbose option to the dom0 command line, so that dom0 builder
can print extra debug information when required.
Use this new verbose mode to print statistics about memory allocations
when populating dom0 p2m.
Signed-off-by: Roger Pau Monné
---
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian
>>> On 28.12.18 at 13:04, wrote:
> @@ -510,6 +496,12 @@ static void __init reserve_dmi_region(void)
> }
> }
>
> +static void __init reserve_vga_region(void)
> +{
> +/* Remove any RAM regions from the VGA hole. */
> +e820_remove_range(, KB(640), MB(1) - 1, E820_RAM, true);
From
On Mon, Jan 07, 2019 at 03:01:54AM -0700, Jan Beulich wrote:
> >>> On 28.12.18 at 12:18, wrote:
> > --- a/xen/arch/x86/hvm/dom0_build.c
> > +++ b/xen/arch/x86/hvm/dom0_build.c
> > @@ -60,6 +60,18 @@ static struct acpi_madt_interrupt_override __initdata
> > *intsrcovr;
> > static unsigned int
>>> On 28.12.18 at 13:04, wrote:
> --- a/xen/arch/x86/e820.c
> +++ b/xen/arch/x86/e820.c
> @@ -599,6 +599,63 @@ int __init e820_add_range(
> return 1;
> }
>
> +uint64_t __init e820_remove_range(struct e820map *e820, uint64_t start,
> + uint64_t end,
flight 131783 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131783/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
freebsd 2a52bc55467e95f92e1024cd558df3930df99594
baseline version:
freebsd
...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
On Fri, Jan 04, 2019 at 08:35:38AM -0700, Jan Beulich wrote:
> >>> On 04.01.19 at 16:14, wrote:
> > There's no reason to use long to store the alignment, since the bigger
>
> biggest?
>
> > page size is 1GB, and the alignment is stored as a frame number.
> >
> > Reported-by: Jan Beulich
> >
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
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 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
...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
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
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 1/7/19 4:26 PM, Tamas K Lengyel wrote:
Fix VGA logdirty with altp2m (v11) Razvan Cojocaru?
This has been merged already.
Indeed, sorry for only seeing this now - I've had a small technical
SNAFU I had to take care of today and missed some emails.
Thanks,
Razvan
> Fix VGA logdirty with altp2m (v11) Razvan Cojocaru?
This has been merged already.
Tamas
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
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 wrote:
> >>> The xenstore 'ring-page-order' is used globally
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
> Of Paul Durrant
> Sent: 03 January 2019 09:20
> To: Wei Liu
> Cc: xen-devel@lists.xenproject.org; Roger Pau Monne
> ; Wei Liu ; Jan Beulich
> ; Andrew Cooper
> Subject: Re: [Xen-devel]
On Mon, Jan 07, 2019 at 03:35:41PM +, Paul Durrant wrote:
[...]
> > > >const struct viridian_page *vp);
> > > > -void viridian_map_guest_page(struct vcpu *v, struct viridian_page
> > *vp);
> > > > +void viridian_map_guest_page(struct domain *d, struct
>>> On 07.01.19 at 17:22, wrote:
> Add a verbose option to the dom0 command line, so that dom0 builder
> can print extra debug information when required.
>
> Use this new verbose mode to print statistics about memory allocations
> when populating dom0 p2m.
>
> Signed-off-by: Roger Pau Monné
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
On Mon, Jan 07, 2019 at 02:56:23AM -0700, Jan Beulich wrote:
> >>> On 04.01.19 at 11:33, wrote:
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -259,6 +259,7 @@ X: xen/drivers/passthrough/arm/
> > X: xen/drivers/passthrough/vtd/
> > X: xen/drivers/passthrough/x86/
> > X:
>>> On 04.01.19 at 11:33, wrote:
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -259,6 +259,7 @@ X:xen/drivers/passthrough/arm/
> X: xen/drivers/passthrough/vtd/
> X: xen/drivers/passthrough/x86/
> X: xen/drivers/passthrough/device_tree.c
> +X: xen/drivers/passthrough/pci.c
Much
>>> On 04.01.19 at 16:33, wrote:
> --- a/xen/include/xen/lib/x86/cpuid.h
> +++ b/xen/include/xen/lib/x86/cpuid.h
> @@ -319,6 +319,27 @@ typedef xen_cpuid_leaf_t cpuid_leaf_buffer_t[];
> int x86_cpuid_copy_to_buffer(const struct cpuid_policy *policy,
>
>>> On 04.01.19 at 16:33, wrote:
> The AFL harness currently notices that there are cases where we optimse the
> serialised stream by omitting data beyond the various maximum leaves.
>
> Both sets of tests will be extended with further libx86 work.
>
> Fix the sorting of the CPUID_GUEST_NR_*
Using plain int for string lengths, while okay for all practical
purposes, is undesirable in a generic library function.
Take the opportunity and also move the function from being in the middle
of mem*() ones to the set of str*() ones, convert its loop from while()
to for(), and correct style.
>>> On 03.01.19 at 20:19, wrote:
> --- a/xen/common/kernel.c
> +++ b/xen/common/kernel.c
> @@ -312,14 +312,18 @@ extern const initcall_t __initcall_start[],
> __presmp_initcall_end[],
> void __init do_presmp_initcalls(void)
> {
> const initcall_t *call;
> -for ( call =
Saving and restoring the value of this MSR is currently handled by
implementation-specific code despite it being architectural. This patch
moves handling of accesses to this MSR from hvm.c into the msr.c, thus
allowing the common MSR save/restore code to handle it.
This patch also changes
...to avoid the need for a VMCS reload when the value of MSR_IA32_BNDCFGS is
read by the tool-stack.
Signed-off-by: Paul Durrant
---
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Wei Liu
Cc: "Roger Pau Monné"
Cc: Jun Nakajima
Cc: Kevin Tian
---
xen/arch/x86/hvm/hvm.c | 18 +++---
...to avoid repeated open-coding.
Unfortunately the mapping from MSR index MSR_AMD64_DR_ADDRESS_MASK
to the 'idx' value is non-trivial since the MSR index corresponding to
idx value 0 is non-consecutive with the MSR indices corresponding to
idx values 1-3. This mapping is currently dealt with by
Saving and restoring the value of this MSR is currently handled by
implementation-specific code despite it being architectural. This patch
moves handling of accesses to this MSR from hvm.c into the msr.c, thus
allowing the common MSR save/restore code to handle it.
This patch also adds proper
Currently the value is saved directly in struct hvm_vcpu. This patch simply
co-locates it with other saved MSR values. No functional change.
Signed-off-by: Paul Durrant
---
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Wei Liu
Cc: "Roger Pau Monné"
Cc: Jun Nakajima
Cc: Kevin Tian
---
On 28/12/2018 15:41, Hans van Kranenburg wrote:
> On 12/28/18 11:15 AM, Juergen Gross wrote:
>> On 27/12/2018 22:12, Hans van Kranenburg wrote:
>>> So,
>>>
>>> On 12/24/18 1:32 AM, Hans van Kranenburg wrote:
On 12/21/18 6:54 PM, Hans van Kranenburg wrote:
>
> We've been tracking
Patch #6 is not strictly related to save/restore. It's just clean-up of
something I noticed along the way.
Paul Durrant (6):
x86: stop handling MSR_IA32_BNDCFGS save/restore in implementation
code
x86: save GUEST_BNDCFGS on context switch...
x86: move the saved value of MSR_IA32_XSS
These hvm_funcs are no longer required since no MSR values are saved or
restored by implementation-specific code.
Signed-off-by: Paul Durrant
---
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Wei Liu
Cc: "Roger Pau Monné"
---
xen/arch/x86/hvm/hvm.c| 31 ++-
>>> 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
> during memory allocation for Dom0. Failing
On 07/01/2019 12:41, Colin Watson wrote:
> Hi,
>
> I'm working on integrating the recently-merged PVH support for GRUB into
> the Debian packages. As a result I find myself thinking about how to
> handle the two-stage boot loader scheme that our packages currently
> implement for PV. I think
On 07/01/2019 10:39, Jan Beulich wrote:
> The pre-decrement would not only cause misbehavior when wrapping (benign
> because there shouldn't be any NULL pointers passed in), but may also
> create a pointer pointing outside the object that the passed in pointer
> points to (it won't be
flight 131784 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131784/
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 07.01.19 at 13:14, wrote:
> On Mon, Jan 07, 2019 at 02:51:54AM -0700, Jan Beulich wrote:
>> >>> On 04.01.19 at 11:33, wrote:
>> > passthrough/x86 is tied to the x86 code, and as such put it under x86
>> > maintainership.
>>
>> It is tied to both, so at the very least I object to ...
>>
>>> On 07.01.19 at 13:11, wrote:
> On Fri, Jan 04, 2019 at 10:03:21AM -0700, Jan Beulich wrote:
>> >>> On 04.01.19 at 11:33, wrote:
>> > It makes no sense for io.c to be on the top level passthrough
>> > directory, since it's x86 specific.
>>
>> I'm not sure it really is. It's largely about
On 07/01/2019 10:40, Jan Beulich wrote:
> Using plain int for string lengths, while okay for all practical
> purposes, is undesirable in a generic library function.
>
> Take the opportunity and also move the function from being in the middle
> of mem*() ones to the set of str*() ones, convert its
>>> On 31.12.18 at 18:34, wrote:
> A NT_GNU_BUILD_ID with namesz longer than 4 will cause the strncmp() to use
> bytes in adjacent stringtable entries.
>
> Instead, check for namesz exactly equal to 4,
Is that a requirement spelled out anywhere? Till now I've been
under the impression that e.g.
On 1/7/19 1:04 PM, Juergen Gross wrote:
> On 28/12/2018 15:41, Hans van Kranenburg wrote:
>> On 12/28/18 11:15 AM, Juergen Gross wrote:
>>
>> [...]
>> So that explains the 18446742891.874140 number, which just corresponds
>> to something near to 'minus 23 minutes'.
>
> I have a local reproducer
On 07/01/2019 13:56, Hans van Kranenburg wrote:
> On 1/7/19 1:04 PM, Juergen Gross wrote:
>> On 28/12/2018 15:41, Hans van Kranenburg wrote:
>>> On 12/28/18 11:15 AM, Juergen Gross wrote:
>>>
>>> [...]
>>> So that explains the 18446742891.874140 number, which just corresponds
>>> to something near
On 07/01/2019 10:39, Jan Beulich wrote:
> It has no users, so rather than fixing its use of types (first and
> foremost c would need to be cast to unsigned char in the comparison
> expression) drop it altogether. memchr() ought to be fine for all
> purposes.
>
> Take the opportunity and also do
On Mon, Jan 07, 2019 at 02:51:54AM -0700, Jan Beulich wrote:
> >>> On 04.01.19 at 11:33, wrote:
> > passthrough/x86 is tied to the x86 code, and as such put it under x86
> > maintainership.
>
> It is tied to both, so at the very least I object to ...
>
> > --- a/MAINTAINERS
> > +++
On Fri, Jan 04, 2019 at 10:03:21AM -0700, Jan Beulich wrote:
> >>> On 04.01.19 at 11:33, wrote:
> > It makes no sense for io.c to be on the top level passthrough
> > directory, since it's x86 specific.
>
> I'm not sure it really is. It's largely about interrupt arrangements
> for guests, which
flight 131772 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131772/
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.
125898
Am Fri, 4 Jan 2019 17:48:31 +0100
schrieb Olaf Hering :
> Am Fri, 4 Jan 2019 16:57:55 +0100
> schrieb Olaf Hering :
>
> > worth keeping (and fixing) the concept of an "offline migration"
>
> And regarding the fix, it looks like qmp_xen_save_devices_state does not need
> the concept of
>>> On 31.12.18 at 12:37, wrote:
> Passing a 32-bit integer index into an array with entries containing less than
> 32 bits of data is wasteful, and creates an unnecessary error condition of
> passing an out-of-range index.
>
> The width of the X86EMUL_OPC() encoding is at most 24 bits, which
On Mon, Jan 07, 2019 at 01:35:59PM +0800, Dongli Zhang wrote:
> The xenstore 'ring-page-order' is used globally for each blkback queue and
> therefore should be read from xenstore only once. However, it is obtained
> in read_per_ring_refs() which might be called multiple times during the
>
This patch aims to have mem access vm events sent from the emulator.
This is useful in the case of page-walks that have to emulate
instructions in access denied pages.
We use hvmemul_map_linear_addr() ro intercept r/w access and
hvmemul_insn_fetch() to intercept exec access.
First we try to send
>>> On 07.01.19 at 10:49, wrote:
> On 07/01/2019 10:39, Jan Beulich wrote:
>> The pre-decrement would not only cause misbehavior when wrapping (benign
>> because there shouldn't be any NULL pointers passed in), but may also
>> create a pointer pointing outside the object that the passed in
>>> On 03.01.19 at 20:19, wrote:
> Use SYMBOL in cases of comparisons and subtractions of:
>
> _start, _end, __init_begin, __init_end, __2M_text_end,
> __2M_rodata_start, __2M_rodata_end, __2M_init_start,__2M_init_end,
> __2M_rwdata_start, __2M_rwdata_end, _stext, _etext, _srodata, _erodata,
>
> On Jan 2, 2019, at 10:03 PM, Ian Jackson wrote:
>
> Coverity understandably complains that get_reaper_lock_and_uid leaks
> the fd and hence open-file. But this is intentional: the lock becomes
> owned by the child process as a whole, which is entirely the property
> of libxl.
>
> (The
>>> On 04.01.19 at 16:33, wrote:
> From: Roger Pau Monné
>
> Signed-off-by: Sergey Dyasli
> Signed-off-by: Roger Pau Monné
> Signed-off-by: Andrew Cooper
Where applicable, same comments here as for patch 1.
Jan
___
Xen-devel mailing list
On Thu, Dec 27, 2018 at 09:03:43PM +, Andrew Cooper wrote:
> On 27/12/2018 15:56, Roger Pau Monne wrote:
> > When running Xen as a guest it's not necessary to mark such pages as
> > RAM because they won't be assigned to the initial domain memory map.
> >
> > While there move the functions to
Hi,
I'm working on integrating the recently-merged PVH support for GRUB into
the Debian packages. As a result I find myself thinking about how to
handle the two-stage boot loader scheme that our packages currently
implement for PV. I think that it would not be very hard to do this for
PVH in
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 wrote:
>>> The xenstore 'ring-page-order' is used globally for each blkback queue and
>>> therefore should be read from xenstore only once.
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'
flight 131773 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131773/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 131755
Am Thu, 13 Dec 2018 11:05:25 +
schrieb Anthony PERARD :
> Hi,
>
> Ian, we have those XC_WANT_COMPAT_* #defines to allow consumers of Xen
> libs be able to use old interfaces. Do you think it's a good idea to
> have this consumers (QEMU here) #undef the flag when it has implemented
> the
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 apply_alternatives(struct
> > alt_instr *start,
> > * So be careful if you want to change the
On Mon, Jan 7, 2019 at 11:32 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.
On 07/01/2019 08:59, Jan Beulich wrote:
>> @@ -271,6 +297,27 @@ int parse_boolean(const char *name, const char *s,
>> const char *e)
>> return -1;
>> }
>>
>> +int cmdline_strcmp(const char *frag, const char *name)
> So you've decided to retain the strcmp()-like return type and value,
>
On Mon, 7 Jan 2019, Juergen Gross wrote:
> On 03/01/2019 15:28, Lars Kurth wrote:
> > Hi all,
> >
> > based on Stefano's and Julien's suggestion that it may make sense to merge
> > the x86 and arm calls, I am willing to try. It also makes sense this time
> > in particular because we are
Current declarations of compat_props arrays are very verbose,
with each entry taking 4 lines of code. By omitting the field
designators, we can make each array entry fit a single line of
code and be more readable.
Eduardo Habkost (3):
spapr: Eliminate SPAPR_PCI_2_7_MMIO_WIN_SIZE macro
On 07/01/2019 10:36, Jan Beulich wrote:
On 31.12.18 at 18:34, wrote:
>> A NT_GNU_BUILD_ID with namesz longer than 4 will cause the strncmp() to use
>> bytes in adjacent stringtable entries.
>>
>> Instead, check for namesz exactly equal to 4,
> Is that a requirement spelled out anywhere? Till
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 returning unsigned
> > long and do unsigned long comparisons when pointers pointing to
> >
On Mon, 7 Jan 2019, Paul Durrant wrote:
> > -Original Message-
> > From: Stefano Stabellini [mailto:sstabell...@kernel.org]
> > Sent: 04 January 2019 17:46
> > To: Paul Durrant
> > Cc: 'Stefano Stabellini' ; Andrew Cooper
> > ; xen-de...@lists.xen.org;
> > julien.gr...@arm.com;
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 stringify() with string literals when appropriate.
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 -
hw/ppc/spapr.c | 2 +-
2 files changed, 1 insertion(+), 2 deletions(-)
flight 131785 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131785/
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
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
---
include/hw/i386/pc.h | 18 +-
hw/core/machine.c | 338
On Mon, Jan 7, 2019 at 11:33 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.
>
> Signed-off-by: Eduardo Habkost
> ---
>
On Mon, 7 Jan 2019, Jan Beulich wrote:
> >>> On 03.01.19 at 20:19, wrote:
> > Use SYMBOL in cases of comparisons and subtractions of:
> >
> > _start, _end, __init_begin, __init_end, __2M_text_end,
> > __2M_rodata_start, __2M_rodata_end, __2M_init_start,__2M_init_end,
> > __2M_rwdata_start,
Remove duplicate header which is included twice.
Signed-off-by: Souptick Joarder
---
arch/arm/xen/mm.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c
index cb44aa2..e1d44b9 100644
--- a/arch/arm/xen/mm.c
+++ b/arch/arm/xen/mm.c
@@ -7,7 +7,6 @@
#include
On Mon, 7 Jan 2019, Jan Beulich wrote:
> >>> On 03.01.19 at 20:19, wrote:
> > --- a/xen/common/kernel.c
> > +++ b/xen/common/kernel.c
> > @@ -312,14 +312,18 @@ extern const initcall_t __initcall_start[],
> > __presmp_initcall_end[],
> > void __init do_presmp_initcalls(void)
> > {
> >
On Mon, Jan 7, 2019 at 11:34 PM 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
Reviewed-by: Marc-André Lureau
> ---
>
flight 131775 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131775/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt-pair broken
On Mon, Jan 07, 2019 at 05:30:18PM -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
Acked-by: David Gibson
> ---
>
1 - 100 of 118 matches
Mail list logo
