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 the opposite of vm_insert_range() or even of vm_in
чт, 15 лист. 2018 о 17:05 Julien Grall пише:
> And in x86 code...
Sorry, did not check.
> You can't assume the compiler will inline even with the inline keyword.
For sure!
> > I'm sorry, but I can't pass my RB for `_t`.
>
> I think this request is unreasonable because this is a matter of taste.
flight 130177 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130177/
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
Hello Julien,
чт, 15 лист. 2018 о 22:20 Julien Grall пише:
> Well the code suggested is different from what I intended :). t should
> be set to invalid before the check mfn_valid/get_page. So this needs at
> least 2 checks. 2 places were t != NULL needs to be explained.
Well, I guess checking a
On Mon, 5 Nov 2018 02:40:41 +0100
Samuel Ortiz wrote:
> It is going to be used by the PC machine type as the MADT table builder
> method and thus needs to be exported outside of acpi-build.c
>
> Also, now that the generic build_madt() API is exported, we have to
> rename the ARM static one in o
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:
> >> I find some pass-thru devices don't work any more across guest
> >> reboot. Assigning it to another domain a
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 fact that the
> PCI bus is known by the structure AcpiPciHpState.
>
> When the structure
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
>>> 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(&pdev->msi_list) && pdev->msix )
>> >> +
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 d
>>> 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);
>>> str
>>> 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 all
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 c
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 afterward
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:
> > > > Ma
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 t
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 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 bu
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
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
test-amd
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 u
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 0
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
>>> 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, new_enabl
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 p2m_d
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. 12954
>>> 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 he
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 have
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 ver
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
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 domai
>>> 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
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
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
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 guest-lo
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 b26818
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
_
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 del
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:
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 w
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.
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
test-amd64-i386-xl-r
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
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 0
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
Te
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:
> >> >
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, slot,
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 broad
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 targeted
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 handle_hvm_io_co
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 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, leav
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
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
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
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 do_IRQ(str
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 @@ stat
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
https://lists.xenproject.org/mailman/l
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
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
https://xenbits.xen.org/gitweb/?p=people/liuw/osstest.
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 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 gener
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 +-
xen/arch/arm/vgic.
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 th
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 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 th
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
unc
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 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
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 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 havi
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 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) an
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 gener
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 clan
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 +32
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 100
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
Xen-devel@lists.xenproject.o
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
Xen-dev
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, etc
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 p
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 k
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 M
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 16/11/
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, 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 supp
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 1
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
test-amd64-amd64-x
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 rea
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 un
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 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,
>>
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 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 toolstac
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, we'
> 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 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, evtchn
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
> > > > > a
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 (
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 git://xenbits.xen.
1 - 100 of 107 matches
Mail list logo
