This run is configured for baseline tests only.
flight 75004 ovmf real [real]
http://osstest.xensource.com/osstest/logs/75004/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail like 75003
flight 125557 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125557/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 0f78fd73496f26d45516f6c453a66f35edca6ab0
baseline version:
ovmf
flight 125525 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125525/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-examine 4 memdisk-try-append fail REGR. vs. 125138
flight 125524 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125524/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemuu-rhel6hvm-amd 10 redhat-install fail REGR. vs. 125169
This run is configured for baseline tests only.
flight 75003 ovmf real [real]
http://osstest.xensource.com/osstest/logs/75003/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail like 75002
flight 125522 examine real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125522/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
examine-laxton0 2 hosts-allocate broken REGR. vs. 124647
Exclude named output files from the Xen tree setup.
The linkfarm.stamp content will differ between top level "make"
and "make install" invocations, due to the introduction of these
output files that are produced during the "make" build.
Filter these out to prevent an unnecessary rebuild of the
On Tue, Jul 24, 2018 at 2:43 AM, Jan Beulich wrote:
> >>> On 20.07.18 at 23:15, wrote:
> > Exclude named output files from the Xen tree setup.
> >
> > The linkfarm.stamp content will differ between top level "make"
> > and "make install" invocations, due to the introduction of these
> > output
flight 125553 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125553/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 49a4797e9c6829520eb3e09b52710b6b6993a65e
baseline version:
ovmf
On Mon, 23 Jul 2018, Julien Grall wrote:
> Hi,
>
> On 07/07/18 00:14, Stefano Stabellini wrote:
> > Signed-off-by: Stefano Stabellini
> > CC: george.dun...@eu.citrix.com
> > CC: ian.jack...@eu.citrix.com
> > CC: jbeul...@suse.com
> > CC: andrew.coop...@citrix.com
> > ---
> > SUPPORT.md | 10
On Mon, 23 Jul 2018, Julien Grall wrote:
> Hi Stefano,
>
> On 07/07/18 00:13, Stefano Stabellini wrote:
> > +config QEMU_PLATFORM
> > + bool
> > +
> > +config RCAR3_PLATFORM
> > + bool
>
> Those 2 options do nothing. So I would prefer if they are removed. With that
> fixed:
>
> Acked-by:
On Tue, 24 Jul 2018, Srivatsa S. Bhat wrote:
> However, if you are proposing that you'd like to contribute the enhanced
> PTI/Spectre (upstream) patches from the SLES 4.4 tree to 4.4 stable, and
> have them merged instead of this patch series, then I would certainly
> welcome it!
I'd in
On Tue, 24 Jul 2018, Michal Hocko wrote:
> oom_reap_task_mm should return false when __oom_reap_task_mm return
> false. This is what my patch did but it seems this changed by
> http://www.ozlabs.org/~akpm/mmotm/broken-out/mm-oom-remove-oom_lock-from-oom_reaper.patch
> so that one should be fixed.
flight 125514 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125514/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvshim7 xen-boot fail REGR. vs. 125401
On 7/23/18 3:06 PM, Jiri Kosina wrote:
> On Sat, 14 Jul 2018, Srivatsa S. Bhat wrote:
>
>> This patch series is a backport of the Spectre-v2 fixes (IBPB/IBRS)
>> and patches for the Speculative Store Bypass vulnerability to 4.4.y
>> (they apply cleanly on top of 4.4.140).
>
> FWIW -- not sure
On Tue, 24 Jul 2018 16:17:47 +0200 Michal Hocko wrote:
> On Fri 20-07-18 17:09:02, Andrew Morton wrote:
> [...]
> > - Undocumented return value.
> >
> > - comment "failed to reap part..." is misleading - sounds like it's
> > referring to something which happened in the past, is in fact
> >
flight 125517 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125517/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 123814
build-amd64-libvirt
This run is configured for baseline tests only.
flight 75002 ovmf real [real]
http://osstest.xensource.com/osstest/logs/75002/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail like 75001
flight 125520 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125520/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-amd64 7 xen-bootfail REGR. vs. 123554
On 23/07/2018 15:20, Pu Wen wrote:
> Add x86 architecture support for new processor Hygon Dhyana Family 18h.
> Rework to create a separated file(arch/x86/kernel/cpu/hygon.c) from the
> AMD init one(arch/x86/kernel/cpu/amd.c) to initialize Dhyana CPU. In
> this way we can remove old AMD
Hi all,
This is just a reminder that tomorrow we are going to have the Xen on
ARM Community Call at 9AM California time.
You are very welcome to join!
Cheers,
Stefano
On Fri, 13 Jul 2018, Stefano Stabellini wrote:
> Hi all,
>
> It is time for another Xen on ARM Community Call. I suggest to
On Tue, Jul 24, 2018 at 05:56:51PM +0100, Wei Liu wrote:
> Signed-off-by: Ian Jackson
> Signed-off-by: Wei Liu
> ---
> This is a script I wrote previously for build test.
Goal here is to bisect a series to find the build failure? We could
allow git bisect to do the work and just build and
flight 125549 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125549/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm
flight 125546 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125546/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 0ed73bcdcd80e0df9b383b1c53cd9a95d366843f
baseline version:
ovmf
FWIW,
On Tue, 2018-07-24 at 16:26 +0100, George Dunlap wrote:
> On 07/24/2018 12:23 PM, Lars Kurth wrote:
> >
> > It seems to me there are a number of options we have and thus some
> > decisions
> > that need to be made.
> > 2: Do we have an opt-in or op-out (e.g. through a tag, a specific
> >
Signed-off-by: Ian Jackson
Signed-off-by: Wei Liu
---
This is a script I wrote previously for build test.
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Konrad Rzeszutek Wilk
Cc: Stefano Stabellini
Cc: Tim Deegan
Cc: Wei Liu
Cc: Julien Grall
Cc: Anthony PERARD
This run is configured for baseline tests only.
flight 75001 ovmf real [real]
http://osstest.xensource.com/osstest/logs/75001/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail like 74999
On 07/24/2018 04:44 PM, Jan Beulich wrote:
On 24.07.18 at 16:01, wrote:
>> I don't see what the problem is in having a single response to the
>> thread saying that the test was run, the result of the run, and a link
>> to a page about it. It's certainly less mail than I get in the course
>>
flight 125512 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125512/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-libvirt broken in 125165
build-i386-pvops
>>> On 24.07.18 at 16:01, wrote:
> I don't see what the problem is in having a single response to the
> thread saying that the test was run, the result of the run, and a link
> to a page about it. It's certainly less mail than I get in the course
> of a normal review cycle about patch series I'm
On 07/24/2018 04:26 PM, George Dunlap wrote:
> On 07/24/2018 12:23 PM, Lars Kurth wrote:
>>
>> On 24/07/2018, 11:50, "Julien Grall" wrote:
>>
>> Hi Lars,
>>
>> On 24/07/18 11:33, Lars Kurth wrote:
>> >
>> > On 24/07/2018, 11:19, "Wei Liu" wrote:
>> > On Tue, Jul
flight 125543 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125543/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm
On 07/24/2018 12:23 PM, Lars Kurth wrote:
>
> On 24/07/2018, 11:50, "Julien Grall" wrote:
>
> Hi Lars,
>
> On 24/07/18 11:33, Lars Kurth wrote:
> >
> > On 24/07/2018, 11:19, "Wei Liu" wrote:
> > On Tue, Jul 24, 2018 at 04:04:05AM -0600, Jan Beulich wrote:
>
On Tue, Jul 24, 2018 at 04:04:05AM -0600, Jan Beulich wrote:
> >>> On 24.07.18 at 11:43, wrote:
> > On Tue, Jul 24, 2018 at 03:34:51AM -0600, Jan Beulich wrote:
> >> >>> On 24.07.18 at 11:24, wrote:
> >> > On Tue, Jul 24, 2018 at 03:06:08AM -0600, Jan Beulich wrote:
> >> >> >>> On 23.07.18 at
On Tue, Jul 24, 2018 at 03:32:09PM +0100, George Dunlap wrote:
> On 07/24/2018 10:34 AM, Jan Beulich wrote:
> On 24.07.18 at 11:24, wrote:
> >> On Tue, Jul 24, 2018 at 03:06:08AM -0600, Jan Beulich wrote:
> >> On 23.07.18 at 18:40, wrote:
> # How does this impact me?
> The
On Mon, Jul 16, 2018 at 05:02:01AM -0600, Jan Beulich wrote:
> > Unfortunably there has been a crash last week:
>
> Hmm, looks to be still all the same as before (except for the line
> number). I'm afraid I'm out of ideas, at least for the moment.
OK, FYI I commited xen 4.11 packages for NetBSD,
On Mon, Jul 23, 2018 at 03:42:37PM +0100, Andrew Cooper wrote:
> Because of a bug in 2010, LMSL support didn't functioned in Xen.
>
> c/s f2c608444 noticed but avoided fixing the issue for migration reasons. In
> addition to migration problems, changes to the segmentation logic for
> emulation
On 07/24/2018 08:45 AM, M. Vefa Bicakci wrote:
> Commit d94a155c59c9 ("x86/cpu: Prevent cpuinfo_x86::x86_phys_bits
> adjustment corruption") has moved the query and calculation of the
> x86_virt_bits and x86_phys_bits fields of the cpuinfo_x86 struct
> from the get_cpu_cap function to a new
On 07/24/2018 02:42 PM, Jan Beulich wrote:
On 12.07.18 at 09:29, wrote:
Forgot to Cc maintainers.
Konrad, Ross: Ping?
Jan
On Wed, Jul 11, 2018 at 05:34:49PM +0200, Roger Pau Monne wrote:
And replace the open-coded versions already in tree. No functional
change.
Signed-off-by: Roger Pau
On 07/24/2018 10:34 AM, Jan Beulich wrote:
On 24.07.18 at 11:24, wrote:
>> On Tue, Jul 24, 2018 at 03:06:08AM -0600, Jan Beulich wrote:
>> On 23.07.18 at 18:40, wrote:
# How does this impact me?
The contribution workflow is *not* impacted by this change, but once up
and
On Tue, Jul 24, 2018 at 11:23:34AM +, Lars Kurth wrote:
> I am not quite sure what QEMU does. But I can't see any bot messages on their
> list archives
The bot from: is no-re...@patchew.org, for e.g.:
- coding style:
https://lists.nongnu.org/archive/html/qemu-devel/2018-07/msg01428.html
-
flight 125540 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125540/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 5b73e17fb17c6935d894b0084f32421e717c247f
baseline version:
ovmf
On Tue, Jul 24, 2018 at 07:59:30AM -0600, Jan Beulich wrote:
> >>> On 24.07.18 at 15:51, wrote:
> > On Tue, Jul 24, 2018 at 07:42:21AM -0600, Jan Beulich wrote:
> >> >>> On 12.07.18 at 09:29, wrote:
> >> > Forgot to Cc maintainers.
> >>
> >> Konrad, Ross: Ping?
> >
> > Daniel? Anyway, I will
On Fri 20-07-18 17:09:02, Andrew Morton wrote:
[...]
> - Undocumented return value.
>
> - comment "failed to reap part..." is misleading - sounds like it's
> referring to something which happened in the past, is in fact
> referring to something which might happen in the future.
>
> - fails
On 24/07/18 13:45, Lars Kurth wrote:
On 24/07/2018, 13:00, "Jan Beulich" wrote:
>>> On 24.07.18 at 13:48, wrote:
> In my personal opinion, just sending CI email as "reply-all" is fine. I
> do not mind having an extra email per patch in my mailbox.
This is
On 07/24/2018 01:45 PM, Lars Kurth wrote:
>
>
> On 24/07/2018, 13:00, "Jan Beulich" wrote:
>
> >>> On 24.07.18 at 13:48, wrote:
> > In my personal opinion, just sending CI email as "reply-all" is fine. I
> > do not mind having an extra email per patch in my mailbox.
>
>
>>> On 24.07.18 at 15:51, wrote:
> On Tue, Jul 24, 2018 at 07:42:21AM -0600, Jan Beulich wrote:
>> >>> On 12.07.18 at 09:29, wrote:
>> > Forgot to Cc maintainers.
>>
>> Konrad, Ross: Ping?
>
> Daniel? Anyway, I will take a look at this no later than tomorrow.
> Sorry for delay but I was swamped
Hi Stefano,
On 07/07/18 00:12, Stefano Stabellini wrote:
Call a new function, "create_domUs", from setup_xen to start DomU VMs.
Introduce support for the "xen,domU" compatible node on device tree.
Create new DomU VMs based on the information found on device tree under
"xen,domU". Calls
On Tue, Jul 24, 2018 at 07:42:21AM -0600, Jan Beulich wrote:
> >>> On 12.07.18 at 09:29, wrote:
> > Forgot to Cc maintainers.
>
> Konrad, Ross: Ping?
Daniel? Anyway, I will take a look at this no later than tomorrow.
Sorry for delay but I was swamped with other important stuff.
Daniel
>>> On 12.07.18 at 09:29, wrote:
> Forgot to Cc maintainers.
Konrad, Ross: Ping?
Jan
> On Wed, Jul 11, 2018 at 05:34:49PM +0200, Roger Pau Monne wrote:
>> And replace the open-coded versions already in tree. No functional
>> change.
>>
>> Signed-off-by: Roger Pau Monné
>> ---
>> Cc: Jan
>>> On 10.07.18 at 12:18, wrote:
On 10.07.18 at 10:31, wrote:
>> The default value of DEFCONFIG_LIST is wrong: it should be the value of
>> the configured ARCH_DEFCONFIG item, not the string "$ARCH_DEFCONFIG".
>
> Makse sense and matches Linux, but I'd still prefer to have Doug's
> consent
>>> On 17.07.18 at 12:38, wrote:
> Level triggered interrupts are not an optional feature of HPET, and
> must be implemented in order to comply with the HPET specification.
>
> Implement them by adding a callback to the timer which sets the
> interrupt bit in the general interrupt status
>>> On 17.07.18 at 12:38, wrote:
> Level trigger interrupts will be asserted regardless of whether the
> interrupt is masked, and thus the callback will also be executed.
>
> Add a new 'level' parameter to create_periodic_time in order to create
> level triggered timers. None of the current
Hello Stefano,
On 07.07.18 02:13, Stefano Stabellini wrote:
Add a "Platform Support" choice with four kconfig options: QEMU, RCAR3,
MPSOC and ALL. They enable the required options for their hardware
platform. ALL enables all available platforms and it's the default. It
doesn't automatically
On 24/07/18 10:57, Lars Kurth wrote:
>
> On 24/07/2018, 10:46, "Wei Liu" wrote:
>
> On Tue, Jul 24, 2018 at 10:38:24AM +0100, Lars Kurth wrote:
> >
> >
> > > On 24 Jul 2018, at 10:24, Wei Liu wrote:
> > >
> > > On Tue, Jul 24, 2018 at 03:06:08AM -0600, Jan Beulich
flight 125511 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125511/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemut-rhel6hvm-amd 12 guest-start/redhat.repeat fail REGR. vs.
125183
Commit d94a155c59c9 ("x86/cpu: Prevent cpuinfo_x86::x86_phys_bits
adjustment corruption") has moved the query and calculation of the
x86_virt_bits and x86_phys_bits fields of the cpuinfo_x86 struct
from the get_cpu_cap function to a new function named
get_cpu_address_sizes.
One of the call sites
On 24/07/2018, 13:00, "Jan Beulich" wrote:
>>> On 24.07.18 at 13:48, wrote:
> In my personal opinion, just sending CI email as "reply-all" is fine. I
> do not mind having an extra email per patch in my mailbox.
This is exactly what I'm afraid of - when you're Cc-ed on a
On 07/23/2018 11:04 AM, Boris Ostrovsky wrote:
On 07/22/2018 11:57 AM, M. Vefa Bicakci wrote:
On 07/21/2018 07:17 PM, M. Vefa Bicakci wrote:
On 07/21/2018 05:25 PM, Boris Ostrovsky wrote:
On 07/21/2018 03:49 PM, M. Vefa Bicakci wrote:
diff --git a/arch/x86/xen/enlighten_pv.c
>>> On 24.07.18 at 13:29, wrote:
> The iommu initialization will also create MMIO mappings in the Dom0
> p2m, so the paging memory pool needs to be allocated or else iommu
> initialization will fail.
>
> Move the call to init the iommu after the Dom0 p2m has been setup in
> order to solve this.
Hello Stefano,
On 23.07.18 21:32, Stefano Stabellini wrote:
also the GIC and timer addresses need to be configurable.
I don't remember we ever had a problem with them. But yes, this should
be configurable as well.
I usually refer to this (future) feature as arbitrary guest memory map.
I
>>> On 24.07.18 at 13:26, wrote:
> On 07/24/2018 09:55 AM, Jan Beulich wrote:
> On 23.07.18 at 15:48, wrote:
>>> --- a/xen/arch/x86/mm/mem_access.c
>>> +++ b/xen/arch/x86/mm/mem_access.c
>>> @@ -221,12 +221,12 @@ bool p2m_mem_access_check(paddr_t gpa, unsigned long
> gla,
>>> {
>>>
>>> On 24.07.18 at 13:48, wrote:
> In my personal opinion, just sending CI email as "reply-all" is fine. I
> do not mind having an extra email per patch in my mailbox.
This is exactly what I'm afraid of - when you're Cc-ed on a lot of
patches, you may then also get a lot of mails here. And no,
Hi All!
Lars Kurth writes:
> On 24/07/2018, 10:06, "Jan Beulich" wrote:
> >>> On 23.07.18 at 18:40, wrote:
> > This does mean though that series which do not build or show other
> issues,
> > will likely not be reviewed until the tests pass. This would lessen the
> >
flight 125541 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125541/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm
flight 75000 distros-debian-snapshot real [real]
http://osstest.xensource.com/osstest/logs/75000/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-i386-daily-netboot-pygrub 11 guest-start fail REGR. vs. 74981
The iommu initialization will also create MMIO mappings in the Dom0
p2m, so the paging memory pool needs to be allocated or else iommu
initialization will fail.
Move the call to init the iommu after the Dom0 p2m has been setup in
order to solve this.
Note that issues caused by this wrong
On 07/24/2018 09:55 AM, Jan Beulich wrote:
On 23.07.18 at 15:48, wrote:
>> --- a/xen/arch/x86/mm/mem_access.c
>> +++ b/xen/arch/x86/mm/mem_access.c
>> @@ -221,12 +221,12 @@ bool p2m_mem_access_check(paddr_t gpa, unsigned long
>> gla,
>> {
>> req->u.mem_access.flags |=
Hi Stefano,
On 07/07/18 00:12, Stefano Stabellini wrote:
Make vpl011 being able to be used without a userspace component in Dom0.
In that case, output is printed to the Xen serial and input is received
from the Xen serial one character at a time.
Call domain_vpl011_init during construct_domU
Hi Lars,
On 24/07/18 11:33, Lars Kurth wrote:
On 24/07/2018, 11:19, "Wei Liu" wrote:
On Tue, Jul 24, 2018 at 04:04:05AM -0600, Jan Beulich wrote:
> I'm afraid my personal bar for any such automation is pretty
> high: There must not ever be any negative effect from such an
On 24/07/2018, 11:19, "Wei Liu" wrote:
On Tue, Jul 24, 2018 at 04:04:05AM -0600, Jan Beulich wrote:
> I'm afraid my personal bar for any such automation is pretty
> high: There must not ever be any negative effect from such an
> addition. Positive effects would of course be very
>>> On 19.07.18 at 16:20, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 19 July 2018 11:49
>> @@ -1046,6 +1060,8 @@ static int __hvmemul_read(
>> pfec |= PFEC_implicit;
>> else if ( hvmemul_ctxt->seg_reg[x86_seg_ss].dpl == 3 )
>> pfec |= PFEC_user_mode;
>>
On Mon, Jul 23, 2018 at 03:42:37PM +0100, Andrew Cooper wrote:
> Because of a bug in 2010, LMSL support didn't functioned in Xen.
>
> c/s f2c608444 noticed but avoided fixing the issue for migration reasons. In
> addition to migration problems, changes to the segmentation logic for
> emulation
On Tue, Jul 24, 2018 at 04:04:05AM -0600, Jan Beulich wrote:
> >>> On 24.07.18 at 11:43, wrote:
> > On Tue, Jul 24, 2018 at 03:34:51AM -0600, Jan Beulich wrote:
> >> >>> On 24.07.18 at 11:24, wrote:
> >> > On Tue, Jul 24, 2018 at 03:06:08AM -0600, Jan Beulich wrote:
> >> >> >>> On 23.07.18 at
>>> On 23.07.18 at 16:42, wrote:
> Because of a bug in 2010, LMSL support didn't functioned in Xen.
>
> c/s f2c608444 noticed but avoided fixing the issue for migration reasons. In
> addition to migration problems, changes to the segmentation logic for
> emulation would be needed before the
>>> On 23.07.18 at 16:11, wrote:
> On Mon, Jul 23, 2018 at 02:49:50PM +0100, Andrew Cooper wrote:
>> It turns out that nothing ever prevented HVM guests from trying to set
> unknown
>> EFER bits. Generally, this results in a vmentry failure.
>>
>> For Intel hardware, all implemented bits are
>>> On 23.07.18 at 16:22, wrote:
> On 23/07/18 15:48, Andrew Cooper wrote:
>> The calls to xpti_init_default() in parse_xpti() are buggy. The CPUID data
>> hasn't been fetched that early, and boot_cpu_has(X86_FEATURE_ARCH_CAPS) will
>> always evaluate false.
>>
>> As a result, the default case
>>> On 23.07.18 at 19:09, wrote:
> The altp2m functionality was originally envisioned to be used in
> several different configurations, one of which was a single in-guest
> agent that had full operational control of altp2m. This required the
> single hypercall to be an HVMOP rather than a
On 24/07/2018, 10:34, "Jan Beulich" wrote:
>>> On 24.07.18 at 11:24, wrote:
> On Tue, Jul 24, 2018 at 03:06:08AM -0600, Jan Beulich wrote:
>> >>> On 23.07.18 at 18:40, wrote:
>> > # How does this impact me?
>> > The contribution workflow is *not* impacted by this change,
>>> On 24.07.18 at 11:43, wrote:
> On Tue, Jul 24, 2018 at 03:34:51AM -0600, Jan Beulich wrote:
>> >>> On 24.07.18 at 11:24, wrote:
>> > On Tue, Jul 24, 2018 at 03:06:08AM -0600, Jan Beulich wrote:
>> >> >>> On 23.07.18 at 18:40, wrote:
>> >> > # How does this impact me?
>> >> > The
Hi Stefano,
On 07/07/18 00:12, Stefano Stabellini wrote:
Move the code to calculate in_fifo_level and out_fifo_level out of
vpl011_data_avail, to the caller.
This change will make it possible to reuse vpl011_data_avail with
different ring structures in a later patch.
Signed-off-by: Stefano
On 24/07/2018, 10:46, "Wei Liu" wrote:
On Tue, Jul 24, 2018 at 10:38:24AM +0100, Lars Kurth wrote:
>
>
> > On 24 Jul 2018, at 10:24, Wei Liu wrote:
> >
> > On Tue, Jul 24, 2018 at 03:06:08AM -0600, Jan Beulich wrote:
> > On 23.07.18 at 18:40, wrote:
>
>>> On 23.07.18 at 13:50, wrote:
> For the last few days, I have been trying to get a PVH dom0 running,
> however I encountered the following problem: the system seems to
> freeze after the hypervisor boots, the screen goes black. I have tried to
> debug it via a serial console (using Minicom)
On Tue, Jul 24, 2018 at 10:38:24AM +0100, Lars Kurth wrote:
>
>
> > On 24 Jul 2018, at 10:24, Wei Liu wrote:
> >
> > On Tue, Jul 24, 2018 at 03:06:08AM -0600, Jan Beulich wrote:
> > On 23.07.18 at 18:40, wrote:
> >>> # How does this impact me?
> >>> The contribution workflow is *not*
On Tue, Jul 24, 2018 at 03:34:51AM -0600, Jan Beulich wrote:
> >>> On 24.07.18 at 11:24, wrote:
> > On Tue, Jul 24, 2018 at 03:06:08AM -0600, Jan Beulich wrote:
> >> >>> On 23.07.18 at 18:40, wrote:
> >> > # How does this impact me?
> >> > The contribution workflow is *not* impacted by this
>>> On 20.07.18 at 23:15, wrote:
> Exclude named output files from the Xen tree setup.
>
> The linkfarm.stamp content will differ between top level "make"
> and "make install" invocations, due to the introduction of these
> output files that are produced during the "make" build.
>
> Filter
> On 24 Jul 2018, at 10:24, Wei Liu wrote:
>
> On Tue, Jul 24, 2018 at 03:06:08AM -0600, Jan Beulich wrote:
> On 23.07.18 at 18:40, wrote:
>>> # How does this impact me?
>>> The contribution workflow is *not* impacted by this change, but once up and
>>> running the following will happen
>>> On 24.07.18 at 11:24, wrote:
> On Tue, Jul 24, 2018 at 03:06:08AM -0600, Jan Beulich wrote:
>> >>> On 23.07.18 at 18:40, wrote:
>> > # How does this impact me?
>> > The contribution workflow is *not* impacted by this change, but once up
>> > and
>
>> > running the following will happen
>>> On 24.07.18 at 11:28, wrote:
> On 07/24/2018 11:55 AM, Jan Beulich wrote:
>>> +if ( cpu_has_svm && !p2m->mem_access_settings )
>>> +{
>>> +p2m->mem_access_settings = xmalloc(struct radix_tree_root);
>>> +
>>> +if( !p2m->mem_access_settings )
>> Style.
>>
>>> +
>>> On 24.07.18 at 11:14, wrote:
> On 24/07/18 10:06, Jan Beulich wrote:
> On 23.07.18 at 18:40, wrote:
>>> # How does this impact me?
>>> The contribution workflow is *not* impacted by this change, but once up and
>>> running the following will happen once you post a patch or patch series
On 07/24/2018 11:55 AM, Jan Beulich wrote:
>> +if ( cpu_has_svm && !p2m->mem_access_settings )
>> +{
>> +p2m->mem_access_settings = xmalloc(struct radix_tree_root);
>> +
>> +if( !p2m->mem_access_settings )
> Style.
>
>> +{
>> +
On 24/07/2018, 10:06, "Jan Beulich" wrote:
>>> On 23.07.18 at 18:40, wrote:
> This does mean though that series which do not build or show other
issues,
> will likely not be reviewed until the tests pass. This would lessen the
> burden on reviewers, as they will know
On Tue, Jul 24, 2018 at 03:06:08AM -0600, Jan Beulich wrote:
> >>> On 23.07.18 at 18:40, wrote:
> > # How does this impact me?
> > The contribution workflow is *not* impacted by this change, but once up and
> > running the following will happen once you post a patch or patch series to
> >
On 24/07/18 10:06, Jan Beulich wrote:
On 23.07.18 at 18:40, wrote:
>> # How does this impact me?
>> The contribution workflow is *not* impacted by this change, but once up and
>> running the following will happen once you post a patch or patch series to
>> xen-devel:
>> * Patchwork will
>>> On 23.07.18 at 18:40, wrote:
> # How does this impact me?
> The contribution workflow is *not* impacted by this change, but once up and
> running the following will happen once you post a patch or patch series to
> xen-devel:
> * Patchwork will take patch series from the mailing list and
>>> On 23.07.18 at 15:48, wrote:
> --- a/xen/arch/x86/mm/mem_access.c
> +++ b/xen/arch/x86/mm/mem_access.c
> @@ -221,12 +221,12 @@ bool p2m_mem_access_check(paddr_t gpa, unsigned long
> gla,
> {
> req->u.mem_access.flags |= MEM_ACCESS_GLA_VALID;
>
>>> On 19.07.18 at 16:08, wrote:
> --- a/xen/arch/x86/hvm/viridian.c
> +++ b/xen/arch/x86/hvm/viridian.c
> @@ -1026,24 +1026,32 @@ static int viridian_load_domain_ctxt(struct domain
> *d, hvm_domain_context_t *h)
> HVM_REGISTER_SAVE_RESTORE(VIRIDIAN_DOMAIN, viridian_save_domain_ctxt,
>
>>> On 19.07.18 at 16:08, wrote:
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -740,16 +740,23 @@ void hvm_domain_destroy(struct domain *d)
> destroy_vpci_mmcfg(d);
> }
>
> +static int hvm_save_tsc_adjust_one(struct vcpu *v, hvm_domain_context_t *h)
> +{
> +struct
Hi Daniel,
I think the main questions here are:
1. Do we need a separated KConfig option for SILO
2. Can we use indirect call like "dummy_xsm_ops.grant_copy"
Any suggestion?
Best regards
Xin(Talons) Li
> > -Original Message-
> > From: Jan Beulich
>>> On 23.07.18 at 12:45, wrote:
> I think the main questions here are:
> 1. Do we need a separated KConfig option for SILO
> 2. Can we use indirect call like "dummy_xsm_ops.grant_copy"
> Any suggestion?
I'm afraid the addressing of your mail is misleading: I've voiced my
1 - 100 of 105 matches
Mail list logo
