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 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 sem
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 Cla
>>> 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 out
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 21
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: x
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 31.01.1
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.
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
> Tra
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
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 wrot
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 some
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 --
xen/drivers/passthrough/amd/pci_amd_iommu
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
---
hw/block/dataplane/xe
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 frontend
.git
tags/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.
*
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 f8176b3c40..ca1
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é
-
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
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
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 BEG
> -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;
> ta...@tklengyel.com;
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 ; rcojoc...@bitdefender.
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 31
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 saveresto
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. 13184
>>> 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
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 ze
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 fork
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 of
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
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 1
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 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 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 do
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)
{
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 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 r
>>> 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 =
> + guest_h
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 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
ilable 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-bloc
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: xen-devel@lists.xenproject
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:
https://downloads.xenproject.org/releas
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
test-amd64-
>>> 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 parse
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 vcpu
>>> 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 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 h
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 req
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 ho
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, 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 candid
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 can
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
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: xen
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
test-amd64-i386-xl
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, j
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 xen/ar
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 sum
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, Julie
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
build-amd64-xsm
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 Linux
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 you
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 tree:
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 suspi
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;
> +}
> +
> +#ifde
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:
> > +{
> > +xen_argo_send_addr
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 i
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:
>
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 h
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:
> > +{
> > +XEN_GUEST_HANDLE_PARA
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
test-amd64-amd64-xl
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 tree
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
test-amd64-i386-libv
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:
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
build-i386-xsm
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 during
> -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 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 impl
>>> 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.
>>
>> Irres
>>> 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 performe
>>> 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 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 means
89 matches
Mail list logo
