>>> On 04.01.19 at 18:00, wrote:
> The C spec requires that the comarison be done in terms of unsigned char.
>
> The code style in this file is terrible, but does claim to be Xen BSD style,
> so fix up these functions while rewriting them.
Where have you found this claim? The comment at the bott
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 approaching freeze time.
>
>
> As per request the meeting i
> -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; jbeul...@suse.com
> Subject: RE: [Xen-devel] [PATCH for-4.12] xen
>>> On 04.01.19 at 18:17, wrote:
> --- a/xen/arch/arm/efi/efi-boot.h
> +++ b/xen/arch/arm/efi/efi-boot.h
> @@ -212,7 +212,7 @@ EFI_STATUS __init fdt_add_uefi_nodes(EFI_SYSTEM_TABLE
> *sys_table,
> break;
>
> type = fdt_getprop(fdt, node, "device_type", &len);
> -if
Adding the introspection guys.
On Fri, Jan 04, 2019 at 08:47:04AM -0700, Jan Beulich wrote:
> >>> On 04.01.19 at 16:35, wrote:
> > On Fri, Jan 04, 2019 at 06:22:19AM -0700, Jan Beulich wrote:
> >> >>> On 04.01.19 at 09:57, wrote:
> >> > On Fri, Dec 21, 2018 at 03:05:03PM -0800, Christopher Clark
> -Original Message-
> From: Dongli Zhang [mailto:dongli.zh...@oracle.com]
> Sent: 07 January 2019 05:36
> To: xen-devel@lists.xenproject.org; linux-bl...@vger.kernel.org; linux-
> ker...@vger.kernel.org
> Cc: konrad.w...@oracle.com; Roger Pau Monne ;
> ax...@kernel.dk; Paul Durrant
> Subj
flight 131781 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131781/
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
> -Original Message-
> From: Dongli Zhang [mailto:dongli.zh...@oracle.com]
> Sent: 07 January 2019 05:36
> To: xen-devel@lists.xenproject.org; linux-bl...@vger.kernel.org; linux-
> ker...@vger.kernel.org
> Cc: konrad.w...@oracle.com; Roger Pau Monne ;
> ax...@kernel.dk; Paul Durrant
> Subj
Found while reviewing Andrew's str{,n}cmp() fix.
1: avoid undefined behavior in strrchr()
2: remove memscan()
3: fix type use in strstr()
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-
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 some stylistic adjustments to its
surviving sibling fu
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 de-referenced though). Use post-decrement (and >
instead of >
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.
Si
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 de-referenced
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 so
>>> 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: xen/drivers
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 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 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 __initdat
>>> 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 pointer
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 "live".
>>> 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 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 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 = __initcall_start
>>> 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 lea
>>> 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 )
>
> OO
>>> 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 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 codin
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 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,
> cpuid_leaf_buff
>>> 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
Xen-dev
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 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_* con
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 th
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 esp
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 the
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 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 d
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 into
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 ++-
xen/in
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 hvm_get/
...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 +++---
x
...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 n
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 chec
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
---
xen/arch/x86/
>>> 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 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
> initiali
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
> > +++ b/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 (b
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: xen/drivers/pas
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 tha
>>> 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 inte
>>> 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 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 fo
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
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
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
test-amd64-amd6
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() whic
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.
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_
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 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
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: Stefano
...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
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
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
test-amd64-amd64-xl-qemuu-win7-amd64
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 newer
> 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
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 b65ae50c2b4
...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 files c
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
C
...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 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 the
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
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
---
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 for
> -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] [PATC
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 __i
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 viridian_pa
> -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() for
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 J
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
> > Si
>>> 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é
Ac
>>> 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, uint32_
>>> 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(&e820, KB(640), MB(1) - 1, E820_RAM, true);
Fro
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
_
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,
> des
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 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, 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 approach
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; jbeul...@su
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, __2M_
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)
> > {
> > const
1 - 100 of 120 matches
Mail list logo
