flight 130092 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130092/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR.
vs. 129789
On Fri, Nov 16, 2018 at 11:59 PM Mike Rapoport wrote:
>
> On Thu, Nov 15, 2018 at 09:15:30PM +0530, Souptick Joarder wrote:
> > Previouly drivers have their own way of mapping range of
> > kernel pages/memory into user vma and this was done by
> > invoking vm_insert_page() within a loop.
> >
> >
flight 130255 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130255/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 129475
build-amd64-xsm
Hi Igor,
On Fri, 2018-11-16 at 10:39 +0100, Igor Mammedov wrote:
> On Mon, 5 Nov 2018 02:40:42 +0100
> Samuel Ortiz wrote:
>
> >
> > From: Sebastien Boeuf
> >
> > Instead of using the machine type specific method find_i440fx() to
> > retrieve the PCI bus, this commit aims to rely on the
On Thu, Nov 15, 2018 at 5:42 PM Souptick Joarder wrote:
>
> Previouly drivers have their own way of mapping range of
> kernel pages/memory into user vma and this was done by
> invoking vm_insert_page() within a loop.
>
> As this pattern is common across different drivers, it can
> be generalized
flight 130231 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130231/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 129475
build-amd64-xsm
flight 130080 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130080/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-i386-pvgrub 7 xen-boot fail REGR. vs. 129313
branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict
testid xen-boot
Tree: linux
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu
On Fri, 2018-11-16 at 16:51 -0600, Doug Goldstein wrote:
> > On Nov 16, 2018, at 3:41 PM, Dario Faggioli
> > wrote:
> >
> > But I have a question, Tumbleweed is rolling (and it's actually
> > rolling
> > quite fast); how can we handle that?
> >
> > I'd say the container image should be rebuild
On Sat, 17 Nov 2018, Dario Faggioli wrote:
> On Fri, 2018-11-16 at 21:58 +, Julien Grall wrote:
> > On 16/11/2018 21:41, Mirela Simonovic wrote:
> > > On Fri, Nov 16, 2018 at 8:09 PM Stefano Stabellini
> > > wrote:
> > > > > It should be possible to figure out which domain needs to
> > > > >
On Fri, 2018-11-16 at 21:58 +, Julien Grall wrote:
> On 16/11/2018 21:41, Mirela Simonovic wrote:
> > On Fri, Nov 16, 2018 at 8:09 PM Stefano Stabellini
> > wrote:
> > > > It should be possible to figure out which domain needs to
> > > > awaken from
> > > > there.
> > >
> > > Actually,
> On Nov 16, 2018, at 3:41 PM, Dario Faggioli wrote:
>
>> On Fri, 2018-11-16 at 19:50 +0100, Dario Faggioli wrote:
>>> On Fri, 2018-11-16 at 18:44 +, Wei Liu wrote:
On Fri, Nov 16, 2018 at 07:30:55PM +0100, Dario Faggioli wrote:
>>> I have been playing with the CI system today so
On Mon, 2018-11-12 at 15:33 +, Andrew Cooper wrote:
> On 12/11/18 15:31, Mirela Simonovic wrote:
> >
> > Thanks, now it's clear. We need to change the type for
> > watchdog_timer
> > to be the derived structure of timer that additionally contains
> > 'suspended' variable. That makes sense,
On Thu, 2018-11-15 at 11:38 +, Julien Grall wrote:
> On 11/15/18 11:10 AM, Mirela Simonovic wrote:
> I don't think we are discussing the same thing. The discussion was
> around other vCPUs, not the vCPU calling SYSTEM_SUSPEND.
>
> Most likely in the future, we would want to allow the
flight 130214 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130214/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 129475
build-amd64-xsm
On 16/11/2018 21:41, Mirela Simonovic wrote:
> Hi Stefano,
>
> On Fri, Nov 16, 2018 at 8:09 PM Stefano Stabellini
> wrote:
>>
>> On Fri, 16 Nov 2018, Stefano Stabellini wrote:
>>> On Fri, 16 Nov 2018, Julien Grall wrote:
On 16/11/2018 12:34, Mirela Simonovic wrote:
> Hi Julien,
On Fri, 2018-11-16 at 19:50 +0100, Dario Faggioli wrote:
> On Fri, 2018-11-16 at 18:44 +, Wei Liu wrote:
> > On Fri, Nov 16, 2018 at 07:30:55PM +0100, Dario Faggioli wrote:
> > >
> > I have been playing with the CI system today so it could have been
> > a
> > bit
> > overwhelmed. Let's wait
Hi Stefano,
On Fri, Nov 16, 2018 at 8:09 PM Stefano Stabellini
wrote:
>
> On Fri, 16 Nov 2018, Stefano Stabellini wrote:
> > On Fri, 16 Nov 2018, Julien Grall wrote:
> > > On 16/11/2018 12:34, Mirela Simonovic wrote:
> > > > Hi Julien,
> > >
> > > Hi Mirela,
> > >
> > > >
> > > > On Fri, Nov 16,
On 11/16/18 8:41 AM, Andrew Cooper wrote:
> This is a followup to c/s 96f235c26 which fulfils the remaining TODO item.
>
> First of all, the pre-existing SVM code has a bug. The value in
> msrs->dr_mask[] may be stale, as we allow direct access to these MSRs.
> Resolve this in guest_rdmsr() by
flight 130063 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130063/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm6 xen-buildfail REGR. vs. 129426
flight 130219 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130219/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm
On Fri, Nov 16, 2018 at 05:43:42PM +, Andrew Cooper wrote:
> On 16/11/2018 10:11, Jan Beulich wrote:
> On 15.11.18 at 22:47, wrote:
> >> Boris has confirmed that noone appears to be using PVRDTSCP any more, and
> >> in
> >> the decade since it was introduced, guest kernel / hardware
On 11/16/18 7:59 PM, George Dunlap wrote:
> On 11/16/18 2:10 PM, Razvan Cojocaru wrote:
>> On 11/16/18 2:03 PM, George Dunlap wrote:
>>> The code is definitely complicated enough, though, that I may have
>>> missed something, which is why I asked Razvan if there was a reason he
>>> changed it.
>>>
On Fri, 16 Nov 2018, Stefano Stabellini wrote:
> On Fri, 16 Nov 2018, Julien Grall wrote:
> > On 16/11/2018 12:34, Mirela Simonovic wrote:
> > > Hi Julien,
> >
> > Hi Mirela,
> >
> > >
> > > On Fri, Nov 16, 2018 at 12:44 PM Julien Grall
> > > wrote:
> > > >
> > > >
> > > >
> > > > On
On Fri, 16 Nov 2018, Julien Grall wrote:
> On 16/11/2018 12:34, Mirela Simonovic wrote:
> > Hi Julien,
>
> Hi Mirela,
>
> >
> > On Fri, Nov 16, 2018 at 12:44 PM Julien Grall wrote:
> > >
> > >
> > >
> > > On 16/11/2018 11:29, Mirela Simonovic wrote:
> > > > On Fri, Nov 16, 2018 at 11:33 AM
On Fri, 2018-11-16 at 18:42 +, Wei Liu wrote:
> On Fri, Nov 16, 2018 at 07:31:10PM +0100, Dario Faggioli wrote:
> > Signed-off-by: Dario Faggioli
>
> Acked-by: Wei Liu
>
> I would like to rearrange your code a bit to move it above the
> arm builds.
>
Sure, that indeed makes sense.
Lemme
On Fri, 2018-11-16 at 18:44 +, Wei Liu wrote:
> On Fri, Nov 16, 2018 at 07:30:55PM +0100, Dario Faggioli wrote:
> >
> > https://gitlab.com/xen-project/people/dfaggioli/xen/pipelines/36897573
> >
> > (Not sure if the fact that it hasn't started yet is my fault... :-/
> > )
>
> I have been
On Fri, Nov 16, 2018 at 07:30:55PM +0100, Dario Faggioli wrote:
> Hello,
>
> This series adds the dockerfile for openSUSE Leap (latest version, 15
> at the time of writing), as well as the gitlab CI runes for building
> the project inside it.
>
> I've tested locally building xen, tools, docs,
On Fri, Nov 16, 2018 at 07:31:10PM +0100, Dario Faggioli wrote:
> Signed-off-by: Dario Faggioli
Acked-by: Wei Liu
I would like to rearrange your code a bit to move it above the
arm builds.
Wei.
___
Xen-devel mailing list
On Fri, Nov 16, 2018 at 07:31:02PM +0100, Dario Faggioli wrote:
> Tracks the latest releast of openSUSE Leap. At the time of writing this
> patch, this is Leap 15.
>
> Signed-off-by: Dario Faggioli
Acked-by: Wei Liu
___
Xen-devel mailing list
Tracks the latest releast of openSUSE Leap. At the time of writing this
patch, this is Leap 15.
Signed-off-by: Dario Faggioli
---
Cc: Doug Goldstein
Cc: Wei Liu
---
automation/build/suse/opensuse-leap.dockerfile | 67
1 file changed, 67 insertions(+)
create mode
Signed-off-by: Dario Faggioli
---
Cc: Doug Goldstein
Cc: Wei Liu
---
.gitlab-ci.yml | 32
1 file changed, 32 insertions(+)
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index a3b393fade..815e626291 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -323,3
Hello,
This series adds the dockerfile for openSUSE Leap (latest version, 15
at the time of writing), as well as the gitlab CI runes for building
the project inside it.
I've tested locally building xen, tools, docs, etc, in a container
generated from the provided dockerfile with both gcc and
On Thu, Nov 15, 2018 at 09:15:30PM +0530, Souptick Joarder wrote:
> Previouly drivers have their own way of mapping range of
> kernel pages/memory into user vma and this was done by
> invoking vm_insert_page() within a loop.
>
> As this pattern is common across different drivers, it can
> be
On 14.11.18 22:16, David Hildenbrand wrote:
> Right now, pages inflated as part of a balloon driver will be dumped
> by dump tools like makedumpfile. While XEN is able to check in the
> crash kernel whether a certain pfn is actuall backed by memory in the
> hypervisor (see xen_oldmem_pfn_is_ram)
Anthony PERARD writes ("Re: [PATCH v6.2 05/11] libxl_qmp: Implementation of
libxl__ev_qmp_*"):
> On Fri, Nov 16, 2018 at 04:09:03PM +, Ian Jackson wrote:
> > Anthony PERARD writes ("Re: [PATCH v6.2 05/11] libxl_qmp: Implementation of
> > libxl__ev_qmp_*"):
> > > I wanted to reduce the number
On 11/16/18 2:10 PM, Razvan Cojocaru wrote:
> On 11/16/18 2:03 PM, George Dunlap wrote:
>> The code is definitely complicated enough, though, that I may have
>> missed something, which is why I asked Razvan if there was a reason he
>> changed it.
>>
>> For the purposes of this patch, I propose
With almost all users of keyhandler_scratch gone, clean up the 3 remaining
users and drop the buffer.
Signed-off-by: Andrew Cooper
Reviewed-by: Wei Liu
---
CC: Jan Beulich
CC: Roger Pau Monné
v2:
* Use a static __initdata buffer for EFI, rather than a stack variable.
* Drop (int) casts for
On 16/11/2018 10:11, Jan Beulich wrote:
On 15.11.18 at 22:47, wrote:
>> Boris has confirmed that noone appears to be using PVRDTSCP any more, and in
>> the decade since it was introduced, guest kernel / hardware support has
>> provided a better alternative.
> Doesn't removal of functionality
Hi Andrii,
On 16/11/2018 16:45, Andrii Anisov wrote:
From: Andrii Anisov
Avoid excessive conversions between pending_irq and irq number/priority.
This simlifies functions interface and reduces under locks code size.
Signed-off-by: Andrii Anisov
---
xen/arch/arm/gic-vgic.c| 10
On 11/16/2018 2:46 AM, Paolo Bonzini wrote:
On 17/04/18 01:09, Maran Wilson wrote:
For certain applications it is desirable to rapidly boot a KVM virtual
machine. In cases where legacy hardware and software support within the
guest is not needed, Qemu should be able to boot directly into the
On Fri, Nov 16, 2018 at 04:09:03PM +, Ian Jackson wrote:
> Anthony PERARD writes ("Re: [PATCH v6.2 05/11] libxl_qmp: Implementation of
> libxl__ev_qmp_*"):
> > On Thu, Nov 15, 2018 at 06:40:13PM +, Ian Jackson wrote:
> > > It would be better if the id column stated something more useful
On Fri, Nov 16, 2018 at 10:06:36AM +, Alexandru Stefan ISAILA wrote:
> A new mechanism has been added which is able to generically re-execute
> instructions, by temporarily granting permissions inside the EPT and
> re-executing the instruction with all other vcpus paused and with the
> monitor
On 11/16/18 12:15 AM, Souptick Joarder wrote:
> On Fri, Nov 16, 2018 at 12:11 PM Matthew Wilcox wrote:
>>
>> On Fri, Nov 16, 2018 at 11:00:30AM +0530, Souptick Joarder wrote:
>>> On Thu, Nov 15, 2018 at 11:44 PM Randy Dunlap wrote:
On 11/15/18 7:45 AM, Souptick Joarder wrote:
What is
From: Andrii Anisov
Avoid excessive conversions between pending_irq and irq number/priority.
This simlifies functions interface and reduces under locks code size.
Signed-off-by: Andrii Anisov
---
xen/arch/arm/gic-vgic.c| 10 +++---
xen/arch/arm/vgic-v3-its.c | 2 +-
On 16/11/18 17:29, Igor Mammedov wrote:
> General suggestions for this series:
> 1. Preferably don't do multiple changes within a patch
> neither post huge patches (unless it's pure code movement).
> (it's easy to squash patches later it necessary)
> 2. Start small, pick a table
flight 130205 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130205/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 129475
build-amd64-xsm
On Fri, Nov 16, 2018 at 04:27:55PM +, Ian Jackson wrote:
> This has got to the top of my todo list. Can someone point me at the
> current most recent work in progress, preferable in git branch form ?
I just pushed my latest wip branch to
On Mon, 5 Nov 2018 02:40:23 +0100
Samuel Ortiz wrote:
> This patch set provides an ACPI code reorganization in preparation for
> adding a shared hardware-reduced ACPI API to QEMU.
>
> The changes are coming from the NEMU [1] project where we're defining
> a new x86 machine type: i386/virt.
This has got to the top of my todo list. Can someone point me at the
current most recent work in progress, preferable in git branch form ?
Thanks,
Ian.
;4~
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
From: Andrii Anisov
Signed-off-by: Andrii Anisov
---
xen/arch/arm/irq.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c
index d5ad277..d6a0273 100644
--- a/xen/arch/arm/irq.c
+++ b/xen/arch/arm/irq.c
@@ -61,7 +61,9 @@
From: Andrii Anisov
Signed-off-by: Andrii Anisov
---
xen/arch/arm/irq.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c
index 098281f..d5ad277 100644
--- a/xen/arch/arm/irq.c
+++ b/xen/arch/arm/irq.c
@@ -224,7 +224,7 @@ void
flight 130041 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130041/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ws16-amd64 16 guest-localmigrate/x10 fail in 129796
REGR. vs. 129461
Thanks for the reply. I have deleted all the parts where we are in
agreement...
Anthony PERARD writes ("Re: [PATCH v6.2 05/11] libxl_qmp: Implementation of
libxl__ev_qmp_*"):
> On Thu, Nov 15, 2018 at 06:40:13PM +, Ian Jackson wrote:
> > It would be better if the id column stated something
On Mon, 5 Nov 2018 02:40:43 +0100
Samuel Ortiz wrote:
> In order to decouple ACPI APIs from specific machine types, we are
> creating an ACPI builder interface that each ACPI platform can choose to
> implement.
> This way, a new machine type can re-use the high level ACPI APIs and
> define some
On 11/16/18 3:05 PM, George Dunlap wrote:
> Now take change_type_range. The global effect of change_type_range
> should be that reads of the p2m which happen afterwards should have the
> new, changed value.
>
> In case A, change_type_range will write invalid entries up to
> max_remapped_pfn,
On 11/16/18 12:31 PM, Jan Beulich wrote:
On 16.11.18 at 13:03, wrote:
>> So the basic question is, does "max_mapped_pfn" mean, "Maximum pfn _for
>> the domain_", or "Maximum pfn _for this p2m_". When the element was
>> added to the p2m struct those were the same thing. Which do the various
On Fri, Nov 16, 2018 at 05:11:39AM -0700, Jan Beulich wrote:
> >>> On 14.11.18 at 12:57, wrote:
> > Current logic to handle long running operations has two flaws:
> >
> > - hvm_io_pending is only used by Intel code, fix this by moving the
> >call to vpci_process_pending into
flight 130184 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130184/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xen-freebsd 5 host-install(5) fail REGR. vs. 130036
version
On Thu, Nov 15, 2018 at 06:40:13PM +, Ian Jackson wrote:
> Anthony PERARD writes ("[PATCH v6.2 05/11] libxl_qmp: Implementation of
> libxl__ev_qmp_*"):
> > Signed-off-by: Anthony PERARD
>
> Thanks for the additional comments. I got thoroughly stuck in.
>
> Overall the structure looks
On Fri, Nov 16, 2018 at 05:00:29AM -0700, Jan Beulich wrote:
> >>> On 14.11.18 at 12:57, wrote:
> > @@ -413,7 +412,7 @@ static void rom_write(const struct pci_dev *pdev,
> > unsigned int reg,
> > header->rom_enabled = new_enabled;
> > pci_conf_write32(pdev->seg, pdev->bus,
On Fri, Nov 16, 2018 at 02:59:41AM -0700, Jan Beulich wrote:
> >>> On 16.11.18 at 10:35, wrote:
> > On Fri, Nov 16, 2018 at 03:53:50PM +0800, Chao Gao wrote:
> >> On Thu, Nov 15, 2018 at 11:40:39AM +0100, Roger Pau Monné wrote:
> >> >On Thu, Nov 15, 2018 at 09:10:26AM +0800, Chao Gao wrote:
> >>
flight 75596 distros-debian-jessie real [real]
http://osstest.xensource.com/osstest/logs/75596/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-i386-jessie-netboot-pygrub 19 guest-start/debian.repeat fail
REGR. vs. 75584
On 11/16/18 2:03 PM, George Dunlap wrote:
> The code is definitely complicated enough, though, that I may have
> missed something, which is why I asked Razvan if there was a reason he
> changed it.
>
> For the purposes of this patch, I propose having p2m_altp2m_init_ept()
> set max_mapped_pfn to
flight 130200 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130200/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 129475
build-amd64
flight 130067 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130067/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-examine 8 reboot fail REGR. vs. 128858
This is a followup to c/s 96f235c26 which fulfils the remaining TODO item.
First of all, the pre-existing SVM code has a bug. The value in
msrs->dr_mask[] may be stale, as we allow direct access to these MSRs.
Resolve this in guest_rdmsr() by reading directly from hardware in the
affected case.
On 16/11/2018 12:34, Mirela Simonovic wrote:
Hi Julien,
Hi Mirela,
On Fri, Nov 16, 2018 at 12:44 PM Julien Grall wrote:
On 16/11/2018 11:29, Mirela Simonovic wrote:
On Fri, Nov 16, 2018 at 11:33 AM Mirela Simonovic
wrote:
Hi Julien,
On Thu, Nov 15, 2018 at 9:31 PM Julien Grall
Use the "extends" keyword introduced in 11.3 to reduce repetition in
jobs. More importantly, this helps us better organise the properties
of jobs.
Signed-off-by: Wei Liu
---
.gitlab-ci.yml | 281 +++--
1 file changed, 134 insertions(+), 147
Signed-off-by: Wei Liu
---
.gitlab-ci.yml | 24
1 file changed, 24 insertions(+)
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index 1c7b3d3d5b..b268182bc6 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -227,6 +227,18 @@ debian-unstable-gcc-debug:
variables:
Since we have introduced arm64 variants, we'd better start tagging the
old ones.
Signed-off-by: Wei Liu
---
Doug, this requires properly tagging all the x86 runner hosts first.
---
.gitlab-ci.yml | 4
1 file changed, 4 insertions(+)
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index
Wei Liu (3):
automation: refactor gitlab-ci.yaml
automation: introduce some RANDCONFIG tests
automation: properly tag x86 jobs in Gitlab CI
.gitlab-ci.yml | 309 ++---
1 file changed, 162 insertions(+), 147 deletions(-)
--
2.11.0
This run is configured for baseline tests only.
flight 75595 qemu-mainline real [real]
http://osstest.xensource.com/osstest/logs/75595/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 16
flight 130196 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130196/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 129475
build-amd64
Hi Julien,
On Fri, Nov 16, 2018 at 12:44 PM Julien Grall wrote:
>
>
>
> On 16/11/2018 11:29, Mirela Simonovic wrote:
> > On Fri, Nov 16, 2018 at 11:33 AM Mirela Simonovic
> > wrote:
> >>
> >> Hi Julien,
> >>
> >> On Thu, Nov 15, 2018 at 9:31 PM Julien Grall wrote:
> >>>
> >>> Hi,
> >>>
> >>>
>>> On 16.11.18 at 13:03, wrote:
> So the basic question is, does "max_mapped_pfn" mean, "Maximum pfn _for
> the domain_", or "Maximum pfn _for this p2m_". When the element was
> added to the p2m struct those were the same thing. Which do the various
> use cases expect it to be, and which would
On 11/16/18 2:03 PM, George Dunlap wrote:
> On 11/16/18 10:08 AM, Jan Beulich wrote:
> On 15.11.18 at 18:54, wrote:
>>> On 11/15/18 7:34 PM, George Dunlap wrote:
> On Nov 14, 2018, at 8:40 PM, Razvan Cojocaru
> wrote:
> @@ -1440,6 +1443,11 @@ void p2m_init_altp2m_ept(struct
On 11/15/18 8:51 PM, Razvan Cojocaru wrote:
> On 11/15/18 10:26 PM, George Dunlap wrote:
>>
>>
>>> On Nov 14, 2018, at 8:40 PM, Razvan Cojocaru
>>> wrote:
>>>
>>> When an new altp2m view is created very early on guest boot, the
>>> display will freeze (although the guest will run normally). This
Anthony PERARD writes ("[PATCH v6 09/11] libxl_qmp: Store advertised QEMU
version in libxl__ev_qmp"):
> This will be used in a later patch.
Thanks. I have one comment about defensive programming in the macro,
and a couple of formatting nits.
> +/*
> + * Store advertised QEMU
Anthony PERARD writes ("[PATCH v6 08/11] libxl: QEMU startup sync based on
QMP"):
> This is only activated when dm_restrict=1, as explained in the previous
> patch "libxl_dm: Pre-open QMP socket for QEMU"
...
> Signed-off-by: Anthony PERARD
> Reviewed-by: Roger Pau Monné
Thanks. I think I
>>> On 14.11.18 at 12:57, wrote:
> Current logic to handle long running operations has two flaws:
>
> - hvm_io_pending is only used by Intel code, fix this by moving the
>call to vpci_process_pending into handle_hvm_io_completion.
As mentioned before, the reference to Intel code is wrong
flight 130024 xen-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130024/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 16 guest-localmigrate/x10 fail
REGR. vs.
On 11/16/18 10:08 AM, Jan Beulich wrote:
On 15.11.18 at 18:54, wrote:
>> On 11/15/18 7:34 PM, George Dunlap wrote:
On Nov 14, 2018, at 8:40 PM, Razvan Cojocaru
wrote:
@@ -1440,6 +1443,11 @@ void p2m_init_altp2m_ept(struct domain *d, unsigned
int i)
struct
>>> On 14.11.18 at 12:57, wrote:
> @@ -413,7 +412,7 @@ static void rom_write(const struct pci_dev *pdev,
> unsigned int reg,
> header->rom_enabled = new_enabled;
> pci_conf_write32(pdev->seg, pdev->bus, slot, func, reg, val);
> }
> -else if ( modify_bars(pdev,
flight 130190 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130190/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 129475
build-amd64
Thanks for this patch. I have a feeling that I have already commented
(perhaps informally) on a few aspects of it but the message was not
marked `replied' in my MUA so I thought I would formally review it.
Apologies if my comments are, effectively, duplicates.
Anthony PERARD writes ("[PATCH v6
On 16/11/2018 11:29, Mirela Simonovic wrote:
On Fri, Nov 16, 2018 at 11:33 AM Mirela Simonovic
wrote:
Hi Julien,
On Thu, Nov 15, 2018 at 9:31 PM Julien Grall wrote:
Hi,
On 11/12/18 11:30 AM, Mirela Simonovic wrote:
The resume of Dom0 should always follow Xen's resume. This is
done by
flight 130022 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130022/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR.
vs. 125898
On Fri, Nov 16, 2018 at 11:33 AM Mirela Simonovic
wrote:
>
> Hi Julien,
>
> On Thu, Nov 15, 2018 at 9:31 PM Julien Grall wrote:
> >
> > Hi,
> >
> > On 11/12/18 11:30 AM, Mirela Simonovic wrote:
> > > The resume of Dom0 should always follow Xen's resume. This is
> > > done by unblocking the first
On Mon, 5 Nov 2018 02:40:45 +0100
Samuel Ortiz wrote:
All remaining patches a bit out of proper order,
they should be around patch 12/24 where you started to touch MCFG code.
> For building the MCFG table, we need to track a given machine
> type PCI host pointer, and we can't get it from the
flight 130188 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130188/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 129475
build-amd64
On 17/04/18 01:09, Maran Wilson wrote:
> For certain applications it is desirable to rapidly boot a KVM virtual
> machine. In cases where legacy hardware and software support within the
> guest is not needed, Qemu should be able to boot directly into the
> uncompressed Linux kernel binary without
On Thu, Nov 15, 2018 at 07:57:08PM +0100, Marek Marczykowski-Górecki wrote:
> On Thu, Nov 15, 2018 at 05:41:44PM +, Anthony PERARD wrote:
> > On Thu, Nov 01, 2018 at 06:32:07PM +0100, Marek Marczykowski-Górecki wrote:
> > > On Thu, Nov 01, 2018 at 04:57:18PM +, Ian Jackson wrote:
> > > >
Hi Julien,
On Thu, Nov 15, 2018 at 9:31 PM Julien Grall wrote:
>
> Hi,
>
> On 11/12/18 11:30 AM, Mirela Simonovic wrote:
> > The resume of Dom0 should always follow Xen's resume. This is
> > done by unblocking the first vCPU of Dom0.
>
> Please explain why you always need to resume Dom0
On 11/16/18 12:08 PM, Jan Beulich wrote:
> I've seen you mention such or alike a couple of times now while
> discussing this series, and I have to admit that I'm a little frightened:
> Making a change just based on the observation that nothing breaks
> is setting us up for breakage in some corner
>>> On 15.11.18 at 22:47, wrote:
> Boris has confirmed that noone appears to be using PVRDTSCP any more, and in
> the decade since it was introduced, guest kernel / hardware support has
> provided a better alternative.
Doesn't removal of functionality require knowing that it was never used
at
>>> On 15.11.18 at 18:54, wrote:
> On 11/15/18 7:34 PM, George Dunlap wrote:
>>> On Nov 14, 2018, at 8:40 PM, Razvan Cojocaru
>>> wrote:
>>> @@ -1440,6 +1443,11 @@ void p2m_init_altp2m_ept(struct domain *d, unsigned
>>> int i)
>>> struct p2m_domain *hostp2m = p2m_get_hostp2m(d);
>>>
A new mechanism has been added which is able to generically re-execute
instructions, by temporarily granting permissions inside the EPT and
re-executing the instruction with all other vcpus paused and with the
monitor trap flag set. The mechanism is re-entrant, meaning that is
capable of handling
>>> On 16.11.18 at 10:35, wrote:
> On Fri, Nov 16, 2018 at 03:53:50PM +0800, Chao Gao wrote:
>> On Thu, Nov 15, 2018 at 11:40:39AM +0100, Roger Pau Monné wrote:
>> >On Thu, Nov 15, 2018 at 09:10:26AM +0800, Chao Gao wrote:
>> >> +if ( pdev && list_empty(>msi_list) && pdev->msix )
>> >> +{
flight 130183 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130183/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 129475
build-amd64
1 - 100 of 107 matches
Mail list logo
