On Tue, Apr 11, 2017 at 12:21:23AM -0600, Jan Beulich wrote:
> >>> On 10.04.17 at 18:46, wrote:
> > I have a (I think) less intrusive fix, which relies on using _Pragma, pasted
> > below. Let me know what you think, and I can formally submit it.
>
> Personally I like this much better as a workaro
>>> On 10.04.17 at 21:44, wrote:
Please don't forget Cc-ing the maintainer(s) of the code being modified.
> @@ -1187,12 +1182,22 @@ static int do_kexec_op_internal(unsigned long op,
> XEN_GUEST_HANDLE_PARAM(void) uarg,
> bool_t co
flight 107351 xen-4.4-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107351/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xend-qemut-winxpsp3 9 windows-install fail REGR. vs. 106822
Tests which are
clang gcc-compat warnings can wrongly fire when certain constructions are used,
at least the following flow:
switch ( ... )
{
case ...:
while ( ({ int x; switch ( foo ) { case 1: x = 1; break; } x }) )
{
...
Will cause clang to emit the following warning "'break' is bound to loop,
On 11/04/17 17:59, Juergen Gross wrote:
On 11/04/17 07:25, Glenn Enright wrote:
Hi all
We are seeing an odd issue with domu domains from xl destroy, under
recent 4.9 kernels a (null) domain is left behind.
I guess this is the dom0 kernel version?
This has occurred on a variety of hardware,
Hello, Jan.
As you know, with VT-d PI enabled, hardware can directly deliver external
interrupts to guest without any VMM intervention. It will reduces overall
interrupt latency to guest and reduces overheads otherwise incurred by the
VMM for virtualizing interrupts. In my mind, it's an important
>>> On 10.04.17 at 20:47, wrote:
> On 4/3/2017 6:55 AM, Jan Beulich wrote:
> On 31.03.17 at 17:42, wrote:
>> The title needs improvement - it doesn't really reflect what the
>> patch does.
>
> I apologize for this. I kept the name same since it was the third version
> of the patch and though
>>> On 11.04.17 at 02:59, wrote:
> As you know, with VT-d PI enabled, hardware can directly deliver external
> interrupts to guest without any VMM intervention. It will reduces overall
> interrupt latency to guest and reduces overheads otherwise incurred by the
> VMM for virtualizing interrupts. I
>>> On 11.04.17 at 09:54, wrote:
> clang gcc-compat warnings can wrongly fire when certain constructions are
> used,
> at least the following flow:
>
> switch ( ... )
> {
> case ...:
> while ( ({ int x; switch ( foo ) { case 1: x = 1; break; } x }) )
> {
> ...
>
> Will cause cla
On Tue, Apr 11, 2017 at 02:35:59AM -0600, Jan Beulich wrote:
> >>> On 11.04.17 at 09:54, wrote:
> > clang gcc-compat warnings can wrongly fire when certain constructions are
> > used,
> > at least the following flow:
> >
> > switch ( ... )
> > {
> > case ...:
> > while ( ({ int x; switch ( f
Add a parameter for setting the resolution of xen-kbdfront in order to
be able to cope with a (virtual) frame buffer of arbitrary resolution.
Signed-off-by: Juergen Gross
---
drivers/input/misc/xen-kbdfront.c | 18 ++
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a
Setting the pointing device resolution via Xenstore isn't working
reliably: in case XenbusStateInitWait has been missed the resolution
settings won't be read. Correct this.
Signed-off-by: Juergen Gross
Reviewed-by: Oleksandr Andrushchenko
---
drivers/input/misc/xen-kbdfront.c | 32 +
As my patch tying the resolution of the xen pointing device to that of
the framebuffer wasn't accepted add support for different resolutions
via a module parameter.
Another possibility would be to set parameters via Xenstore, but this
is broken (patch 2 fixes that) and not yet supported by Xen too
On 10/04/17 16:18, Oleksandr Andrushchenko wrote:
> On 04/10/2017 05:11 PM, Juergen Gross wrote:
>> On 10/04/17 16:00, Oleksandr Andrushchenko wrote:
>>>
>>> On 04/10/2017 04:50 PM, Juergen Gross wrote:
On 10/04/17 15:44, Oleksandr Andrushchenko wrote:
> Hi, Juergen!
>
> On 03/21/2
Haozhong Zhang writes:
> Add an optional argument 'devtype' to 'query-memory-devices', which
> is either 'dimm' or 'nvdimm'. If 'devtype' is missed or 'dimm', all
> memory devices will be listed. If 'devtype' is 'nvdimm', only nvdimm
> devices will be listed.
Basically, the argument provides lim
On 10/04/17 17:32, Raslan, KarimAllah wrote:
>
> Ahmed, Karim Allah
> karah...@amazon.de
>
>
>
>> On Apr 10, 2017, at 3:57 PM, Juergen Gross wrote:
>>
>> On 10/04/17 15:47, Boris Ostrovsky wrote:
>>> On 04/07/2017 06:11 PM, Stefano Stabellini wrote:
On Fri, 7 Apr 2017, Boris Ostrovsky wro
Hi, Juergen,
could you please make one more patch in the series:
the code that you fix in this patch is ok, but most
of the functionality of the xenkbd_set_connected
is still useless: feature-abs-pointer/request-abs-pointer
negotiation has only meaning at probe time, when we are
configuring
flight 107350 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107350/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl 11 guest-start fail REGR. vs. 59254
test-armhf-armhf-xl
On 11/04/17 11:00, Oleksandr Andrushchenko wrote:
> Hi, Juergen,
>
> could you please make one more patch in the series:
>
> the code that you fix in this patch is ok, but most
>
> of the functionality of the xenkbd_set_connected
>
> is still useless: feature-abs-pointer/request-abs-pointer
>
Hi Stefano,
On 04/11/2017 12:01 AM, Stefano Stabellini wrote:
On Mon, 10 Apr 2017, Andre Przywara wrote:
Hi,
On 10/04/17 00:12, André Przywara wrote:
Hi,
I wanted to run some ideas on how to prevent the race conditions we are
facing with the ITS emulation and removing devices and/or LPIs.
I
On 04/11/2017 11:50 AM, Juergen Gross wrote:
Add a parameter for setting the resolution of xen-kbdfront in order to
be able to cope with a (virtual) frame buffer of arbitrary resolution.
Signed-off-by: Juergen Gross
---
drivers/input/misc/xen-kbdfront.c | 18 ++
1 file change
On 11/04/17 11:26, Oleksandr Andrushchenko wrote:
> On 04/11/2017 11:50 AM, Juergen Gross wrote:
>> Add a parameter for setting the resolution of xen-kbdfront in order to
>> be able to cope with a (virtual) frame buffer of arbitrary resolution.
>>
>> Signed-off-by: Juergen Gross
>> ---
>> driver
From: Oleksandr Andrushchenko
For some use cases when Xen framebuffer/input backend
is not a part of Qemu it is required to disable it,
because of conflicting access to input/display devices.
Introduce additional configuration option for explicit
input/display control.
Signed-off-by: Oleksandr A
On Mon, Apr 10, 2017 at 11:02:37AM -0400, Doug Freed wrote:
> Hi,
>
> This issue came up in the #xen IRC channel on freenode, and Andrew
> Cooper asked for somebody to email xen-devel so it could be fixed. A
> user had the following line in their domain config and couldn't figure
> out why it was
On 04/11/2017 12:35 PM, Juergen Gross wrote:
On 11/04/17 11:26, Oleksandr Andrushchenko wrote:
On 04/11/2017 11:50 AM, Juergen Gross wrote:
Add a parameter for setting the resolution of xen-kbdfront in order to
be able to cope with a (virtual) frame buffer of arbitrary resolution.
Signed-off-b
Testing has shown that domUs with 'tsc_mode=default' can be migrated
safely between identical hardware, even if the measured clock frequency
differs by a few kHz. A change like shown below would allow to migrate
between "2.nnGHz" hosts without enforcing emulation. If the domU is
migrated to a host
Am Dienstag, 11. April 2017, 20:03:14 schrieb Glenn Enright:
> On 11/04/17 17:59, Juergen Gross wrote:
> > On 11/04/17 07:25, Glenn Enright wrote:
> >> Hi all
> >>
> >> We are seeing an odd issue with domu domains from xl destroy, under
> >> recent 4.9 kernels a (null) domain is left behind.
> >
>
On 10/04/17 19:48, Boris Ostrovsky wrote:
>>> The following is meant as a real question without any prejudice:
>>>
>>> How old a Xen version do we want to support in the Linux kernel?
>>>
>>> - Only those being still maintained (meaning getting security fixes)
> Definitely not this. 4.4 is the olde
>>> On 11.04.17 at 11:39, wrote:
> Testing has shown that domUs with 'tsc_mode=default' can be migrated
> safely between identical hardware, even if the measured clock frequency
> differs by a few kHz. A change like shown below would allow to migrate
> between "2.nnGHz" hosts without enforcing emu
Add traps to each capability PCI_CAP_LIST_NEXT field in order to mask them on
request.
All capabilities from the device are fetched and stored in an internal list,
that's later used in order to return the next capability to the guest. Note
that this only removes the capability from the linked list
Mostly code motion, this function will be needed in other parts apart from PVH
Dom0 build. Also note that the __init attribute is dropped.
Signed-off-by: Roger Pau Monné
---
Cc: Jan Beulich
Cc: Andrew Cooper
---
xen/arch/x86/hvm/dom0_build.c | 26 --
xen/common/memory.c
Introduce a set of handlers for the accesses to the ECAM areas. Those areas are
setup based on the contents of the hardware MMCFG tables, and the list of
handled ECAM areas is stored inside of the hvm_domain struct.
The read/writes are forwarded to the generic vpci handlers once the address is
dec
Hello,
The following series contain an implementation of handlers for the PCI
configuration space inside of Xen. This allows Xen to detect accesses to the
PCI configuration space and react accordingly.
I'm still not sure that the interface for the handlers is the final one, right
now only some ba
This functionality is going to reside in vpci.c (and the corresponding vpci.h
header), and should be arch-agnostic. The handlers introduced in this patch
setup the basic functionality required in order to trap accesses to the PCI
config space, and allow decoding the address and finding the correspo
Introduce a set of handlers that trap accesses to the PCI BARs and the command
register, in order to emulate BAR sizing and BAR relocation.
The command handler is used to detect changes to bit 2 (response to memory
space accesses), and maps/unmaps the BARs of the device into the guest p2m.
The BA
So that it can be called from outside in order to get the size of regular PCI
BARs. This will be required in order to map the BARs from PCI devices into PVH
Dom0 p2m.
Signed-off-by: Roger Pau Monné
---
Cc: Jan Beulich
---
xen/drivers/passthrough/pci.c | 86 ++
On 11/04/17 11:39, Olaf Hering wrote:
> Testing has shown that domUs with 'tsc_mode=default' can be migrated
> safely between identical hardware, even if the measured clock frequency
> differs by a few kHz. A change like shown below would allow to migrate
> between "2.nnGHz" hosts without enforcing
flight 107356 xen-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107356/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-xl-arndale 2 hosts-allocate broken in 107327 pass in 107356
test-amd64-i386-xl-qemut-debi
This run is configured for baseline tests only.
flight 71170 xen-4.7-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71170/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-qemuu-nested-intel 17 capture-logs/l
>The patch, unchanged from before, is
>https://github.com/xenserver/xen-4.7.pg/blob/master/master/0001-libxl-Don-t-insert-PCI-device-into-xenstore-for-HVM-.patch
This patch means that no xenstore keys will be created for HVM. For this, I
have one question that :
libxl__device_pci_add --> libxl_
On Mon, 10 Apr 2017 22:49:33 +0200
Daniel Kiper wrote:
> On Fri, Apr 07, 2017 at 11:16:22AM +0200, Petr Tesarik wrote:
> > On Wed, 5 Apr 2017 13:13:00 +0200
> > Petr Tesarik wrote:
> >
> > > On Tue, 4 Apr 2017 12:42:53 -0700 (PDT)
> > > Daniel Kiper wrote:
> > >
> > >[...]
> > > > So, if Petr d
No quote is required when a string is provided as part of a spec string.
Reported-by: Doug Freed
Signed-off-by: Wei Liu
---
Cc: Ian Jackson
---
docs/man/xl.cfg.pod.5.in | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/docs/man/xl.cfg.pod.5.in b/docs/man/xl.cfg.pod.5
Cc Doug Freed
On Tue, Apr 11, 2017 at 12:03:00PM +0100, Wei Liu wrote:
> No quote is required when a string is provided as part of a spec string.
>
> Reported-by: Doug Freed
> Signed-off-by: Wei Liu
> ---
> Cc: Ian Jackson
> ---
> docs/man/xl.cfg.pod.5.in | 9 +
> 1 file changed, 5 in
On 11/04/17 10:24, Julien Grall wrote:
Hi Stefano,
On 04/11/2017 12:01 AM, Stefano Stabellini wrote:
On Mon, 10 Apr 2017, Andre Przywara wrote:
Hi,
On 10/04/17 00:12, André Przywara wrote:
Hi,
I wanted to run some ideas on how to prevent the race conditions we are
facing with the ITS emul
Hello,
I have created a clang-format file for specifications of format for Xen
hypervisor and incorporated all of the support which present clang-format could
provide. I have seen all the options provided by clang-format and have some
discrepancies regarding some of format specifications which
On Tue, Apr 11, 2017 at 01:46:37AM -0600, Jan Beulich wrote:
> >>> On 10.04.17 at 21:44, wrote:
>
> Please don't forget Cc-ing the maintainer(s) of the code being modified.
>
> > @@ -1187,12 +1182,22 @@ static int do_kexec_op_internal(unsigned long op,
> > XEN_GUES
Ishani,
> On 11 Apr 2017, at 12:21, Ishani wrote:
>
> Hello,
>
> I have created a clang-format file for specifications of format for Xen
> hypervisor and incorporated all of the support which present clang-format
> could provide. I have seen all the options provided by clang-format and have
Hi Andre,
On Sat, Apr 8, 2017 at 3:37 AM, Andre Przywara wrote:
> Hi,
>
> an only slightly modified repost of the last version.
> I added the Reviewed-by: and Acked-by: tags from Stefano and Julien
> and rebased on top of the latest staging tree:
> commit 89216c7999eb5b8558bfac7d61ae0d5ab844ce3f
Add a parameter for setting the resolution of xen-kbdfront in order to
be able to cope with a (virtual) frame buffer of arbitrary resolution.
While at it remove the pointless second reading of parameters from
Xenstore in the device connection phase: all parameters are available
during device probi
>>> On 11.04.17 at 13:24, wrote:
> On Tue, Apr 11, 2017 at 01:46:37AM -0600, Jan Beulich wrote:
>> >>> On 10.04.17 at 21:44, wrote:
>> wouldn't it be better to handle this with a static state variable,
>> which gets checked/set atomically, and which if already set simply
>> leads to a continuatio
On Tue, Apr 11, 2017 at 06:31:36AM -0600, Jan Beulich wrote:
> >>> On 11.04.17 at 13:24, wrote:
> > On Tue, Apr 11, 2017 at 01:46:37AM -0600, Jan Beulich wrote:
> >> >>> On 10.04.17 at 21:44, wrote:
> >> wouldn't it be better to handle this with a static state variable,
> >> which gets checked/se
On 03/04/17 14:42, Daniel Kiper wrote:
> On Fri, Mar 31, 2017 at 12:14:38PM +0200, Juergen Gross wrote:
>> For kdump to work correctly it needs the physical address of
>> vmcoreinfo_note. When running as dom0 this means the virtual address
>> has to be translated to the related machine address.
>>
On Tue, Apr 11, 2017 at 02:45:43PM +0200, Juergen Gross wrote:
> On 03/04/17 14:42, Daniel Kiper wrote:
> > On Fri, Mar 31, 2017 at 12:14:38PM +0200, Juergen Gross wrote:
> >> For kdump to work correctly it needs the physical address of
> >> vmcoreinfo_note. When running as dom0 this means the virt
Hi Wei,
On 11/04/17 12:03, Wei Liu wrote:
No quote is required when a string is provided as part of a spec string.
Reported-by: Doug Freed
Signed-off-by: Wei Liu
Documentation will always improve the release :). Unless there is a
commit moratorium, consider that release-ack is not necessar
flight 107357 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107357/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qcow216 guest-localmigrate/x10 fail REGR. vs. 107259
Regressions whi
On 04/11/2017 05:53 AM, Andrew Cooper wrote:
On 10/04/17 19:48, Boris Ostrovsky wrote:
The following is meant as a real question without any prejudice:
How old a Xen version do we want to support in the Linux kernel?
- Only those being still maintained (meaning getting security fixes)
Defin
flight 71171 distros-debian-snapshot real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71171/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-i386-daily-netboot-pvgrub 9 debian-di-install fail REGR. vs.
71146
On Mon, 2017-04-10 at 14:50 -0700, Candida Haynes wrote:
> Hi,
>
> I apologize to anyone who receives this twice - I received an
> error/bounce message. I am writing because I am interested in
> applying to Outreachy and contributing to the Xen Code Review
> Dashboard. My most formal experience wi
On 11/04/17 15:22, Boris Ostrovsky wrote:
>
>
> On 04/11/2017 05:53 AM, Andrew Cooper wrote:
>> On 10/04/17 19:48, Boris Ostrovsky wrote:
> The following is meant as a real question without any
> prejudice:
>
> How old a Xen version do we want to support in the Linux
> kernel
I think the right thing is indeed to revert 72a9b186292 (and
therefore da72ff5bfcb02). Any objections?
For the end result: depends. Is there a real error or not?
KarimAllah wrote that his concerns are of a theoretical nature as
xen_strict_xenbus_quirk() would mask the problem. OTOH he tells
> On Apr 11, 2017, at 10:57 AM, Juergen Gross wrote:
>
> On 10/04/17 17:32, Raslan, KarimAllah wrote:
>>
>> Ahmed, Karim Allah
>> karah...@amazon.de
>>
>>
>>
>>> On Apr 10, 2017, at 3:57 PM, Juergen Gross wrote:
>>>
>>> On 10/04/17 15:47, Boris Ostrovsky wrote:
On 04/07/2017 06:11 PM,
Hi,
Kindly let me know if my understanding is correct.
Using a domctl API will allow us to keep the vUART configuration
flexible. Currently, we can operate on one ring-buf PFN and an event
channel port only for a single vUART but if we use DOMCTL interface,
then we can effectively get/set multipl
> On Apr 11, 2017, at 4:10 PM, Boris Ostrovsky
> wrote:
>
>
>
>>>
>>> I think the right thing is indeed to revert 72a9b186292 (and
>>> therefore da72ff5bfcb02). Any objections?
>>
>> For the end result: depends. Is there a real error or not?
>> KarimAllah wrote that his concerns are of a t
On 11/04/17 16:42, Raslan, KarimAllah wrote:
>
>> On Apr 11, 2017, at 4:10 PM, Boris Ostrovsky
>> wrote:
>>
>>
>>
I think the right thing is indeed to revert 72a9b186292 (and
therefore da72ff5bfcb02). Any objections?
>>>
>>> For the end result: depends. Is there a real error or n
On Tue, 11 Apr 2017 15:00:58 +0200
Daniel Kiper wrote:
> On Tue, Apr 11, 2017 at 02:45:43PM +0200, Juergen Gross wrote:
> > On 03/04/17 14:42, Daniel Kiper wrote:
> > > On Fri, Mar 31, 2017 at 12:14:38PM +0200, Juergen Gross wrote:
> > >> For kdump to work correctly it needs the physical address
>>> On 01.04.17 at 15:53, wrote:
> --- a/xen/arch/x86/psr.c
> +++ b/xen/arch/x86/psr.c
> @@ -157,10 +157,26 @@ static void free_socket_resources(unsigned int socket)
> {
> unsigned int i;
> struct psr_socket_info *info = socket_info + socket;
> +struct domain *d;
>
> if ( !in
>>> On 01.04.17 at 15:53, wrote:
> @@ -593,7 +616,21 @@ int psr_get_val(struct domain *d, unsigned int socket,
> /* Set value functions */
> static unsigned int get_cos_num(const struct psr_socket_info *info)
> {
> -return 0;
> +unsigned int num = 0, i;
> +
> +/* Get all features to
>>> On 01.04.17 at 15:53, wrote:
> --- a/xen/arch/x86/psr.c
> +++ b/xen/arch/x86/psr.c
> @@ -720,8 +720,83 @@ static int find_cos(const uint32_t val[], unsigned int
> array_len,
> const struct psr_socket_info *info,
> spinlock_t *ref_lock)
> {
> +uns
>>> On 01.04.17 at 15:53, wrote:
> --- a/xen/arch/x86/psr.c
> +++ b/xen/arch/x86/psr.c
> @@ -800,15 +800,82 @@ static int find_cos(const uint32_t val[], unsigned int
> array_len,
> return -ENOENT;
> }
>
> +static bool fits_cos_max(const uint32_t val[],
> + uint32_t
>>> On 01.04.17 at 15:53, wrote:
> +static void do_write_psr_msr(void *data)
> +{
> +struct cos_write_info *info = data;
> +unsigned int cos= info->cos;
> +struct feat_node *feat = info->feature;
> +
> +if ( cos > feat->props->cos_max )
> +return;
This che
No matter that we emulate IRET for (guest) real more only right now, we
should get its effect on (virtual) NMI delivery right.
Signed-off-by: Jan Beulich
---
v2: Adjust x86_emulate_wrapper() accordingly.
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -1955,25 +1955,32 @@ st
>>> On 01.04.17 at 15:53, wrote:
> @@ -755,7 +765,7 @@ static int gather_val_array(uint32_t val[],
> cos = 0;
>
> /* Value getting order is same as feature array. */
> -feat->props->get_val(feat, cos, &val[0]);
> +feat->props->get_val(feat, cos, 0, &val[0]);
Hi,
On 09/04/17 21:16, Julien Grall wrote:
> Hi Andre,
>
> On 04/07/2017 06:32 PM, Andre Przywara wrote:
>> Emulate the memory mapped ITS registers and provide a stub to introduce
>> the ITS command handling framework (but without actually emulating any
>> commands at this time).
>>
>> Signed-off
>>> On 01.04.17 at 15:53, wrote:
> @@ -94,6 +102,13 @@ struct feat_node {
> unsigned int cos_max;
> unsigned int cbm_len;
>
> +/*
> + * An array to save all 'enum cbm_type' values of the feature. It is
> + * used with cos_num together to get/write a feat
Hi,
On 06/04/17 01:45, Stefano Stabellini wrote:
> On Thu, 6 Apr 2017, Andre Przywara wrote:
>> The MAPTI commands associates a DeviceID/EventID pair with a LPI/CPU
>> pair and actually instantiates LPI interrupts.
>> We connect the already allocated host LPI to this virtual LPI, so that
>> any tr
For kdump to work correctly it needs the physical address of
vmcoreinfo_note. When running as dom0 this means the virtual address
has to be translated to the related machine address.
paddr_vmcoreinfo_note() is meant to do the translation via
__pa_symbol() only, but being attributed "weak" it can b
The patch introduces a new command line option 'cpu' that when used will create
runqueue per logical pCPU. This may be useful for small systems, and also for
development, performance evalution and comparison.
Signed-off-by: Praveen Kumar
Reviewed-by: Dario Faggioli
---
docs/misc/xen-command-li
On 11/04/17 16:36, Jan Beulich wrote:
> No matter that we emulate IRET for (guest) real more only right now, we
> should get its effect on (virtual) NMI delivery right.
>
> Signed-off-by: Jan Beulich
> ---
> v2: Adjust x86_emulate_wrapper() accordingly.
>
> --- a/xen/arch/x86/hvm/emulate.c
> +++ b
Hello,
this is trying to make the point that having NULL pointer entries in the
radix tree and letting Xen handle that is a valid case.
To some degree this serves as a tag (LPI has been unmapped), so should
semantically come close to what we are discussing.
It has the big advantage of being able t
On 11/04/17 17:15, Praveen Kumar wrote:
> The patch introduces a new command line option 'cpu' that when used will
> create
> runqueue per logical pCPU. This may be useful for small systems, and also for
> development, performance evalution and comparison.
>
> Signed-off-by: Praveen Kumar
> Revi
flight 107296 linux-arm-xen real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107296/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-arndale 2 hosts-allocate broken REGR. vs. 1071
Eric Blake writes:
> We now have macros in place to make it less verbose to add a scalar
> to QDict and QList, so use them. To make this patch smaller to
> review, a couple of subdirectories were done in earlier patches.
>
> Patch created mechanically via:
> spatch --sp-file scripts/coccinelle
On Tue, Apr 11, 2017 at 04:59:16PM +0200, Petr Tesarik wrote:
> On Tue, 11 Apr 2017 15:00:58 +0200
> Daniel Kiper wrote:
>
> > On Tue, Apr 11, 2017 at 02:45:43PM +0200, Juergen Gross wrote:
> > > On 03/04/17 14:42, Daniel Kiper wrote:
> > > > On Fri, Mar 31, 2017 at 12:14:38PM +0200, Juergen Gross
On 04/11/2017 12:12 PM, Markus Armbruster wrote:
> Eric Blake writes:
>
>> We now have macros in place to make it less verbose to add a scalar
>> to QDict and QList, so use them. To make this patch smaller to
>> review, a couple of subdirectories were done in earlier patches.
>>
>> Patch created
On Tue, Apr 04, 2017 at 11:59:03AM -0700, Dan Williams wrote:
> >> I don't think KVM has the same issue, but honestly I don't have the
> >> full mental model of how KVM supports mmap. I've at least been able to
> >> run a guest where the "pmem" is just dynamic page cache on the host
> >> side so th
The patch actually doesn't impact the functionality as such. This only replaces
bool_t with bool in credit2.
Signed-off-by: Praveen Kumar
---
xen/common/sched_credit2.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/xen/common/sched_credit2.c b/xen/common/sche
flight 107359 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107359/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-vhd 15 guest-start.2fail REGR. vs. 107247
Regressions which
We now have macros in place to make it less verbose to add a scalar
to QDict and QList, so use them. To make this patch smaller to
review, a couple of subdirectories were done in earlier patches.
Patch created mechanically via:
spatch --sp-file scripts/coccinelle/qobject.cocci \
--macro-fil
flight 107364 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107364/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf f8c1facf34a1f65082fa22fdbc20a6e0ab8887b4
baseline version:
ovmf 1ea946d0f9ea7de963545
When a blkfront device is resized from dom0, emit a KOBJ_CHANGE uevent to
notify the guest about the change. This allows for custom udev rules, such
as automatically resizing a filesystem, when an event occurs.
Signed-off-by: Marc Olson
---
drivers/block/xen-blkfront.c | 3 +++
1 file changed, 3
On Tue, Apr 11, 2017 at 12:24:09PM -0700, Marc Olson wrote:
> When a blkfront device is resized from dom0, emit a KOBJ_CHANGE uevent to
> notify the guest about the change. This allows for custom udev rules, such
> as automatically resizing a filesystem, when an event occurs.
Looks pretty reasonab
This run is configured for baseline tests only.
flight 71172 xen-4.6-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71172/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-multivcpu 15 guest-start
flight 107358 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107358/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-xl-arndale 2 hosts-allocate broken in 107313 pass in 107358
test-armhf-armhf-xl-multivcpu 15 gu
flight 107360 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107360/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-xsm 9 debian-install fail REGR. vs. 107219
Regressions which
On Fri, 7 Apr 2017, Stefano Stabellini wrote:
> On Fri, 7 Apr 2017, Volodymyr Babchuk wrote:
> > >> Native application is an another domain type. It has own vCPU (only one
> > >> at this
> > >> moment) Native app is loaded as any other kernel, using ELF loader.
> > >> It looks like another stub-do
flight 107362 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107362/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-libvirt 13 saverestore-support-checkfail like 107325
test-armhf-armhf-libvirt-xsm 13
On Tue, 11 Apr 2017, Bhupinder Thakur wrote:
> Hi,
>
> Kindly let me know if my understanding is correct.
>
> Using a domctl API will allow us to keep the vUART configuration
> flexible. Currently, we can operate on one ring-buf PFN and an event
> channel port only for a single vUART but if we us
On 11/04/17 21:49, Dietmar Hahn wrote:
Am Dienstag, 11. April 2017, 20:03:14 schrieb Glenn Enright:
On 11/04/17 17:59, Juergen Gross wrote:
On 11/04/17 07:25, Glenn Enright wrote:
Hi all
We are seeing an odd issue with domu domains from xl destroy, under
recent 4.9 kernels a (null) domain is
flight 107365 xen-4.4-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107365/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xend-qemut-winxpsp3 15 guest-localmigrate/x10 fail REGR. vs.
106822
Tests whi
This run is configured for baseline tests only.
flight 71173 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71173/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf f8c1facf34a1f65082fa22fdbc20a6e0ab8887b4
baseline v
1 - 100 of 150 matches
Mail list logo
