As agreed on PV call PFA pahole results
On 12/22/2016 10:12 AM, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
This protocol aims to provide a unified protocol which fits more
sophisticated use-cases than a framebuffer device can handle. At the
moment basic functionality is supp
As agreed on PV call PFA pahole results
On 12/05/2016 03:05 PM, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
Hi, all!
Please find the next version of the ABI for the PV sound
after addressing review comments.
Thank you,
Oleksandr Andrushchenko
Oleksandr Grytsov
Oleksandr An
As agreed on PV call PFA pahole results
On 01/06/2017 11:32 AM, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
Hi, all!
This series updates existing kbdif protocol documentation
and adds multi-touch support
Thank you,
Oleksandr Andrushchenko
Oleksandr Andrushchenko (2):
xe
flight 104106 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104106/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail like 104100
test-armhf-armhf-libvirt
flight 104110 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104110/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-libvirt 13 saverestore-support-checkfail like 104093
test-armhf-armhf-libvirt-qcow2 1
On 01/11/2017 02:29 AM, Stefano Stabellini wrote:
On Tue, 10 Jan 2017, Oleksandr Andrushchenko wrote:
On 01/07/2017 12:37 AM, Stefano Stabellini wrote:
On Fri, 6 Jan 2017, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
Signed-off-by: Oleksandr Andrushchenko
---
xen/include/
flight 104122 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104122/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen ffc103c223a6d12e5221f66b7e96396a61ba1b20
baseline version:
xen 9009
On 11/01/17 05:37, Tian, Kevin wrote:
From: Anshul Makkar [mailto:anshul.mak...@citrix.com]
Sent: Friday, January 06, 2017 2:42 AM
Current codebase doesn't implement and use vmptrst. Implementing it as it may
be required in future.
Signed-off-by: Anshul Makkar
Then let's do it when it's rea
flight 104121 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104121/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 0772737347816ced8df6299b1c88cccb9de9164c
baseline version:
ovmf 7c14bc8769fbe1670e3b3
This run is configured for baseline tests only.
flight 68355 qemu-mainline real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68355/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt-
This run is configured for baseline tests only.
flight 68356 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68356/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 462a3eba8feaf3716d294111725742ff5aa08488
baseline v
>>> On 10.01.17 at 23:57, wrote:
> @@ -628,65 +690,10 @@ acpi_parse_one_rmrr(struct acpi_dmar_header *header)
> ret = acpi_parse_dev_scope(dev_scope_start, dev_scope_end,
> &rmrru->scope, RMRR_TYPE, rmrr->segment);
>
> -if ( ret || (rmrru->scope.devices_c
On Mon, Jan 09, 2017 at 12:33:58PM +0100, Arnd Bergmann wrote:
> On Friday, January 6, 2017 10:43:52 AM CET Nicolas Dichtel wrote:
> > Here is the v2 of this series. The first 5 patches are just cleanup: some
> > exported headers were still under a non-uapi directory.
>
> Since this is meant as a
When iterating through CPUID leaves to generating a policy, libxc will clip
itself at the hardcoded maxima, meaning that no data outside of the hardcoded
maxima are provided to Xen (in turn, causing Xen to return zeros if these
leaves are requested.)
The HVM code also clips the max_leaf data repor
flight 104119 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104119/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-libvirt-xsm 6 xen-boot fail pass in 104104
Regressions which are regarded a
On 10/01/17 13:01, Jan Beulich wrote:
On 10.01.17 at 12:59, wrote:
>> On 10/01/17 09:06, Jan Beulich wrote:
>>> - don't accept LOCK for DR accesses (it's undefined in the manuals)
>>> - only accept LOCK for CR accesses when the respective feature flag is
>>> set (which would not normally be
flight 104123 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104123/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf f7c11d9b995cc59cdbda0b790eafbc510b50b82d
baseline version:
ovmf 0772737347816ced8df62
>>> On 11.01.17 at 13:44, wrote:
> When iterating through CPUID leaves to generating a policy, libxc will clip
> itself at the hardcoded maxima, meaning that no data outside of the hardcoded
> maxima are provided to Xen (in turn, causing Xen to return zeros if these
> leaves are requested.)
>
> T
>>> On 11.01.17 at 04:14, wrote:
> On 17-01-10 04:45:05, Jan Beulich wrote:
>> >>> On 14.12.16 at 05:07, wrote:
>> > +/* L3 CAT callback functions implementation. */
>> > +static void l3_cat_init_feature(unsigned int eax, unsigned int ebx,
>> > +unsigned int ecx, u
>>> On 11.01.17 at 06:13, wrote:
> On 17-01-10 06:46:03, Jan Beulich wrote:
>> >>> On 14.12.16 at 05:07, wrote:
>> > +int psr_get_info(unsigned int socket, enum cbm_type type,
>> > + uint32_t dat[], uint32_t array_len)
>> > +{
>> > +struct psr_socket_info *info = get_socket_in
>>> On 11.01.17 at 06:16, wrote:
> On 17-01-10 06:50:36, Jan Beulich wrote:
>> >>> On 14.12.16 at 05:07, wrote:
>> > This patch implements get value flow including L3 CAT callback
>> > function.
>> >
>> > It also changes domctl interface to make it more general.
>> >
>> > With this patch, 'psr-
>>> On 11.01.17 at 07:07, wrote:
> On 17-01-10 07:34:00, Jan Beulich wrote:
>> >>> On 14.12.16 at 05:07, wrote:
>> > +static int l3_cat_set_new_val(uint64_t val[],
>> > + const struct feat_node *feat,
>> > + unsigned int old_cos,
>> > +
>>> On 11.01.17 at 07:22, wrote:
> On 17-01-10 08:15:15, Jan Beulich wrote:
>> >>> On 14.12.16 at 05:07, wrote:
>> > --- a/xen/arch/x86/psr.c
>> > +++ b/xen/arch/x86/psr.c
>> > @@ -186,6 +186,9 @@ struct feat_ops {
>> > unsigned int (*exceeds_cos_max)(const uint64_t val[],
>> >
On Wed, Jan 11, 2017 at 12:44:41PM +, Andrew Cooper wrote:
> When iterating through CPUID leaves to generating a policy, libxc will clip
> itself at the hardcoded maxima, meaning that no data outside of the hardcoded
> maxima are provided to Xen (in turn, causing Xen to return zeros if these
>
On Mon, Jan 09, 2017 at 08:29:15PM +0200, Andy Shevchenko wrote:
> On Mon, 2017-01-09 at 19:12 +0200, Andy Shevchenko wrote:
> > On Mon, 2017-01-09 at 18:27 +0200, Andy Shevchenko wrote:
> > > On Mon, 2017-01-09 at 06:58 -0800, Luis R. Rodriguez wrote:
> > > > The only architecture that was not tes
flight 104124 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104124/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt 11 guest-start fail REGR. vs. 104101
Tests which
On 10/01/17 09:04, Jan Beulich wrote:
> ... affecting POPF, CLI, and STI.
There seems to be a a discrepancy in Intel documentation.
Vol3 20.3.2 "Class 2—Maskable Hardware Interrupt Handling in
Virtual-8086 Mode Using the Virtual Interrupt Mechanism" says
"Also, if under these circumstances an 80
>>> On 11.01.17 at 16:15, wrote:
> On 10/01/17 09:04, Jan Beulich wrote:
>> @@ -1178,6 +1180,15 @@ _mode_iopl(
>> fail_if(_iopl < 0); \
>> _iopl; \
>> })
>> +#define mode_pvi() ({\
>> +
On Tue, Jan 10, 2017 at 8:25 PM, Stefano Stabellini
wrote:
> On Tue, 10 Jan 2017, Dan Streetman wrote:
>> On Tue, Jan 10, 2017 at 2:03 PM, Stefano Stabellini
>> wrote:
>> > On Tue, 10 Jan 2017, Dan Streetman wrote:
>> >> On Tue, Jan 10, 2017 at 10:57 AM, Dan Streetman wrote:
>> >> > On Mon, Jan
>>> +
>>> +
>>> +static bool test_reply(struct xb_req_data *req)
>>> +{
>>> + if (req->state == xb_req_state_got_reply || !xenbus_ok())
>>> + return true;
>>> +
>>> + /* Make sure to reread req->state each time. */
>>> + cpu_relax();
>> I don't think I understand why this is needed
On 10/01/17 09:04, Jan Beulich wrote:
> @@ -1836,6 +1840,34 @@ static int inject_swint(enum x86_swint_t
> generate_exception(fault_type, error_code);
> }
>
> +static void adjust_bnd(struct x86_emulate_ctxt *ctxt,
> + const struct x86_emulate_ops *ops, enum vex_pfx pfx)
On 11/01/17 15:26, Jan Beulich wrote:
On 11.01.17 at 16:15, wrote:
>> On 10/01/17 09:04, Jan Beulich wrote:
>>> @@ -1178,6 +1180,15 @@ _mode_iopl(
>>> fail_if(_iopl < 0); \
>>> _iopl; \
>>> })
>>> +#define mode_pvi() ({
On Wed, Jan 11, 2017 at 05:55:58AM +, Tian, Kevin wrote:
> > From: Venu Busireddy
> > Sent: Wednesday, January 11, 2017 6:58 AM
> >
> > From: Elena Ufimtseva
> >
> > Add Xen command line option rmrr to specify RMRR regions that are not
> > defined in ACPI thus causing IO Page Faults and prev
>>> On 11.01.17 at 16:40, wrote:
> On 10/01/17 09:04, Jan Beulich wrote:
>> @@ -1836,6 +1840,34 @@ static int inject_swint(enum x86_swint_t
>> generate_exception(fault_type, error_code);
>> }
>>
>> +static void adjust_bnd(struct x86_emulate_ctxt *ctxt,
>> + const stru
Dear Konrad,
Please see my comments below:
It would be good to have that as part of this patchset, otherwise
this is kind of non-compiling type patch.
I'm not really sure what do you mean.
The patch I refer was done for LK 3.4 if I remember, it is not
applicable to 4.6 I'm currently working wi
On Wed, Jan 11, 2017 at 06:09:03PM +0200, Andrii Anisov wrote:
> Dear Konrad,
>
> Please see my comments below:
> > It would be good to have that as part of this patchset, otherwise
> > this is kind of non-compiling type patch.
> I'm not really sure what do you mean.
As in attaching an rework of
flight 104125 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104125/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
On Tue, Jan 03, 2017 at 08:31:25AM -0700, Tamas K Lengyel wrote:
> On Fri, Dec 9, 2016 at 12:59 PM, Tamas K Lengyel
> wrote:
> > This patch relocates mem_access components that are currently mixed with p2m
> > code into separate files. This better aligns the code with similar
> > subsystems,
> >
On 11/01/17 16:29, Boris Ostrovsky wrote:
>
+
+
+static bool test_reply(struct xb_req_data *req)
+{
+ if (req->state == xb_req_state_got_reply || !xenbus_ok())
+ return true;
+
+ /* Make sure to reread req->state each time. */
+ cpu_relax();
Somehow I cannot find *recent* information on dom0 kernels in the wiki.
Which dom0 kernels do the Xen developers use for test/production? Are
there recommended versions (for example 4.4) for production?
Are are any dependencies/incompatibilities between Xen versions and dom0
kernels (I am only
On Wed, Jan 11, 2017 at 06:01:59PM +0100, Andreas Kinzler wrote:
> Somehow I cannot find *recent* information on dom0 kernels in the wiki.
> Which dom0 kernels do the Xen developers use for test/production? Are there
> recommended versions (for example 4.4) for production?
I use the latest and gre
On Tue, 2017-01-10 at 15:32 -0600, wy11 wrote:
> If the time granularity of RTDS is nanosecond, then it is no longer
> a
> problem. Can you please help me to know where I can find it in the
> source code?
>
If that's what you're interested in, time granularity is nanoseconds
for each and every
Coverity points out that x86_insn_modrm() returns -EINVAL for instructions not
encoded with a ModRM byte. A consequence is that checking != 3 is
insufficient to confirm that &ext was actually written to.
In practice, this check is only used after decode has been successful, and
0f01 will have a M
On Tue, 2017-01-10 at 09:21 +0200, Oleksandr Andrushchenko wrote:
> On 01/07/2017 12:20 AM, Stefano Stabellini wrote:
> > On Fri, 6 Jan 2017, Oleksandr Andrushchenko wrote:
> > > | reserved
> > > |
> > > + * +-+--
This simplifies the XEN_DOMCTL_set_cpuid handling, splitting the safety logic
away from the internals of how an update is completed.
The legacy cpuids[] logic is left in alone in a fuction, as it wont survive
very long. update_domain_cpuid_info() gains a small performance optimisation
to skip all
This removes all dependencies on the legacy cpuids[] array from
cpuid_hypervisor_leaves(). Swap a BUG() to an ASSERT_UNREACHABLE(), because
in the unlikely case that we hit it, returning all zeros to the guest is fine.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
This maintains the same to
The only callers of domain_cpuid() are the legacy cpuid path via
{pv,hvm}_cpuid(). Move domain_cpuid() to being private in cpuid.c, with an
adjusted API to use struct cpuid_leaf rather than individual pointers.
The ITSC clobbering logic is dropped. It is no longer necessary now that the
logic ha
The purpose of this series is to hide the legacy cpuid implementation entirely
behind the new API. In particular, hiding domain_cpuid() in the same way that
{pv,hvm}_cpuid() were hidden.
Andrew Cooper (4):
x86/domctl: Move all CPUID update logic into
update_domain_cpuid_info()
x86/cpuid:
This hides the legacy details inside the cpuid subsystem, where they will
eventually be dropped entirely.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
---
xen/arch/x86/cpuid.c | 10 +-
xen/arch/x86/domain.c| 14 +-
xen/arch/x86/domc
On 01/06/2017 05:31 PM, Jim Fehlig wrote:
Adding xen-devel for a question below...
Happy new year!
Nearly a year ago I reported an issue with the hypervisor feature on Xen
[1] and am now seeing a similar issue with the feature. Setting the
default value of pae changed between xend and libxl.
On Wed, Jan 11, 2017 at 10:49:48AM -0700, Jim Fehlig wrote:
> On 01/06/2017 05:31 PM, Jim Fehlig wrote:
>
> Adding xen-devel for a question below...
>
> > Happy new year!
> >
> > Nearly a year ago I reported an issue with the hypervisor feature on
> > Xen
> > [1] and am now seeing a similar is
This was introduced by c/s c38869e711 "x86/cpuid: Drop the temporary linear
feature bitmap from struct cpuid_policy", and caught by Coverity.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
---
xen/arch/x86/sysctl.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/xen/arch/x86/sysctl.c b
Thank you very much.I really appreciate your help.
Best Regards,
Wenqiu
Quoting Dario Faggioli :
On Tue, 2017-01-10 at 15:32 -0600, wy11 wrote:
If the time granularity of RTDS is nanosecond, then it is no longer
a
problem. Can you please help me to know where I can find it in the
source
On 11/01/17 17:49, Jim Fehlig wrote:
> On 01/06/2017 05:31 PM, Jim Fehlig wrote:
>
> Adding xen-devel for a question below...
>
>> Happy new year!
>>
>> Nearly a year ago I reported an issue with the hypervisor
>> feature on Xen
>> [1] and am now seeing a similar issue with the feature. Setting
>
On 01/11/2017 11:00 AM, Andrew Cooper wrote:
On 11/01/17 17:49, Jim Fehlig wrote:
On 01/06/2017 05:31 PM, Jim Fehlig wrote:
Adding xen-devel for a question below...
Happy new year!
Nearly a year ago I reported an issue with the hypervisor
feature on Xen
[1] and am now seeing a similar issue
On 01/11/2017 10:55 AM, Daniel P. Berrange wrote:
On Wed, Jan 11, 2017 at 10:49:48AM -0700, Jim Fehlig wrote:
On 01/06/2017 05:31 PM, Jim Fehlig wrote:
Adding xen-devel for a question below...
Happy new year!
Nearly a year ago I reported an issue with the hypervisor feature on Xen
[1] and a
On Fri, 2017-01-06 at 10:43 +0100, Nicolas Dichtel wrote:
> Regularly, when a new header is created in include/uapi/, the developer
> forgets to add it in the corresponding Kbuild file. This error is usually
> detected after the release is out.
>
> In fact, all headers under uapi directories shoul
On 01/11/2017 07:35 PM, Dario Faggioli wrote:
On Tue, 2017-01-10 at 09:21 +0200, Oleksandr Andrushchenko wrote:
On 01/07/2017 12:20 AM, Stefano Stabellini wrote:
On Fri, 6 Jan 2017, Oleksandr Andrushchenko wrote:
| reserved
|
+ * +-+---
On Wed, 11 Jan 2017, Dan Streetman wrote:
> On Tue, Jan 10, 2017 at 8:25 PM, Stefano Stabellini
> wrote:
> > On Tue, 10 Jan 2017, Dan Streetman wrote:
> >> On Tue, Jan 10, 2017 at 2:03 PM, Stefano Stabellini
> >> wrote:
> >> > On Tue, 10 Jan 2017, Dan Streetman wrote:
> >> >> On Tue, Jan 10, 2017
On Wed, 4 Jan 2017, Stefano Stabellini wrote:
> On Wed, 4 Jan 2017, Konrad Rzeszutek Wilk wrote:
> > On Wed, Jan 04, 2017 at 10:00:01AM -0800, Stefano Stabellini wrote:
> > > Hi all,
> > >
> > > as you know, we have an issue with the speed of review and acceptance of
> > > new PV drivers. In a dis
On Mon, Jan 09, 2017 at 07:37:59PM -0600, Doug Goldstein wrote:
> On 12/5/16 4:25 PM, Daniel Kiper wrote:
[...]
> > diff --git a/xen/arch/x86/efi/efi-boot.h b/xen/arch/x86/efi/efi-boot.h
> > index 62c010e..dc857d8 100644
> > --- a/xen/arch/x86/efi/efi-boot.h
> > +++ b/xen/arch/x86/efi/efi-boot.h
flight 104127 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104127/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
On Tue, Jan 10, 2017 at 02:51:27PM -0600, Doug Goldstein wrote:
> On 1/9/17 7:37 PM, Doug Goldstein wrote:
> > On 12/5/16 4:25 PM, Daniel Kiper wrote:
>
> >> diff --git a/xen/arch/x86/efi/efi-boot.h b/xen/arch/x86/efi/efi-boot.h
> >> index 62c010e..dc857d8 100644
> >> --- a/xen/arch/x86/efi/efi-boo
On 1/11/17 1:08 PM, Daniel Kiper wrote:
> On Mon, Jan 09, 2017 at 07:37:59PM -0600, Doug Goldstein wrote:
>> On 12/5/16 4:25 PM, Daniel Kiper wrote:
>
> [...]
>
>>> diff --git a/xen/arch/x86/efi/efi-boot.h b/xen/arch/x86/efi/efi-boot.h
>>> index 62c010e..dc857d8 100644
>>> --- a/xen/arch/x86/efi/
On Wed, Jan 11, 2017 at 10:49:48AM -0700, Jim Fehlig wrote:
> On 01/06/2017 05:31 PM, Jim Fehlig wrote:
>
> Adding xen-devel for a question below...
>
> > Happy new year!
> >
> > Nearly a year ago I reported an issue with the hypervisor feature on
> > Xen
> > [1] and am now seeing a similar is
On Wed, Jan 11, 2017 at 10:49:15AM -0800, Stefano Stabellini wrote:
> On Wed, 4 Jan 2017, Stefano Stabellini wrote:
> > On Wed, 4 Jan 2017, Konrad Rzeszutek Wilk wrote:
> > > On Wed, Jan 04, 2017 at 10:00:01AM -0800, Stefano Stabellini wrote:
> > > > Hi all,
> > > >
> > > > as you know, we have an
On Mon, Jan 09, 2017 at 08:05:01PM -0600, Doug Goldstein wrote:
> On 12/5/16 4:25 PM, Daniel Kiper wrote:
[...]
> > /* Save trampoline address for later use. */
> > shl $4, %ecx
> > -mov %ecx,sym_phys(trampoline_phys)
> > +mov %ecx,sym_fs(trampoline_p
I know it is cumbersome, and I might not be a fun of it myself, but it
is required for new Xen protocol changes. I wrote all of the binary
representations manually but if you find a tool to do it, please let me
know :-)
Letting you know ;) there is a project in Python which can do this [1]
I'm
On 1/11/17 1:47 PM, Daniel Kiper wrote:
> On Tue, Jan 10, 2017 at 02:51:27PM -0600, Doug Goldstein wrote:
>> On 1/9/17 7:37 PM, Doug Goldstein wrote:
>>> On 12/5/16 4:25 PM, Daniel Kiper wrote:
>>
diff --git a/xen/arch/x86/efi/efi-boot.h b/xen/arch/x86/efi/efi-boot.h
index 62c010e..dc857d
On 1/11/17 2:05 PM, Daniel Kiper wrote:
> On Mon, Jan 09, 2017 at 08:05:01PM -0600, Doug Goldstein wrote:
>> On 12/5/16 4:25 PM, Daniel Kiper wrote:
>
> [...]
>
>>> /* Save trampoline address for later use. */
>>> shl $4, %ecx
>>> -mov %ecx,sym_phys(trampoline_ph
flight 104128 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104128/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf e044364b82e63047980606c388f4854b7c41e947
baseline version:
ovmf f7c11d9b995cc59cdbda0
On 01/11/2017 12:33 PM, Andrew Cooper wrote:
> Coverity points out that x86_insn_modrm() returns -EINVAL for instructions not
> encoded with a ModRM byte. A consequence is that checking != 3 is
> insufficient to confirm that &ext was actually written to.
>
> In practice, this check is only used af
On 1/11/17 1:08 PM, Daniel Kiper wrote:
> On Mon, Jan 09, 2017 at 07:37:59PM -0600, Doug Goldstein wrote:
>> On 12/5/16 4:25 PM, Daniel Kiper wrote:
>
>
>>> diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
>>> index 0a93e61..70ed836 100644
>>> --- a/xen/common/efi/boot.c
>>> +++ b/xen/c
On Wed, Jan 11, 2017 at 01:50:56PM -0600, Doug Goldstein wrote:
> On 1/11/17 1:08 PM, Daniel Kiper wrote:
> > On Mon, Jan 09, 2017 at 07:37:59PM -0600, Doug Goldstein wrote:
> >> On 12/5/16 4:25 PM, Daniel Kiper wrote:
[...]
> >>> /* Populate E820 table and check trampoline area availability
On Mon, Dec 05, 2016 at 11:25:05PM +0100, Daniel Kiper wrote:
> Hi,
>
> I am sending eleventh version of multiboot2 protocol support for
> legacy BIOS and EFI platforms. This patch series release contains
> fixes for all known issues.
>
> The final goal is xen.efi binary file which could be loaded
flight 104129 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104129/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf df3f02df1bde40c2a0d486d3ca6bd529c3654049
baseline version:
ovmf e044364b82e6304798060
flight 104126 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104126/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-xsm 6 xen-boot fail REGR. vs. 104119
Regressions which
On Wed, 2017-01-11 at 20:40 +0200, Oleksandr Andrushchenko wrote:
> On 01/11/2017 07:35 PM, Dario Faggioli wrote:
> >
> > It's indeed a repetition, but a good one, IMO: it helps the reader,
> > as
> > she won't have to go back to figure out how big the struct was, how
> > the
> > macro was call an
On Wed, Jan 11, 2017 at 1:46 PM, Stefano Stabellini
wrote:
> On Wed, 11 Jan 2017, Dan Streetman wrote:
>> On Tue, Jan 10, 2017 at 8:25 PM, Stefano Stabellini
>> wrote:
>> > On Tue, 10 Jan 2017, Dan Streetman wrote:
>> >> On Tue, Jan 10, 2017 at 2:03 PM, Stefano Stabellini
>> >> wrote:
>> >> > On
The following commit:
commit 72a9b186292d98494f26cfd24a1621796209
Author: KarimAllah Ahmed
Date: Fri Aug 26 23:55:36 2016 +0200
xen: Remove event channel notification through Xen PCI platform device
broke Linux when booting as Dom0 on Xen in a nested Xen environment (Xen
installed ins
On 17-01-11 06:48:27, Jan Beulich wrote:
> >>> On 11.01.17 at 04:14, wrote:
> > On 17-01-10 04:45:05, Jan Beulich wrote:
> >> >>> On 14.12.16 at 05:07, wrote:
> >> > +/* L3 CAT callback functions implementation. */
> >> > +static void l3_cat_init_feature(unsigned int eax, unsigned int ebx,
> >> >
On 17-01-11 06:53:30, Jan Beulich wrote:
> >>> On 11.01.17 at 06:13, wrote:
> > On 17-01-10 06:46:03, Jan Beulich wrote:
> >> >>> On 14.12.16 at 05:07, wrote:
> >> > +int psr_get_info(unsigned int socket, enum cbm_type type,
> >> > + uint32_t dat[], uint32_t array_len)
> >> > +{
>
On 17-01-11 06:54:30, Jan Beulich wrote:
> >>> On 11.01.17 at 06:16, wrote:
> > On 17-01-10 06:50:36, Jan Beulich wrote:
> >> >>> On 14.12.16 at 05:07, wrote:
> >> > This patch implements get value flow including L3 CAT callback
> >> > function.
> >> >
> >> > It also changes domctl interface to
On 17-01-11 06:57:30, Jan Beulich wrote:
> >>> On 11.01.17 at 07:07, wrote:
> > On 17-01-10 07:34:00, Jan Beulich wrote:
> >> >>> On 14.12.16 at 05:07, wrote:
> >> > +static int l3_cat_set_new_val(uint64_t val[],
> >> > + const struct feat_node *feat,
> >> > +
On 17-01-11 07:01:23, Jan Beulich wrote:
> >>> On 11.01.17 at 07:22, wrote:
> > On 17-01-10 08:15:15, Jan Beulich wrote:
> >> >>> On 14.12.16 at 05:07, wrote:
> >> > --- a/xen/arch/x86/psr.c
> >> > +++ b/xen/arch/x86/psr.c
> >> > @@ -186,6 +186,9 @@ struct feat_ops {
> >> > unsigned int (*ex
flight 104133 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104133/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 713e4b007cb791829397522ad8f366dd1e08bee6
baseline version:
ovmf df3f02df1bde40c2a0d48
During an OOM scenario, request slots could not be created as skb
allocation fails. So the netback cannot pass in packets and netfront
wrongly assumes that there is no more work to be done and it disables
polling. This causes Rx to stall.
Fix is to consider the skb allocation failure as an error a
The current function pointers in struct vmx_domain for managing hvm
posted interrupt can be used also by SVM AVIC. Therefore, this patch
introduces the struct hvm_pi_ops in the struct hvm_domain to hold them.
Signed-off-by: Suravee Suthikulpanit
Cc: Andrew Cooper
Cc: Konrad Rzeszutek Wilk
Cc: J
flight 104135 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104135/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf bf3b7aae7100b60ff8a387f0b7604dbb6ff29fc9
baseline version:
ovmf 713e4b007cb7918293975
On 01/12/2017 12:50 AM, Dario Faggioli wrote:
On Wed, 2017-01-11 at 20:40 +0200, Oleksandr Andrushchenko wrote:
On 01/11/2017 07:35 PM, Dario Faggioli wrote:
It's indeed a repetition, but a good one, IMO: it helps the reader,
as
she won't have to go back to figure out how big the struct was,
flight 104131 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104131/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-debianhvm-amd64 16 guest-stop fail REGR. vs. 104119
Regressions which
flight 104134 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104134/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-libvirt 13 saverestore-support-checkfail like 104110
test-armhf-armhf-libvirt-qcow2 1
92 matches
Mail list logo
