On Mon, Feb 4, 2019 at 6:41 AM Jan Beulich wrote:
>
> >>> On 31.01.19 at 05:28, wrote:
> > @@ -1237,6 +1864,54 @@ compat_argo_op(unsigned int cmd,
> > XEN_GUEST_HANDLE_PARAM(void) arg1,
> > break;
> > }
> >
> > +case XEN_ARGO_OP_sendv:
> > +{
> > +
On Mon, 28 Jan 2019, Julien Grall wrote:
> no_irq_type handlers are used when an IRQ does not have action attached.
> This is useful to detect misconfiguration between the interrupt
> controller and the software.
>
> Currently, all the handlers will do nothing on spurious interrupt. This
> means
branch xen-4.10-testing
xenbranch xen-4.10-testing
job build-i386-xsm
testid xen-build
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
*** Found and reproduced problem changeset ***
Bug is in
On 1/24/19 12:29 PM, Peter Maydell wrote:
> On Thu, 24 Jan 2019 at 17:40, Eric Blake wrote:
>>
>> On 1/24/19 2:45 AM, Markus Armbruster wrote:
>>
Signed-off-by: Michael Tokarev
Revieved-by: Michael Tokarev
>>>
>>> Typo in Reviewed-by.
>>
>> Should we tighten checkpatch.pl to flag
On Tue, 29 Jan 2019, Andrii Anisov wrote:
> On 29.01.19 17:17, Julien Grall wrote:
> > No we don't have to.
> I mean, EPAM systems as a XEN based virtualization solution provider have to
> handle that issue.
>
> > They have been lucky to see this working even on baremetal.
> > Set/Way operations
On Mon, Feb 4, 2019 at 7:12 AM Jan Beulich wrote:
>
> >>> On 31.01.19 at 05:28, wrote:
> > @@ -1802,6 +2157,21 @@ do_argo_op(unsigned int cmd,
> > XEN_GUEST_HANDLE_PARAM(void) arg1,
> > break;
> > }
> >
> > +case XEN_ARGO_OP_notify:
> > +{
> > +
branch xen-4.10-testing
xenbranch xen-4.10-testing
job build-amd64-xsm
testid xen-build
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
*** Found and reproduced problem changeset ***
Bug is in
flight 132804 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132804/
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. 132599
On Wed, 30 Jan 2019, Christopher Clark wrote:
> +#include
> +#include
> +
> +long
> +do_argo_op(unsigned int cmd, XEN_GUEST_HANDLE_PARAM(void) arg1,
> + XEN_GUEST_HANDLE_PARAM(void) arg2, unsigned long arg3,
> + unsigned long arg4)
> +{
> +return -ENOSYS;
> +}
> +
>
Hi Andrii,
Please send an update soon as I would like to get it in 4.12.
Juergen,
I would like to have your release ack on this.
On Fri, 25 Jan 2019, Andrii Anisov wrote:
> Stefan,
>
> I hope you would not mind if I put your Suggested-by for v2?
>
> On 25.01.19 08:55, Andrii Anisov wrote:
> -Original Message-
> From: Alexandru Stefan ISAILA [mailto:aisa...@bitdefender.com]
> Sent: 04 February 2019 11:37
> To: xen-devel@lists.xenproject.org
> Cc: Paul Durrant ; jbeul...@suse.com; Andrew
> Cooper ; Wei Liu ; Roger
> Pau Monne ; rcojoc...@bitdefender.com;
>
The current use of get/set_field_from/in_reg_u32() is both inefficient and
requires some ugly casting.
This patch defines a new bitfield structure (amd_iommu_pte) and uses this
structure in all PTE/PDE manipulation, resulting in much more readable
and compact code.
NOTE: This commit also fixes
On 2/4/19 10:28 AM, Andrii Anisov wrote:
Hello,
Hi Andrii,
On 01.02.19 19:40, Julien Grall wrote:
On 01/02/2019 16:53, Roger Pau Monné wrote:
On Thu, Jan 31, 2019 at 11:14:37PM +, Julien Grall wrote:
On 1/31/19 9:56 PM, Stefano Stabellini wrote:
On Thu, 31 Jan 2019, Julien Grall
Its last uses was removed by: 6d7c06c213ddcfabcafdc178ccef81736f85a7c2
"Remove broken Xen PV domain builder".
Signed-off-by: Anthony PERARD
Reviewed-by: Paul Durrant
---
configure | 19 ---
1 file changed, 19 deletions(-)
diff --git a/configure b/configure
index
From: Paul Durrant
Some frontend drivers will handle dynamic resizing of PV disks, so set up
the BlockDevOps resize_cb() method during xen_block_realize() to allow
this to be done.
Signed-off-by: Paul Durrant
Reviewed-by: Anthony PERARD
Signed-off-by: Anthony PERARD
---
From: Paul Durrant
There is a flaw in the xen-bus state model. To allow a frontend to re-
connect the backend state of an online XenDevice is transitioned from
Closed to InitWait, but this is currently done unilaterally which is
incorrect. The backend state should remain Closed until the
/pull-xen-20190204
for you to fetch changes up to 3149f183d7ca448b1dc30fe3d4acb9e367de01bf:
xen-block: handle resize callback (2019-02-04 11:04:49 +)
Xen queue
* xen-block, the Xen PV backend, now handles resize.
* configure
The behaviour of vpmu= being exclusive of vpmu=bts|ipc|arch is odd and
contrary to Xen's normal command line parsing behaviour. Rewrite the parsing
to use the normal form, but retain the previous behaviour where the use of
bts/ipc/arch implies vpmu=true.
Parts of the documenation are stale, most
On 2/4/19 10:32 AM, Andrii Anisov wrote:
Hello Julien,
Hi Andrii,
On 01.02.19 12:51, Julien Grall wrote:
I don't consider polluting your log a real problem.
Unless the system becomes an insane typewriter :)
I don't consider it as a critical issue because of the type of guest
we currently
On Fri, Feb 01, 2019 at 05:40:14PM +, Julien Grall wrote:
> Hi,
>
> On 01/02/2019 16:53, Roger Pau Monné wrote:
> > On Thu, Jan 31, 2019 at 11:14:37PM +, Julien Grall wrote:
> > > On 1/31/19 9:56 PM, Stefano Stabellini wrote:
> > > > On Thu, 31 Jan 2019, Julien Grall wrote:
> > > > > On
The current use of get/set_field_from/in_reg_u32() is both inefficient and
requires some ugly casting.
This patch defines a new bitfield structure (amd_iommu_dte) and uses this
structure in all DTE manipulation, resulting in much more readable and
compact code.
NOTE: This patch also includes
Reduce code size by ~300 lines.
Paul Durrant (2):
amd-iommu: use a bitfield for PTE/PDE
amd-iommu: use a bitfield for DTE
xen/drivers/passthrough/amd/iommu_guest.c | 55 +--
xen/drivers/passthrough/amd/iommu_map.c | 338 --
branch xen-4.10-testing
xenbranch xen-4.10-testing
job build-amd64
testid xen-build
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
*** Found and reproduced problem changeset ***
Bug is in tree:
flight 132772 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132772/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install
fail REGR. vs.
Hello,
On 01.02.19 19:40, Julien Grall wrote:
On 01/02/2019 16:53, Roger Pau Monné wrote:
On Thu, Jan 31, 2019 at 11:14:37PM +, Julien Grall wrote:
On 1/31/19 9:56 PM, Stefano Stabellini wrote:
On Thu, 31 Jan 2019, Julien Grall wrote:
On 31/01/2019 12:00, Andrii Anisov wrote:
On
branch xen-4.9-testing
xenbranch xen-4.9-testing
job build-i386
testid xen-build
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
*** Found and reproduced problem changeset ***
Bug is in tree: xen
On Sun, Feb 03, 2019 at 09:35:18PM +0100, Hans van Kranenburg wrote:
> xen-bugtool relies on code that has been removed in commit 9e8672f1c3
> "tools: remove xend and associated python modules", more than 5 years
> ago. Remove it, since it confuses users.
>
> -$ /usr/sbin/xen-bugtool
>
When Xen is detected via pkg-config, it isn't necessary to modify
LDFLAGS as modifying libs_softmmu is enough.
Reported-by: Peter Maydell
Signed-off-by: Michael Tokarev
Signed-off-by: Anthony PERARD
Reviewed-by: Peter Maydell
Reviewed-by: Michael Tokarev
Reviewed-by: Philippe Mathieu-Daudé
Patchew URL:
https://patchew.org/QEMU/20190204112803.11645-1-anthony.per...@citrix.com/
Hi,
This series failed the docker-mingw@fedora build test. Please find the testing
commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.
=== TEST SCRIPT
On 2/4/19 1:55 PM, Paul Durrant wrote:
-Original Message-
From: Alexandru Stefan ISAILA [mailto:aisa...@bitdefender.com]
Sent: 04 February 2019 11:37
To: xen-devel@lists.xenproject.org
Cc: Paul Durrant ; jbeul...@suse.com; Andrew
Cooper ; Wei Liu ; Roger
Pau Monne ;
flight 132798 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132798/
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
>>> On 04.02.19 at 18:18, wrote:
> On Mon, Feb 04, 2019 at 09:56:22AM -0700, Jan Beulich wrote:
>> >>> On 30.01.19 at 11:36, wrote:
>> > The assert was originally added to make sure that higher order
>> > regions (> PAGE_ORDER_4K) could not be used to bypass the
>> > mmio_ro_ranges check
On 05/02/2019 01:54, Stefano Stabellini wrote:
> On Mon, 28 Jan 2019, Julien Grall wrote:
>> no_irq_type handlers are used when an IRQ does not have action attached.
>> This is useful to detect misconfiguration between the interrupt
>> controller and the software.
>>
>> Currently, all the handlers
On i.MX8, we implemented partition reboot which means Cortex-A reboot
will not impact M4 cores and System control Unit core. However GICv3
is not reset because we also need to support A72 Cluster reboot without
affecting A53 Cluster.
The gic-v3 controller is configured with EOImode to 1, so
flight 132815 xen-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132815/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 132630
On 04/02/2019 20:08, Stefano Stabellini wrote:
> On Mon, 4 Feb 2019, Jan Beulich wrote:
> On 01.02.19 at 19:52, wrote:
>>
>> I'm not going to reply in detail to all of what you wrote about fanatics,
>> but I would like to say that I think compiler people less of that than
>> you appear to
>>> On 04.02.19 at 20:08, wrote:
> On Mon, 4 Feb 2019, Jan Beulich wrote:
>> And btw - I can't judge on b. anyway, as I still don't know what
>> exactly MISRA compliance is to mean, with the rules to adhere to
>> suitably justified.
>
> I can't pretend to know exactly what MISRAC compliance
branch xen-4.9-testing
xenbranch xen-4.9-testing
job build-i386-xsm
testid xen-build
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
*** Found and reproduced problem changeset ***
Bug is in tree:
>>> On 04.02.19 at 18:11, wrote:
> On Mon, Feb 04, 2019 at 09:41:34AM -0700, Jan Beulich wrote:
>> >>> On 30.01.19 at 11:36, wrote:
>> > Due to the recent changes in the iommu mapping logic, the start
>> > addresses provided need to be aligned to the order intended to be
>> > mapped.
>>
>>
> -Original Message-
> From: Julien Grall [mailto:julien.gr...@arm.com]
> Sent: 2019年2月3日 0:04
> To: Peng Fan ; sstabell...@kernel.org; jgr...@suse.com
> Cc: xen-devel@lists.xenproject.org
> Subject: Re: [PATCH for-4.12 v2] arm: gic-v3: deactivate SGI/PPI during
> initialization
>
>
>
>>> On 05.02.19 at 01:52, wrote:
> To make Argo's current Experimental status clearer, with the ABI stability
> status that accords, I propose the following addition to SUPPORT.md:
>
> Within section: ## Virtual Hardware, Hypervisor
>
> ### Argo: Inter-domain message delivery by hypercall.
>
>
On Mon, 4 Feb 2019, Roger Pau Monné wrote:
> > Yes, v7 was sent to address Jan and Julien's review comments in parallel
> > with our ongoing discussion on v5 macros. v7 also provided a checkpoint
> > for Argo testers to maximize test coverage as the series converges into
> > a Xen 4.12 merge
branch xen-4.9-testing
xenbranch xen-4.9-testing
job build-amd64-xsm
testid xen-build
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
*** Found and reproduced problem changeset ***
Bug is in tree:
On Mon, 4 Feb 2019, Jan Beulich wrote:
> >>> On 01.02.19 at 19:52, wrote:
>
> I'm not going to reply in detail to all of what you wrote about fanatics,
> but I would like to say that I think compiler people less of that than
> you appear to imply, at least the ones I know. In particular, they
in the Git repository at:
>
> https://xenbits.xen.org/git-http/people/aperard/qemu-dm.git
> tags/pull-xen-20190204
>
> for you to fetch changes up to 3149f183d7ca448b1dc30fe3d4acb9e367de01bf:
>
> xen-block: handle
On 2/4/19 5:14 PM, Roger Pau Monné wrote:
On Mon, Feb 04, 2019 at 02:00:40PM +0200, Razvan Cojocaru wrote:
On 2/4/19 1:55 PM, Paul Durrant wrote:
-Original Message-
From: Alexandru Stefan ISAILA [mailto:aisa...@bitdefender.com]
Sent: 04 February 2019 11:37
To:
Hi all,
Xen 4.12 rc2 is tagged. You can check that out from xen.git:
git://xenbits.xen.org/xen.git 4.12-rc2
For your convenience there is also a tarball at:
https://downloads.xenproject.org/release/xen/4.12-rc2/xen-4.12-rc2.tar.gz
And the signature is at:
flight 132770 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132770/
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. 129313
>>> On 04.02.19 at 15:58, wrote:
> On 04/02/2019 14:44, Jan Beulich wrote:
> On 04.02.19 at 15:22, wrote:
>>> On 04/02/2019 13:53, Jan Beulich wrote:
>>> On 04.02.19 at 12:41, wrote:
> @@ -64,37 +54,37 @@ static DEFINE_PER_CPU(struct vcpu *, last_vcpu);
> static int __init
On 04/02/2019 17:06, Jan Beulich wrote:
On 04.02.19 at 15:58, wrote:
>> On 04/02/2019 14:44, Jan Beulich wrote:
>> On 04.02.19 at 15:22, wrote:
On 04/02/2019 13:53, Jan Beulich wrote:
On 04.02.19 at 12:41, wrote:
>> @@ -64,37 +54,37 @@ static DEFINE_PER_CPU(struct
On Sun, Feb 03, 2019 at 10:04:29AM -0800, Christopher Clark wrote:
> On Thu, Jan 31, 2019 at 5:39 AM Roger Pau Monné wrote:
> >
> > On Wed, Jan 30, 2019 at 08:05:30PM -0800, Christopher Clark wrote:
> > > On Tue, Jan 22, 2019 at 6:19 AM Roger Pau Monné
> > > wrote:
> > > >
> > > > On Mon, Jan
Hello Julien,
On 01.02.19 12:51, Julien Grall wrote:
I don't consider polluting your log a real problem.
Unless the system becomes an insane typewriter :)
I don't consider it as a critical issue because of the type of guest we
currently support, so it is not in my queue for Xen 4.12 fixes.
Ping, any thoughts on this are appreciated.
Regards,
Alex
On 11.01.2019 17:37, Alexandru Stefan ISAILA wrote:
> This is done so hvmemul_linear_to_phys() can be called from
> hvmemul_map_linear_addr()
>
> Signed-off-by: Alexandru Isaila
> ---
> xen/arch/x86/hvm/emulate.c | 181
flight 132776 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132776/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 132745
test-armhf-armhf-libvirt-raw 13
>>> On 04.02.19 at 12:41, wrote:
> --- a/docs/misc/xen-command-line.pandoc
> +++ b/docs/misc/xen-command-line.pandoc
> @@ -2088,36 +2088,36 @@ Use Virtual Processor ID support if available. This
> prevents the need for TLB
> flushes on VM entry and exit, increasing performance.
>
> ### vpmu
On Mon, Feb 04, 2019 at 01:58:24PM +, Wei Liu wrote:
> This utility can't possibly work with modern Xen setup: none of the
> sysfs path used (under /sys/devices/xen-backend) is documented as
> stable ABI in upstream Linux kernel.
>
> Archaeology shows that the path used could have been part
On 04/02/2019 13:53, Jan Beulich wrote:
On 04.02.19 at 12:41, wrote:
>> --- a/docs/misc/xen-command-line.pandoc
>> +++ b/docs/misc/xen-command-line.pandoc
>> @@ -2088,36 +2088,36 @@ Use Virtual Processor ID support if available. This
>> prevents the need for TLB
>> flushes on VM entry and
>>> On 31.01.19 at 05:28, wrote:
> @@ -1237,6 +1864,54 @@ compat_argo_op(unsigned int cmd,
> XEN_GUEST_HANDLE_PARAM(void) arg1,
> break;
> }
>
> +case XEN_ARGO_OP_sendv:
> +{
> +xen_argo_send_addr_t send_addr;
> +xen_argo_iov_t iovs[XEN_ARGO_MAXIOV];
> +
On 04.02.19 13:21, Julien Grall wrote:
What I meant is the virtual address stays the same but the guest physical
address may change. I don't see how this could be broken today, can you explain
it?
I suppose guest's mapping change is not quite atomic from the hypervisor point
of view, so
On 04.02.19 13:36, Julien Grall wrote:
That's a good news! Let me try to address your concerns below one by one.
Lets do it:)
And they employ KPTI enabled kernel in the BSP.
KPTI is going to work on Xen. There are no known issue with Linux as the
virtual address is not going to be re-used
Hi,
Sorry for the formatting.
On Mon, 4 Feb 2019, 15:52 Andrii Anisov, wrote:
>
>
> On 04.02.19 13:21, Julien Grall wrote:
> > What I meant is the virtual address stays the same but the guest
> physical address may change. I don't see how this could be broken today,
> can you explain it?
>
> I
On 04/02/2019 14:58, Wei Liu wrote:
> This utility can't possibly work with modern Xen setup: none of the
> sysfs path used (under /sys/devices/xen-backend) is documented as
> stable ABI in upstream Linux kernel.
>
> Archaeology shows that the path used could have been part of the
> xenolinux
On 04/02/2019 13:58, Wei Liu wrote:
> This utility can't possibly work with modern Xen setup: none of the
> sysfs path used (under /sys/devices/xen-backend) is documented as
> stable ABI in upstream Linux kernel.
>
> Archaeology shows that the path used could have been part of the
> xenolinux fork
On 04/02/2019 14:44, Jan Beulich wrote:
On 04.02.19 at 15:22, wrote:
>> On 04/02/2019 13:53, Jan Beulich wrote:
>> On 04.02.19 at 12:41, wrote:
@@ -64,37 +54,37 @@ static DEFINE_PER_CPU(struct vcpu *, last_vcpu);
static int __init parse_vpmu_params(const char *s)
{
This utility can't possibly work with modern Xen setup: none of the
sysfs path used (under /sys/devices/xen-backend) is documented as
stable ABI in upstream Linux kernel.
Archaeology shows that the path used could have been part of the
xenolinux fork which never got upstreamed.
It's utility is
flight 132841 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132841/
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 04.02.19 at 15:22, wrote:
> On 04/02/2019 13:53, Jan Beulich wrote:
> On 04.02.19 at 12:41, wrote:
>>> @@ -64,37 +54,37 @@ static DEFINE_PER_CPU(struct vcpu *, last_vcpu);
>>> static int __init parse_vpmu_params(const char *s)
>>> {
>>> const char *ss;
>>> +int rc = 0, val;
On Fri, Jan 11, 2019 at 03:37:45PM +, Alexandru Stefan ISAILA wrote:
> This patch aims to have mem access vm events sent from the emulator.
> This is useful in the case of page-walks that have to emulate
> instructions in access denied pages.
>
> We use hvmemul_map_linear_addr() ro intercept
>>> On 31.01.19 at 05:28, wrote:
> @@ -1802,6 +2157,21 @@ do_argo_op(unsigned int cmd,
> XEN_GUEST_HANDLE_PARAM(void) arg1,
> break;
> }
>
> +case XEN_ARGO_OP_notify:
> +{
> +XEN_GUEST_HANDLE_PARAM(xen_argo_ring_data_t) ring_data_hnd =
> +
On Mon, Feb 04, 2019 at 02:00:40PM +0200, Razvan Cojocaru wrote:
> On 2/4/19 1:55 PM, Paul Durrant wrote:
> > > -Original Message-
> > > From: Alexandru Stefan ISAILA [mailto:aisa...@bitdefender.com]
> > > Sent: 04 February 2019 11:37
> > > To: xen-devel@lists.xenproject.org
> > > Cc: Paul
On Mon, Jan 14, 2019 at 6:47 AM Wei Liu wrote:
>
> Hi all
>
> The locking scheme seems to be remaining sticking point. The rest are
> mostly cosmetic issues (FAOD, they still need to be addressed). Frankly
> I don't think there is enough time to address all the technical details,
> but let me
branch xen-4.9-testing
xenbranch xen-4.9-testing
job build-amd64
testid xen-build
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
*** Found and reproduced problem changeset ***
Bug is in tree:
Hi all,
from my perspective we have enough momentum to move forward, albeit some
prospective attendees are still confirming their travel plans. I can
accommodate a maximum if 15, but possibly, a few more. With this in Mind,
please start booking flights.
Location:
The Citrix office in Milton,
On 04/02/2019 09:16, Jan Beulich wrote:
On 01.02.19 at 18:09, wrote:
>> On 01/02/2019 16:55, Jan Beulich wrote:
>> On 01.02.19 at 17:25, wrote:
If it were just getting insn_len incorrectly as 0, then the guest would
livelock as we wouldn't inject the #DB with trap semantics it
flight 132779 xen-4.11-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132779/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install
fail never pass
On Wed, Jan 30, 2019 at 8:14 PM Christopher Clark
wrote:
>
> On Fri, Jan 25, 2019 at 10:55 AM Christopher Clark
> wrote:
> >
> > On Thu, Jan 24, 2019 at 2:08 AM Julien Grall wrote:
> > > [...]
> > > Sorry for noticing quite late in the process. Don't you need to add the
> > > hypercall in
>>> On 30.01.19 at 11:36, wrote:
> The assert was originally added to make sure that higher order
> regions (> PAGE_ORDER_4K) could not be used to bypass the
> mmio_ro_ranges check performed by p2m_type_to_flags.
>
> This however is already checked in set_mmio_p2m_entry, which makes
> sure that
On Mon, Feb 04, 2019 at 09:41:34AM -0700, Jan Beulich wrote:
> >>> On 30.01.19 at 11:36, wrote:
> > Due to the recent changes in the iommu mapping logic, the start
> > addresses provided need to be aligned to the order intended to be
> > mapped.
>
> Irrespective of your reply to Wei's similar
>>> On 30.01.19 at 11:36, wrote:
> Due to the recent changes in the iommu mapping logic, the start
> addresses provided need to be aligned to the order intended to be
> mapped.
Irrespective of your reply to Wei's similar request (where you've
provided links to mails showing crashes) I'd like you
On 30/01/2019 10:36, Roger Pau Monne wrote:
Subject s/ntp/npt/
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On Mon, Feb 04, 2019 at 09:56:22AM -0700, Jan Beulich wrote:
> >>> On 30.01.19 at 11:36, wrote:
> > The assert was originally added to make sure that higher order
> > regions (> PAGE_ORDER_4K) could not be used to bypass the
> > mmio_ro_ranges check performed by p2m_type_to_flags.
> >
> > This
Hi,
On 2/4/19 12:53 PM, Roger Pau Monné wrote:
On Fri, Feb 01, 2019 at 05:40:14PM +, Julien Grall wrote:
Hi,
On 01/02/2019 16:53, Roger Pau Monné wrote:
On Thu, Jan 31, 2019 at 11:14:37PM +, Julien Grall wrote:
On 1/31/19 9:56 PM, Stefano Stabellini wrote:
On Thu, 31 Jan 2019,
flight 132783 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132783/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i3866 xen-buildfail REGR. vs. 130954
Hi Andrii,
On 2/4/19 3:19 PM, Andrii Anisov wrote:
On 04.02.19 13:36, Julien Grall wrote:
That's a good news! Let me try to address your concerns below one by one.
Lets do it:)
And they employ KPTI enabled kernel in the BSP.
KPTI is going to work on Xen. There are no known issue with
Hi Christopher,
On 2/4/19 8:32 PM, Christopher Clark wrote:
On Wed, Jan 30, 2019 at 8:14 PM Christopher Clark
wrote:
On Fri, Jan 25, 2019 at 10:55 AM Christopher Clark
wrote:
On Thu, Jan 24, 2019 at 2:08 AM Julien Grall wrote:
[...]
Sorry for noticing quite late in the process. Don't
>>> On 01.02.19 at 18:09, wrote:
> On 01/02/2019 16:55, Jan Beulich wrote:
> On 01.02.19 at 17:25, wrote:
>>> If it were just getting insn_len incorrectly as 0, then the guest would
>>> livelock as we wouldn't inject the #DB with trap semantics it requires,
>> I'm confused again: Why trap
On Sun, Feb 03, 2019 at 09:56:26AM -0800, Christopher Clark wrote:
> On Thu, Jan 31, 2019 at 3:01 AM Roger Pau Monné wrote:
> >
> > On Thu, Jan 31, 2019 at 03:35:23AM -0700, Jan Beulich wrote:
> > > >>> On 31.01.19 at 11:18, wrote:
> > > > On Wed, Jan 30, 2019 at 08:10:28PM -0800, Christopher
On Fri, 2019-02-01 at 10:59 +0100, Juergen Gross wrote:
> On 01/02/2019 10:50, Jan Beulich wrote:
> > > > > On 01.02.19 at 08:26, wrote:
> > >
> > > The periodic timer is used via VCPUOP_set_periodic_timer only,
> > > and
> > > today's Linux kernel isn't using it at all. So I guess this timer
>
>>> On 01.02.19 at 19:52, wrote:
I'm not going to reply in detail to all of what you wrote about fanatics,
but I would like to say that I think compiler people less of that than
you appear to imply, at least the ones I know. In particular, they can
be convinced of there being bugs by pointing
89 matches
Mail list logo
