flight 130526 xtf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130526/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-xtf-amd64-amd64-4 69 xtf/test-hvm64-xsa-278 fail never pass
test-xtf-amd64-amd64-2 69 xtf/test-hvm6
Peter Anvin pointed out that commit ae7e1238e68f2a ("x86/boot: Add
ACPI RSDP address to setup_header") should be reverted as setup_header
should contain only items set by legacy BIOS.
So revert said commit. Instead of fully reverting the depending
commit e7b66d16fe4172 ("x86/acpi, x86/boot: Take R
In case the RSDP address in struct boot_params is specified don't try
to find the table by searching, but take the address directly as set
by the boot loader.
Signed-off-by: Juergen Gross
---
arch/x86/include/uapi/asm/bootparam.h | 3 ++-
arch/x86/kernel/acpi/boot.c | 2 +-
2 files cha
Resend with Daniel's mailo address corrected
Instead of passing the RSDP address for Xen PVH guests from grub2 to
the kernel in setup_header move it into the non-legacy part of the
boot_params structure.
This patch series should be applied rather sooner than later in order
to avoid shipping linux
Instead of passing the RSDP address for Xen PVH guests from grub2 to
the kernel in setup_header move it into the non-legacy part of the
boot_params structure.
This patch series should be applied rather sooner than later in order
to avoid shipping linux 4.20 with a corky boot protocol.
Juergen Gro
Peter Anvin pointed out that commit ae7e1238e68f2a ("x86/boot: Add
ACPI RSDP address to setup_header") should be reverted as setup_header
should contain only items set by legacy BIOS.
So revert said commit. Instead of fully reverting the depending
commit e7b66d16fe4172 ("x86/acpi, x86/boot: Take R
In case the RSDP address in struct boot_params is specified don't try
to find the table by searching, but take the address directly as set
by the boot loader.
Signed-off-by: Juergen Gross
---
arch/x86/include/uapi/asm/bootparam.h | 3 ++-
arch/x86/kernel/acpi/boot.c | 2 +-
2 files cha
Hi,
When we make grub with xen, we met below error, do you have any advice?
cd grub
./autogen.sh
./configure --target=amd64 --with-platform=xen --prefix=${PWD}/../pvgrub2
make
.
loader/i386/xen.c: In function 'grub_cmd_xen':
loader/i386/xen.c:650:10: error: too few arguments to function
flight 130576 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130576/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
build-arm64-xs
On Thu, Oct 11, 2018 at 6:05 PM Vlastimil Babka wrote:
>
> On 10/10/18 6:56 PM, Arun KS wrote:
> > On 2018-10-10 21:00, Vlastimil Babka wrote:
> >> On 10/5/18 10:10 AM, Arun KS wrote:
> >>> When free pages are done with higher order, time spend on
> >>> coalescing pages by buddy allocator can be r
flight 130531 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130531/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm6 xen-buildfail REGR. vs. 129475
build-i386
flight 130493 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130493/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken
build-arm64-xsm
This run is configured for baseline tests only.
flight 75614 xen-unstable real [real]
http://osstest.xensource.com/osstest/logs/75614/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-pygrub 22 leak-check/check
flight 130562 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130562/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
build-arm64-xs
flight 130552 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130552/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
build-arm64-xs
flight 130495 xen-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130495/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken
build-arm64-xsm
On Mon, Nov 19, 2018 at 09:30:58PM +, Wei Liu wrote:
> See https://gitlab.com/xen-project/people/liuw/xen/pipelines/37173009
>
> A pipeline while I was developing this series.
A (still in progress as of now) full pipeline
https://gitlab.com/xen-project/people/liuw/xen/pipelines/37175006
Wei.
... so that it can be passed on to test stage.
Note that xen is only extracted for x86_64 build since others may not
have that. Use a directory to account for possibly different file
names on Arm.
Signed-off-by: Wei Liu
---
.gitlab-ci.yml | 1 +
automation/scripts/build | 4
2 fi
Signed-off-by: Wei Liu
---
.gitlab-ci.yml | 2 +-
automation/scripts/build | 3 +++
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index 5678b552c4..28152e906d 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -8,7 +8,7 @@ stages:
-
Signed-off-by: Wei Liu
---
automation/build/README.md | 3 +++
automation/scripts/containerize | 8 +---
2 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/automation/build/README.md b/automation/build/README.md
index f6cfd46f1e..d8c8a18e33 100644
--- a/automation/build/READM
See https://gitlab.com/xen-project/people/liuw/xen/pipelines/37173009
A pipeline while I was developing this series.
Wei Liu (4):
automation: introduce CONTAINER_NO_PULL for containerize
automation: stash default config file for artifact extraction
automation: also specify xen binary as art
This patch introduces a new test stage into the pipeline and provides
a simple QEMU based smoke test.
Signed-off-by: Wei Liu
---
.gitlab-ci.yml | 19 +++
automation/scripts/qemu-smoke-x86-64.sh | 23 +++
2 files changed, 42 insertions(
flight 130468 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130468/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvopsbroken
build-arm64-xsm
flight 130482 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130482/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken
build-arm64-xsm
flight 130530 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130530/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
build-arm64-xs
On Fri, Nov 16, 2018 at 01:12:27PM +, Wei Liu wrote:
> 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
> ++---
On 19/11/2018 10:22, Jan Beulich wrote:
> @@ -3344,7 +3344,8 @@ x86_decode(
> break;
>
> case simd_128:
> -op_bytes = 16;
> +/* The special case here are MMX shift insns. */
"special case here is the MMX" or "special cases here are".
Otherwise, Acked-by: Andrew Coo
On 19/11/2018 10:21, Jan Beulich wrote:
> Note: vpadd* / vpsub* et al are put at seemingly the wrong slot of the
> big switch(). This is in anticipation of adding e.g. vpunpck* to those
> groups (see the legacy/VEX encoded case labels nearby to support this).
>
> Signed-off-by: Jan Beulich
Acked-
On 19/11/2018 10:21, Jan Beulich wrote:
> Include VPTEST{,N}M{B,D,Q,W} as once again possibly used by the compiler
> for comparison against all-zero vectors.
>
> Also table entries for a few more insns get their .d8s field set right
> away, again in order to not split and later re-combine the group
On 19/11/2018 10:19, Jan Beulich wrote:
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On 19/11/2018 10:14, Jan Beulich wrote:
> In order to be able to verify the 32-bit variant builds and runs,
> introduce a respective target (and the necessary other adjustments).
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
This seems to all work fine now.
___
On 19/11/2018 10:14, Jan Beulich wrote:
> Besides the already existing tests (which are going to be extended once
> respective ISA extension support is complete), let's also ensure for
> every individual insn that their Disp8 scaling (and memory access width)
> are correct.
>
> Signed-off-by: Jan B
On 19/11/2018 10:13, Jan Beulich wrote:
> Note: SDM Vol 2 rev 067 is not really consistent about EVEX.L'L for LIG
> insns - the only place where this is made explicit is a table in
> the section titled "Vector Length Orthogonality": While they
> tolerate 0, 1, and 2, a value of 3
On 19/11/2018 16:01, Andrew Cooper wrote:
> Sample run available here:
>
> https://gitlab.com/xen-project/people/andyhhp/xen/pipelines/37138805
>
> Note that the failure is due to missing "libx86: Work around GCC being unable
> to spill the PIC hard register" which was the trigger for doing this
On Thu, Nov 08, 2018 at 03:16:23PM +0100, Igor Mammedov wrote:
> On Mon, 5 Nov 2018 02:40:28 +0100
> Samuel Ortiz wrote:
>
> > XSDT is the 64-bit version of the legacy ACPI RSDT (Root System
> > Description Table). RSDT only allow for 32-bit addressses and have thus
> > been deprecated. Since AC
On 16/11/18 18:17, Maran Wilson wrote:
> 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 need
On 19/11/2018 10:13, Jan Beulich wrote:
> @@ -8828,12 +8837,7 @@ x86_emulate(
> dst.type = OP_NONE;
> break;
> default:
> -if ( (d & DstMask) != DstMem )
> -{
> -ASSERT_UNREACHABLE();
> -
On Mon, Nov 19, 2018 at 06:14:26PM +0100, Paolo Bonzini wrote:
> On 19/11/18 16:31, Igor Mammedov wrote:
> > I've tried to give suggestions how to restructure series
> > on per patch basis. In my opinion it quite possible to split
> > series in several smaller ones and it should really help with
>
This patch makes a few clarifications which were discussed on
IRC recently.
Specifically:
- Highlight the principle that license deviations
should be brought to the attention of maintainers
- Add a requirement for GPLv2 compatibility
- Restructure the document toghlight use-cases for
"N
On Mon, 2018-11-19 at 16:37 +0100, Igor Mammedov wrote:
> On Fri, 16 Nov 2018 19:42:08 +
> "Boeuf, Sebastien" wrote:
>
> >
> > 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:
> > >
> > > >
On 10/31/18 3:21 PM, Paul Durrant wrote:
> ...and re-name them to iommu_map/unmap() since they no longer necessarily
> operate on a single page.
>
> The P2M code currently contains many loops to deal with the fact that,
> while it may be require to handle page orders greater than 0, the
> IOMMU ma
On Mon, Nov 19, 2018 at 9:56 PM Mike Rapoport wrote:
>
> On Mon, Nov 19, 2018 at 08:43:09PM +0530, Souptick Joarder wrote:
> > Hi Mike,
> >
> > On Sat, Nov 17, 2018 at 8:07 PM Matthew Wilcox wrote:
> > >
> > > On Sat, Nov 17, 2018 at 12:26:38PM +0530, Souptick Joarder wrote:
> > > > On Fri, Nov 1
Apologies, the subject should have been, of course, "[PATCH V7 0/5] Fix
VGA logdirty related display freezes with altp2m", which I did paste in,
but ommited to uncomment.
Sorry,
Razvan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://l
The logdirty rangesets of the altp2ms need to be kept in sync with the
hostp2m. This means when iterating through the altp2ms, we need to
use the host p2m to clip the rangeset, not the indiviual altp2m's
value.
This change also:
- Documents that the end is non-inclusive
- Calculates an "inclusi
For now, only do allocation/deallocation; keeping them in sync
will be done in subsequent patches.
Logdirty synchronization will only be done for active altp2ms;
so allocate logdirty rangesets (copying the host logdirty
rangeset) when an altp2m is activated, and free it when
deactivated.
Write a
When an new altp2m view is created very early on guest boot, the
display will freeze (although the guest will run normally). This
may also happen on resizing the display. The reason is the way
Xen currently (mis)handles logdirty VGA: it intentionally
misconfigures VGA pages so that they will fault.
This series aims to prevent the display from freezing when
enabling altp2m and switching to a new view (and assorted problems
when resizing the display).
The first patch introduces p2m_{init,free}_logdirty(), the second
allocates a new logdirty rangeset for each new altp2m, and the
fourth propaga
change_range_type() invalidates gfn ranges to lazily change the type
of a range of gfns, and also modifies the logdirty rangesets of that
p2m. At the moment, it clips both down by the hostp2m.
While this will result in correct behavior, it's not entirely efficient,
since invalidated entries outsid
Add logdirty_ranges allocator / deallocator helpers.
p2m_init_logdirty() will not re-allocate if
p2m->logdirty ranges has already been allocated.
Move the rangeset deallocation call from p2m_teardown_hostp2m()
to p2m_free_one() - we will want this to apply to altp2ms
as well.
Signed-off-by: Razva
On Mon, Nov 19, 2018 at 04:27:39PM +, Ian Jackson wrote:
> * Use mkdir -p, rather than trying to only create /run/user/$uid.
> That helps if /run and/or /run/user do not exist, as they do in
> libxl-made chroots with recent libxl (which gets qemu to chroot).
>
> * Do all of this in the roo
On 19/11/18 16:31, Igor Mammedov wrote:
> I've tried to give suggestions how to restructure series
> on per patch basis. In my opinion it quite possible to split
> series in several smaller ones and it should really help with
> making series cleaner and easier/faster to review/amend/merge
> vs what
George Dunlap writes ("Re: [OSSTEST PATCH 1/3] ts-depriv-audit-qemu: Create
complete /run/user in appropriate root"):
> Implementing `rm -rf` in C is a reasonably large faff; and given that
> qemu shouldn't be able to write to it anyway, I figured simply doing an
> `rmdir` and failing if it failed
On 11/19/18 4:53 PM, Ian Jackson wrote:
> George Dunlap writes ("Re: [OSSTEST PATCH 1/3] ts-depriv-audit-qemu: Create
> complete /run/user in appropriate root"):
>> On 11/19/18 4:27 PM, Ian Jackson wrote:
>>> CC: George Dunlap
>>> Signed-off-by: Ian Jackson
>>
>> It doesn't look like this does
George Dunlap writes ("Re: [OSSTEST PATCH 1/3] ts-depriv-audit-qemu: Create
complete /run/user in appropriate root"):
> On 11/19/18 4:27 PM, Ian Jackson wrote:
> > CC: George Dunlap
> > Signed-off-by: Ian Jackson
>
> It doesn't look like this does an `rm -rf $qroot` afterwards. If on
> this s
flight 130430 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130430/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken
build-arm64-pvops
On 11/19/18 4:17 PM, Razvan Cojocaru wrote:
> On 11/19/18 5:58 PM, George Dunlap wrote:
>> On 11/17/18 6:58 PM, Razvan Cojocaru wrote:
>>> On 11/16/18 9:50 PM, Razvan Cojocaru wrote:
On 11/16/18 7:59 PM, George Dunlap wrote:
> On the other hand, we want the logdirty rangesets to actually m
On Sun, Nov 11, 2018 at 10:49:39AM -0800, H. Peter Anvin wrote:
> On 11/10/18 1:03 AM, Juergen Gross wrote:
> >
> > How would that help? The garabge data written could have the correct
> > terminal sentinel value by chance.
> >
> > That's why I re-used an existing field in setup_header (the versi
On 11/19/18 4:27 PM, Ian Jackson wrote:
> * Use mkdir -p, rather than trying to only create /run/user/$uid.
> That helps if /run and/or /run/user do not exist, as they do in
> libxl-made chroots with recent libxl (which gets qemu to chroot).
>
> * Do all of this in the root directory of the qe
flight 130507 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130507/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm6 xen-buildfail REGR. vs. 129475
build-amd64
On Mon, 19 Nov 2018, 15:57 Andrii Anisov, wrote:
> Julien,
>
>
> It's me again about your patch:)
>
> I've found this patch useful and even can give a motivation to have it
> in the mainline. The patch ensures that vgic_sync_from_lrs is performed
> on guest to hyp switch prior to any IRQ processi
On Mon, Nov 19, 2018 at 04:01:21PM +, Andrew Cooper wrote:
> Signed-off-by: Andrew Cooper
Acked-by: Wei Liu
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On Mon, Nov 19, 2018 at 04:01:20PM +, Andrew Cooper wrote:
> Signed-off-by: Andrew Cooper
Acked-by: Wei Liu
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Deployment note: I have copied this binary to the images directory in
Cambridge and Massachusetts. The corresponding patch to chiark-utils
is on its way to my upstream hat.
CC: George Dunlap
Signed-off-by: Ian Jackson
---
production-config | 2 +-
production-config-cambridge | 2 +-
libxl creates this directory with mode 0. That prevents
fishdescriptor from working. chmod it. This is OK for testing.
CC: George Dunlap
Signed-off-by: Ian Jackson
---
ts-depriv-audit-qemu | 1 +
1 file changed, 1 insertion(+)
diff --git a/ts-depriv-audit-qemu b/ts-depriv-audit-qemu
index 4
* Use mkdir -p, rather than trying to only create /run/user/$uid.
That helps if /run and/or /run/user do not exist, as they do in
libxl-made chroots with recent libxl (which gets qemu to chroot).
* Do all of this in the root directory of the qemu process, not our
own root directory. So it w
Coverity (CID 796599) points out that xen_pt_setup_vga() trusts
the rom->size field in the BIOS ROM from a PCI passthrough VGA
device, and uses it as an index into the memory which contains
the BIOS image. A corrupt BIOS ROM could therefore cause us to
index off the end of the buffer.
Check that t
On Mon, Nov 19, 2018 at 08:43:09PM +0530, Souptick Joarder wrote:
> Hi Mike,
>
> On Sat, Nov 17, 2018 at 8:07 PM Matthew Wilcox wrote:
> >
> > On Sat, Nov 17, 2018 at 12:26:38PM +0530, Souptick Joarder wrote:
> > > On Fri, Nov 16, 2018 at 11:59 PM Mike Rapoport wrote:
> > > > > + * vm_insert_ran
On 11/19/18 5:58 PM, George Dunlap wrote:
> On 11/17/18 6:58 PM, Razvan Cojocaru wrote:
>> On 11/16/18 9:50 PM, Razvan Cojocaru wrote:
>>> On 11/16/18 7:59 PM, George Dunlap wrote:
On the other hand, we want the logdirty rangesets to actually match the
host's rangesets; using altp2m->max_
>
> diff --git a/include/linux/page-flags.h b/include/linux/page-flags.h
> index 50ce1bddaf56..f91da3d0a67e 100644
> --- a/include/linux/page-flags.h
> +++ b/include/linux/page-flags.h
> @@ -670,7 +670,7 @@ PAGEFLAG_FALSE(DoubleMap)
> #define PAGE_TYPE_BASE 0xf000
> /* Reserve
Sample run available here:
https://gitlab.com/xen-project/people/andyhhp/xen/pipelines/37138805
Note that the failure is due to missing "libx86: Work around GCC being unable
to spill the PIC hard register" which was the trigger for doing this work.
Andrew Cooper (2):
automation: Add a 32bit
Signed-off-by: Andrew Cooper
---
CC: Wei Liu
CC: Doug Goldstein
---
.gitlab-ci.yml | 32
1 file changed, 32 insertions(+)
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index e7690e2..ad82c20 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -92,6 +92,38 @@ deb
Signed-off-by: Andrew Cooper
---
CC: Wei Liu
CC: Doug Goldstein
---
automation/build/debian/jessie-i386.dockerfile | 50 ++
1 file changed, 50 insertions(+)
create mode 100644 automation/build/debian/jessie-i386.dockerfile
diff --git a/automation/build/debian/jessie-i3
On 11/17/18 6:58 PM, Razvan Cojocaru wrote:
> On 11/16/18 9:50 PM, Razvan Cojocaru wrote:
>> On 11/16/18 7:59 PM, George Dunlap wrote:
>>> On the other hand, we want the logdirty rangesets to actually match the
>>> host's rangesets; using altp2m->max_mapped_pfn for this is clearly
>>> wrong. The ea
flight 130516 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130516/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
build-arm64-xs
On 19.11.2018 17:08, Roger Pau Monné wrote:
> On Mon, Nov 19, 2018 at 01:30:09PM +, Alexandru Stefan ISAILA wrote:
+/* Now transform our RWX values in a XENMEM_access_* constant. */
+if ( r == 0 && w == 0 && x == 0 )
+new_access = XENMEM_access_n;
+else
Julien,
It's me again about your patch:)
I've found this patch useful and even can give a motivation to have it
in the mainline. The patch ensures that vgic_sync_from_lrs is performed
on guest to hyp switch prior to any IRQ processing.
So, do you plan to push it for review? Could I do that
On 19.11.18 15:54, Julien Grall wrote:
You didn't get my point. You removed a parameter without explaining
why it is fine.
It is a pure optimization. If you look through the code, you can see
that callers of these functions already have a correspondent `struct
pending_irq` pointer. But they
On Fri, 16 Nov 2018 19:42:08 +
"Boeuf, Sebastien" wrote:
> 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 m
On 11/19/18 8:59 AM, Juergen Gross wrote:
> arch/x86/xen/spinlock.c includes several headers which are not needed.
> Remove the #includes.
>
> Signed-off-by: Juergen Gross
> ---
Reviewed-by: Boris Ostrovsky
___
Xen-devel mailing list
Xen-devel@list
On Fri, 16 Nov 2018 17:37:54 +0100
Paolo Bonzini wrote:
> 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 squas
>>> On 19.11.18 at 16:19, wrote:
> On 19/11/2018 15:14, Jan Beulich wrote:
> On 19.11.18 at 15:45, wrote:
>>> Versions of GCC before 5 can't compile cpuid.c, and fail with the rather
>>> cryptic:
>>>
>>> In file included from lib/x86/cpuid.c:3:0:
>>> lib/x86/cpuid.c: In function ‘x86_cpu
>>> On 15.11.18 at 22:47, wrote:
> For more historical context, see
> c/s c17b36d5dc792cfdf59b6de0213b168bec0af8e8
> c/s 04656384a1b9714e43db850c51431008e23450d8
>
> PVRDTSCP was an attempt to provide Xen-aware userspace with a stable monotonic
> clock, and enough information for said userspa
On 19/11/2018 15:14, Jan Beulich wrote:
On 19.11.18 at 15:45, wrote:
>> Versions of GCC before 5 can't compile cpuid.c, and fail with the rather
>> cryptic:
>>
>> In file included from lib/x86/cpuid.c:3:0:
>> lib/x86/cpuid.c: In function ‘x86_cpuid_policy_fill_native’:
>> include/xen/l
>>> On 19.11.18 at 15:45, wrote:
> Versions of GCC before 5 can't compile cpuid.c, and fail with the rather
> cryptic:
>
> In file included from lib/x86/cpuid.c:3:0:
> lib/x86/cpuid.c: In function ‘x86_cpuid_policy_fill_native’:
> include/xen/lib/x86/cpuid.h:25:5: error: inconsistent opera
Versions of GCC before 5 can't compile cpuid.c, and fail with the rather
cryptic:
In file included from lib/x86/cpuid.c:3:0:
lib/x86/cpuid.c: In function ‘x86_cpuid_policy_fill_native’:
include/xen/lib/x86/cpuid.h:25:5: error: inconsistent operand constraints in
an ‘asm’
asm ( "cpui
Hi Mike,
On Sat, Nov 17, 2018 at 8:07 PM Matthew Wilcox wrote:
>
> On Sat, Nov 17, 2018 at 12:26:38PM +0530, Souptick Joarder wrote:
> > On Fri, Nov 16, 2018 at 11:59 PM Mike Rapoport wrote:
> > > > + * vm_insert_range - insert range of kernel pages into user vma
> > > > + * @vma: user vma to ma
On Mon, Nov 19, 2018 at 01:30:09PM +, Alexandru Stefan ISAILA wrote:
> >> +/* Now transform our RWX values in a XENMEM_access_* constant. */
> >> +if ( r == 0 && w == 0 && x == 0 )
> >> +new_access = XENMEM_access_n;
> >> +else if ( r == 0 && w == 0 && x == 1 )
> >> +
flight 130494 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130494/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
freebsd fef1dcc92cfc7d9879928902d01ef3adce5e7f34
baseline version:
freebsd 16c74967439
On 19/11/2018 14:52, Mihai Donțu wrote:
> On Mon, 2018-11-19 at 13:29 +, Andrew Cooper wrote:
>> On 19/11/2018 13:11, Andrew Cooper wrote:
>>> Some versions of GCC can't compile cpuid.c, and fail with the rather
>>> cryptic:
>>>
>>> In file included from lib/x86/cpuid.c:3:0:
>>> lib/x86/cp
>>> On 14.11.18 at 12:57, wrote:
> Make sure the MSIX MMIO regions don't have p2m entries setup, so that
> accesses to them trap into the hypervisor and can be handled by vpci.
>
> Commit 042678762 ("x86/iommu: add map-reserved dom0-iommu option to
> map reserved memory ranges") added mappings fo
On Mon, 2018-11-19 at 13:29 +, Andrew Cooper wrote:
> On 19/11/2018 13:11, Andrew Cooper wrote:
> > Some versions of GCC can't compile cpuid.c, and fail with the rather
> > cryptic:
> >
> > In file included from lib/x86/cpuid.c:3:0:
> > lib/x86/cpuid.c: In function ‘x86_cpuid_policy_fill_
Versions of GCC before 5 can't compile cpuid.c, and fail with the rather
cryptic:
In file included from lib/x86/cpuid.c:3:0:
lib/x86/cpuid.c: In function ‘x86_cpuid_policy_fill_native’:
include/xen/lib/x86/cpuid.h:25:5: error: inconsistent operand constraints in
an ‘asm’
asm ( "cpui
flight 130424 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130424/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
build-arm64-pvops
>>> On 19.11.18 at 15:33, wrote:
> On 19/11/2018 13:51, Jan Beulich wrote:
>>> static inline void cpuid_leaf(uint32_t leaf, struct cpuid_leaf *l)
>>> {
>>> -asm ( "cpuid"
>>> - : "=a" (l->a), "=b" (l->b), "=c" (l->c), "=d" (l->d)
>>> +asm ( XCHG_BX
>>> + "cpuid;"
>>> +
>>> On 16.11.18 at 14:41, 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 reading di
On 19/11/2018 13:51, Jan Beulich wrote:
>> static inline void cpuid_leaf(uint32_t leaf, struct cpuid_leaf *l)
>> {
>> -asm ( "cpuid"
>> - : "=a" (l->a), "=b" (l->b), "=c" (l->c), "=d" (l->d)
>> +asm ( XCHG_BX
>> + "cpuid;"
>> + XCHG_BX
>> + : "=a" (l->a
On Fri, Nov 16, 2018 at 01:12:30PM +, Wei Liu wrote:
> 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.
All runners are properly configured at this point,
>>> On 19.11.18 at 14:30, wrote:
>> > +/* Now transform our RWX values in a XENMEM_access_* constant. */
>>> +if ( r == 0 && w == 0 && x == 0 )
>>> +new_access = XENMEM_access_n;
>>> +else if ( r == 0 && w == 0 && x == 1 )
>>> +new_access = XENMEM_access_x;
>>> +els
On 19/11/2018 14:23, Jan Beulich wrote:
On 19.11.18 at 15:08, wrote:
>> On 19/11/2018 13:51, Jan Beulich wrote:
>> On 19.11.18 at 14:11, wrote:
In practice, this is a collision between the output constraint and the GOT
which is held in %ebx when compiling with -fPIC for librari
>>> On 19.11.18 at 15:08, wrote:
> On 19/11/2018 13:51, Jan Beulich wrote:
> On 19.11.18 at 14:11, wrote:
>>> In practice, this is a collision between the output constraint and the GOT
>>> which is held in %ebx when compiling with -fPIC for libraries.
>>>
>>> This affects at least GCC 4.9 as
1 - 100 of 208 matches
Mail list logo
