Currently building the shim will modify shim.config in case some config
option was added or modified in the hypervisor.
Avoid that by copying shim.config to an intermediate file instead.
Signed-off-by: Juergen Gross
---
Not sure whether its worth to take that for 4.11.
In case the maintainers th
On 19/04/18 18:14, Andrew Cooper wrote:
> On 19/04/18 15:54, Wei Liu wrote:
>> On Thu, Apr 19, 2018 at 01:01:53PM +0200, Juergen Gross wrote:
>>> On 19/04/18 12:47, Jan Beulich wrote:
>>> On 19.04.18 at 12:30, wrote:
> --- a/tools/firmware/xen-dir/Makefile
> +++ b/tools/firmware/xen-di
On 20/04/18 01:04, Anchal Agarwal wrote:
>
> Hello,
>
> This patch reverts commit e91b2b1194335ca83d8a40fa4e0efd480bf2babe.
> evtchn are supposed to be masked during resume by irq subsytem
> however, they are not. This causes special interrupts like PV
> spinlock to cause kernel BUG() as it exp
Hello,
This patch reverts commit e91b2b1194335ca83d8a40fa4e0efd480bf2babe.
evtchn are supposed to be masked during resume by irq subsytem
however, they are not. This causes special interrupts like PV
spinlock to cause kernel BUG() as it expects the IRQ to be
masked. This causes instances that
On 20/04/18 01:00, Stefano Stabellini wrote:
> On Thu, 19 Apr 2018, Juergen Gross wrote:
>> On 19/04/18 10:06, Andrew Cooper wrote:
>>> On 18/04/2018 23:15, Stefano Stabellini wrote:
xen/arch/arm/configs/renesas.config | 80
+
1 file changed, 80
From: David Wang
CPUs may share an in-use channel. Hence clearing of a bit from
the cpumask (in hpet_broadcast_exit()) as well as setting one
(in hpet_broadcast_enter()) must not race evaluation of that same
cpumask. Therefore avoid evaluating the cpumask twice in
hpet_detach_channel(). Otherwise
On Thu, 19 Apr 2018, Jan Beulich wrote:
> >>> On 19.04.18 at 00:15, wrote:
> > Add a Xen build target to count the lines of code of the source files
> > built. Uses `cloc' to do the job.
> >
> > Generate the list of source files from the %.o targets, append output
> > to "sourcelist".
> >
> > Re
On 04/19/2018 02:18 PM, Andrew Cooper wrote:
> On 19/04/18 16:54, Natarajan, Janakarajan wrote:
>> On 4/13/2018 12:57 PM, Andrew Cooper wrote:
>>> On 04/04/18 00:01, Janakarajan Natarajan wrote:
@@ -63,6 +64,54 @@ avic_get_physical_id_entry(struct svm_domain *d,
unsigned int index)
On Thu, 19 Apr 2018, Juergen Gross wrote:
> On 19/04/18 10:06, Andrew Cooper wrote:
> > On 18/04/2018 23:15, Stefano Stabellini wrote:
> >> xen/arch/arm/configs/renesas.config | 80
> >> +
> >> 1 file changed, 80 insertions(+)
> >> create mode 100644 xen/arch/
On Thu, 19 Apr 2018, Lars Kurth wrote:
> 19/04/2018, 17:32, "Julien Grall" wrote:
>
>
>
> On 18/04/18 23:15, Stefano Stabellini wrote:
> > Hi all,
>
> Hi,
>
> > This patch series is the first step toward building a small certifiable
> > Xen hypervisor for A
On Thu, 19 Apr 2018, Jan Beulich wrote:
> >>> On 19.04.18 at 00:15, wrote:
> > --- /dev/null
> > +++ b/xen/drivers/passthrough/arm/Kconfig
> > @@ -0,0 +1,7 @@
> > +
> > +config HAS_SMMUv2
> > + bool "ARM SMMUv2 driver"
> > + default y
> > + depends on ARM
> > + ---help---
> > + Driver
On 04/19/2018 01:45 PM, Ian Jackson wrote:
> perror() is defined to fprintf(stderr,...). HACKING says
> fprintf(stderr,...) is wrong. So perror() is too.
>
> Signed-off-by: Ian Jackson
> CC: Paolo Bonzini
> CC: Markus Armbruster
> CC: Daniel P. Berrange
> CC: Michael Tokarev
> CC: Alistair
Hi Ian,
On 04/19/2018 01:45 PM, Ian Jackson wrote:
> Signed-off-by: Ian Jackson
> CC: Paolo Bonzini
> CC: Markus Armbruster
> CC: Daniel P. Berrange
> CC: Michael Tokarev
> ---
> v7: New patch
> ---
> os-posix.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/os
Jason Andryuk:
> On Thu, Apr 19, 2018 at 2:10 PM, Simon Gaiser
> wrote:
>> Jason Andryuk:
>>> A toolstack may delete the vif frontend and backend xenstore entries
>>> while xen-netfront is in the removal code path. In that case, the
>>> checks for xenbus_read_driver_state would return XenbusState
On 19/04/18 16:54, Natarajan, Janakarajan wrote:
> On 4/13/2018 12:57 PM, Andrew Cooper wrote:
>> On 04/04/18 00:01, Janakarajan Natarajan wrote:
>>> @@ -63,6 +64,54 @@ avic_get_physical_id_entry(struct svm_domain *d,
>>> unsigned int index)
>>> return &d->avic_physical_id_table[index];
>>>
On Thu, Apr 19, 2018 at 2:10 PM, Simon Gaiser
wrote:
> Jason Andryuk:
>> A toolstack may delete the vif frontend and backend xenstore entries
>> while xen-netfront is in the removal code path. In that case, the
>> checks for xenbus_read_driver_state would return XenbusStateUnknown, and
>> xennet_
Jason Andryuk:
> A toolstack may delete the vif frontend and backend xenstore entries
> while xen-netfront is in the removal code path. In that case, the
> checks for xenbus_read_driver_state would return XenbusStateUnknown, and
> xennet_remove would hang indefinitely. This hang prevents system
>
On Thu, Apr 19, 2018 at 11:14:02AM +0300, Oleksandr Andrushchenko wrote:
> On 04/18/2018 08:01 PM, Dongwon Kim wrote:
> >On Wed, Apr 18, 2018 at 09:38:39AM +0300, Oleksandr Andrushchenko wrote:
> >>On 04/17/2018 11:57 PM, Dongwon Kim wrote:
> >>>On Tue, Apr 17, 2018 at 09:59:28AM +0200, Daniel Vett
On 19/04/2018, 17:32, "Julien Grall" wrote:
On 18/04/18 23:15, Stefano Stabellini wrote:
> Hi all,
Hi,
> This patch series is the first step toward building a small certifiable
> Xen hypervisor for ARM boards.
>
> First, the series makes a few c
Hi,
This series seems to have some coding style problems. See output below for
more information:
Type: series
Message-id: 1524156319-11465-1-git-send-email-ian.jack...@eu.citrix.com
Subject: [Qemu-devel] [PATCH v7 00/16] xen: xen-domid-restrict improvements
=== TEST SCRIPT BEGIN ===
#!/bin/bash
Signed-off-by: Ian Jackson
CC: Paolo Bonzini
CC: Markus Armbruster
CC: Daniel P. Berrange
CC: Michael Tokarev
---
v7: New patch
---
os-posix.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/os-posix.c b/os-posix.c
index 0f59566..d4cf466 100644
--- a/os-posix.c
+++ b/o
This series provides necessary support for running qemu as a Xen
device model without power equivalent to root. In particular, it
makes -xen-domid-restrict effective.
Compared to v7, it addresses review comments. As a result, it has
grown a couple of new cleanup patches, including a few that I t
The last user was just removed; remove this function, accordingly.
Signed-off-by: Ian Jackson
---
include/hw/xen/xen_common.h | 22 --
1 file changed, 22 deletions(-)
diff --git a/include/hw/xen/xen_common.h b/include/hw/xen/xen_common.h
index 2eed6fc..5f1402b 100644
--- a/i
From: Ross Lagerwall
Saving the current state to xenstore may fail when running restricted
(in particular, after a migration). Therefore, don't report the error or
exit when running restricted. Toolstacks that want to allow running
QEMU restricted should instead make use of QMP events to listen
From: Ross Lagerwall
Xen unstable (to be in 4.11) has two new dmops, relocate_memory and
pin_memory_cacheattr. Use these to set up the VGA memory, replacing the
previous calls to libxc. This allows the VGA console to work properly
when QEMU is running restricted (-xen-domid-restrict).
Wrapper fu
xc_interface_open etc. is not going to work if we have dropped
privilege, but xendevicemodel_shutdown will if everything is new
enough.
xendevicemodel_shutdown is only availabe in Xen 4.10 and later, so
provide a stub for earlier versions.
Signed-off-by: Ian Jackson
Reviewed-by: Anthony PERARD
We are going to want to reuse this.
No functional change.
Signed-off-by: Ian Jackson
Reviewed-by: Anthony PERARD
Acked-by: Stefano Stabellini
---
hw/i386/xen/xen-hvm.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/hw/i386/xen/xen-hvm.c b/hw/i386/xen/xen-hvm.c
index
And insist that it works.
Drop individual use of xendevicemodel_restrict and
xenforeignmemory_restrict. These are not actually effective in this
version of qemu, because qemu has a large number of fds open onto
various Xen control devices.
The restriction arrangements are still not right, becaus
We need to restrict *all* the control fds that qemu opens. Looking in
/proc/PID/fd shows there are many; their allocation seems scattered
throughout Xen support code in qemu.
We must postpone the restrict call until roughly the same time as qemu
changes its uid, chroots (if applicable), and so on
From: Anthony PERARD
Xen libraries in 4.10 include a new xentoolcore library. This
contains the xentoolcore_restrict_all function which we are about to
want to use.
Signed-off-by: Ian Jackson
Acked-by: Stefano Stabellini
---
v5: More truthful commit message.
---
configure | 8 +---
1 fil
This is called just before os_setup_post. Currently none of the
accelerators provide this hook, but the Xen one is going to provide
one in a moment.
Signed-off-by: Ian Jackson
Reviewed-by: Eduardo Habkost
---
v7: New patch in this version of the series
---
accel/accel.c | 9 +
I'm going to be editing this function and it makes sense to clean up
this style problem in advance.
Signed-off-by: Ian Jackson
CC: Paolo Bonzini
CC: Markus Armbruster
CC: Daniel P. Berrange
CC: Michael Tokarev
---
os-posix.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
d
This allows the caller to specify a uid and gid to use, even if there
is no corresponding password entry. This will be useful in certain
Xen configurations.
We don't support just -runas because: (i) deprivileging without
calling setgroups would be ineffective (ii) given only a uid we don't
know
This avoids checkpatch misparsing (as statements) long function
definitions or declarations, which sometimes start with constructs
like this:
static inline int xendevicemodel_relocate_memory(
xendevicemodel_handle *dmod, domid_t domid, ...
The type xendevicemodel_handle does not conform t
We are going to want to use the dummy xendevicemodel_handle type in
new stub functions in the CONFIG_XEN_CTRL_INTERFACE_VERSION < 41000
section. So we need to provide that definition, or (as applicable)
include the appropriate header, earlier in the file.
(Ideally the newer compatibility layers w
This makes it much easier to find a particular thing in config.log.
The information may be lacking in other shells, resulting in harmless
empty output. (This is why we don't use the proper ${FUNCNAME[*]}
array syntax - other shells will choke on that.)
The extra output is only printed if configu
perror() is defined to fprintf(stderr,...). HACKING says
fprintf(stderr,...) is wrong. So perror() is too.
Signed-off-by: Ian Jackson
CC: Paolo Bonzini
CC: Markus Armbruster
CC: Daniel P. Berrange
CC: Michael Tokarev
CC: Alistair Francis
---
v7: New patch
---
os-posix.c | 8
1 fi
Ian Jackson writes ("Re: [PATCH 01/12] checkpatch: Add xendevicemodel_handle to
the list of types"):
> Paolo Bonzini writes ("Re: [PATCH 01/12] checkpatch: Add
> xendevicemodel_handle to the list of types"):
> > Or just rename it so that it is CamelCase. Then checkpatch will be happy.
>
> I can
On 4/17/2018 7:58 AM, Jan Beulich wrote:
On 04.04.18 at 01:01, wrote:
--- a/xen/include/asm-x86/hvm/vlapic.h
+++ b/xen/include/asm-x86/hvm/vlapic.h
@@ -137,6 +137,10 @@ void vlapic_ipi(struct vlapic *vlapic, uint32_t icr_low,
uint32_t icr_high);
int vlapic_apicv_write(struct vcpu *v, unsig
On Thu, Apr 19, 2018 at 05:14:38PM +0100, Andrew Cooper wrote:
> On 19/04/18 15:54, Wei Liu wrote:
> > On Thu, Apr 19, 2018 at 01:01:53PM +0200, Juergen Gross wrote:
> >> On 19/04/18 12:47, Jan Beulich wrote:
> >> On 19.04.18 at 12:30, wrote:
> --- a/tools/firmware/xen-dir/Makefile
>
On 19/04/18 15:54, Wei Liu wrote:
> On Thu, Apr 19, 2018 at 01:01:53PM +0200, Juergen Gross wrote:
>> On 19/04/18 12:47, Jan Beulich wrote:
>> On 19.04.18 at 12:30, wrote:
--- a/tools/firmware/xen-dir/Makefile
+++ b/tools/firmware/xen-dir/Makefile
@@ -41,21 +41,22 @@ linkfarm.st
On 4/13/2018 12:57 PM, Andrew Cooper wrote:
On 04/04/18 00:01, Janakarajan Natarajan wrote:
@@ -63,6 +64,54 @@ avic_get_physical_id_entry(struct svm_domain *d, unsigned
int index)
return &d->avic_physical_id_table[index];
}
+static void avic_vcpu_load(struct vcpu *v)
+{
+unsigne
On 19/04/18 16:44, Julien Grall wrote:
Hi,
On 18/04/18 23:15, Stefano Stabellini wrote:
Introduce a Kconfig option for the ARM SMMUv2 driver.
The driver is handling both SMMUv1 and SMMUv2.
I forgot to mention that by disabling the driver, you are going to
end-up giving the SMMU to Dom0.
On 4/13/2018 12:35 PM, Andrew Cooper wrote:
On 04/04/18 00:01, Janakarajan Natarajan wrote:
From: Suravee Suthikulpanit
Introduce AVIC base initialization code. This includes:
* Setting up per-VM data structures.
* Setting up per-vCPU data structure.
* Initializing AVIC-related
Hi,
On 18/04/18 23:15, Stefano Stabellini wrote:
Introduce a Kconfig option for the ARM SMMUv2 driver.
The driver is handling both SMMUv1 and SMMUv2.
Signed-off-by: Stefano Stabellini
CC: jbeul...@suse.com
---
xen/drivers/passthrough/Kconfig | 2 ++
xen/drivers/passthrough/arm/Kcon
Hi Stefano,
Please CC "THE REST" maintainers here.
On 18/04/18 23:15, Stefano Stabellini wrote:
All the UART drivers are silent options. Add one line descriptions so
that can be de/selected via menuconfig.
Signed-off-by: Stefano Stabellini
---
xen/drivers/char/Kconfig | 16
Hi Stefano,
On 18/04/18 23:15, Stefano Stabellini wrote:
Make it possible to disable the following existing kconfig options:
HAS_GICV3
HAS_ARM_HDLCD
HAS_MEM_ACCESS
Today they are silent option. This patch adds one line descriptions and
make them de/selectable.
Also, do not select VIDE
On 18/04/18 23:15, Stefano Stabellini wrote:
Hi all,
Hi,
This patch series is the first step toward building a small certifiable
Xen hypervisor for ARM boards.
First, the series makes a few changes to allow disabling more kconfig
options: most of them already exist but cannot be disabled.
On 19/04/18 16:25, Andrew Cooper wrote:
> All of this is as recommended by the Intel whitepaper:
>
> https://software.intel.com/sites/default/files/managed/1d/46/Retpoline-A-Branch-Target-Injection-Mitigation.pdf
>
> The 'RSB Alternative' bit in MSR_ARCH_CAPABILITIES may be set by a hypervisor
>
>>> On 19.04.18 at 16:28, wrote:
> Commit 0d31d16 (x86/setup: do not relocate Xen over current Xen image
> placement) disallowed src/dst images overlaps when relocating Xen image.
> Though it deliberately allowed destination region between __image_base__
> and (__image_base__ + XEN_IMG_OFFSET) ove
>>> On 19.04.18 at 16:25, wrote:
> All of this is as recommended by the Intel whitepaper:
>
> https://software.intel.com/sites/default/files/managed/1d/46/Retpoline-A-Branch-Target-Injection-Mitigation.pdf
>
> The 'RSB Alternative' bit in MSR_ARCH_CAPABILITIES may be set by a hypervisor
> to ind
On Thu, Apr 19, 2018 at 01:01:53PM +0200, Juergen Gross wrote:
> On 19/04/18 12:47, Jan Beulich wrote:
> On 19.04.18 at 12:30, wrote:
> >> --- a/tools/firmware/xen-dir/Makefile
> >> +++ b/tools/firmware/xen-dir/Makefile
> >> @@ -41,21 +41,22 @@ linkfarm.stamp: $(DEP_DIRS) $(DEP_FILES) FORCE
>
Commit 0d31d16 (x86/setup: do not relocate Xen over current Xen image
placement) disallowed src/dst images overlaps when relocating Xen image.
Though it deliberately allowed destination region between __image_base__
and (__image_base__ + XEN_IMG_OFFSET) overlaps with the end of source
image. And he
All of this is as recommended by the Intel whitepaper:
https://software.intel.com/sites/default/files/managed/1d/46/Retpoline-A-Branch-Target-Injection-Mitigation.pdf
The 'RSB Alternative' bit in MSR_ARCH_CAPABILITIES may be set by a hypervisor
to indicate that the virtual machine may migrate to
From: Oleksandr Andrushchenko
It is now only possible to control if multi-touch virtual device
is created or not (via the corresponding XenStore entries),
but keyboard and pointer devices are always created.
In some cases this is not desirable. For example, if virtual
keyboard device is exposed t
On 19/04/18 14:10, Jan Beulich wrote:
On 19.04.18 at 12:20, wrote:
>> From: David Wang
>>
>> CPUs may share an in-use channel. Hence clearing of a bit from
>> the cpumask (in hpet_broadcast_exit()) as well as setting one
>> (in hpet_broadcast_enter()) must not race evaluation of that same
>>
On 04/19/2018 04:19 PM, Juergen Gross wrote:
On 19/04/18 15:12, Oleksandr Andrushchenko wrote:
On 04/19/2018 04:10 PM, Jason Andryuk wrote:
On Thu, Apr 19, 2018 at 9:01 AM, Oleksandr Andrushchenko
wrote:
Ok, so I'll send v2 with the following changes:
diff --git a/drivers/input/misc/xen-kbdf
On 19/04/18 15:12, Oleksandr Andrushchenko wrote:
> On 04/19/2018 04:10 PM, Jason Andryuk wrote:
>> On Thu, Apr 19, 2018 at 9:01 AM, Oleksandr Andrushchenko
>> wrote:
>>> Ok, so I'll send v2 with the following changes:
>>>
>>> diff --git a/drivers/input/misc/xen-kbdfront.c
>>> b/drivers/input/misc
On 04/19/2018 04:10 PM, Jason Andryuk wrote:
On Thu, Apr 19, 2018 at 9:01 AM, Oleksandr Andrushchenko
wrote:
Ok, so I'll send v2 with the following changes:
diff --git a/drivers/input/misc/xen-kbdfront.c
b/drivers/input/misc/xen-kbdfront.c
index a3306aad40b0..d8cca212f737 100644
--- a/drivers/
On Thu, Apr 19, 2018 at 9:01 AM, Oleksandr Andrushchenko
wrote:
>
> Ok, so I'll send v2 with the following changes:
>
> diff --git a/drivers/input/misc/xen-kbdfront.c
> b/drivers/input/misc/xen-kbdfront.c
> index a3306aad40b0..d8cca212f737 100644
> --- a/drivers/input/misc/xen-kbdfront.c
> +++ b/d
On 04/19/2018 03:52 PM, Juergen Gross wrote:
On 19/04/18 13:44, Oleksandr Andrushchenko wrote:
On 04/19/2018 02:25 PM, Juergen Gross wrote:
On 18/04/18 17:04, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
It is now only possible to control if multi-touch virtual device
is crea
On 19/04/18 13:44, Oleksandr Andrushchenko wrote:
> On 04/19/2018 02:25 PM, Juergen Gross wrote:
>> On 18/04/18 17:04, Oleksandr Andrushchenko wrote:
>>> From: Oleksandr Andrushchenko
>>>
>>> It is now only possible to control if multi-touch virtual device
>>> is created or not (via the correspond
>>> On 19.04.18 at 12:26, wrote:
> On 19/04/18 10:00, Jan Beulich wrote:
> On 18.04.18 at 20:13, wrote:
>>> @@ -177,18 +192,37 @@ static bool __init retpoline_safe(void)
>>> * versions.
>>> */
>>> case 0x3d: /* Broadwell */
>>> -return ucode_rev >= 0x28;
>>> +
>>> On 19.04.18 at 12:20, wrote:
> From: David Wang
>
> CPUs may share an in-use channel. Hence clearing of a bit from
> the cpumask (in hpet_broadcast_exit()) as well as setting one
> (in hpet_broadcast_enter()) must not race evaluation of that same
> cpumask. Therefore avoid evaluating the cpu
>>> On 19.04.18 at 11:28, wrote:
> On Wed, Apr 18, 2018 at 10:00:53AM -0600, Jan Beulich wrote:
>> >>> On 18.04.18 at 12:26, wrote:
>> > @@ -1019,6 +1020,12 @@ void __init noreturn __start_xen(unsigned long
>> > mbi_p)
>> > bootsym(trampoline_xen_phys_start) = e;
>> >
>> >
On 04/19/2018 02:25 PM, Juergen Gross wrote:
On 18/04/18 17:04, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
It is now only possible to control if multi-touch virtual device
is created or not (via the corresponding XenStore entries),
but keyboard and pointer devices are always
On 18/04/18 17:04, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> It is now only possible to control if multi-touch virtual device
> is created or not (via the corresponding XenStore entries),
> but keyboard and pointer devices are always created.
Why don't you want to go tha
On 19/04/18 12:47, Jan Beulich wrote:
On 19.04.18 at 12:30, wrote:
>> --- a/tools/firmware/xen-dir/Makefile
>> +++ b/tools/firmware/xen-dir/Makefile
>> @@ -41,21 +41,22 @@ linkfarm.stamp: $(DEP_DIRS) $(DEP_FILES) FORCE
>> $(D): linkfarm.stamp
>> $(MAKE) -C $(D)/xen distclean
>>
>> -.P
On Thu, Apr 19, 2018 at 09:17:04AM +0100, Wei Liu wrote:
> On Mon, Apr 16, 2018 at 06:32:19PM +0100, Anthony PERARD wrote:
> > Signed-off-by: Anthony PERARD
>
> I guess DEBUG was broken because in three cases a gc was not in scope
> and in one case an argument was missing?
Yes
> With the commit
Sorry for top posting,
is someone working on the comments on this patch?
-Manish
On 03/10/2018 11:23 PM, Manish Jaggi wrote:
Hi Sameer,
On 02/09/2018 08:40 AM, Sameer Goel wrote:
This driver follows an approach similar to smmu driver. The intent here
is to reuse as much Linux code as possi
>>> On 19.04.18 at 12:30, wrote:
> --- a/tools/firmware/xen-dir/Makefile
> +++ b/tools/firmware/xen-dir/Makefile
> @@ -41,21 +41,22 @@ linkfarm.stamp: $(DEP_DIRS) $(DEP_FILES) FORCE
> $(D): linkfarm.stamp
> $(MAKE) -C $(D)/xen distclean
>
> -.PHONY: shim-%config
> -shim-%config: $(D) FORC
On Thu, Apr 19, 2018 at 09:35:44AM +0100, Roger Pau Monné wrote:
> On Thu, Apr 19, 2018 at 09:10:56AM +0100, Wei Liu wrote:
> > On Tue, Apr 17, 2018 at 02:03:41PM +0100, Roger Pau Monne wrote:
> > > Current interface to the gntdev in FreeBSD is wrong, and mostly worked
> > > out of luck before the
From: David Wang
CPUs may share an in-use channel. Hence clearing of a bit from
the cpumask (in hpet_broadcast_exit()) as well as setting one
(in hpet_broadcast_enter()) must not race evaluation of that same
cpumask. Therefore avoid evaluating the cpumask twice in
hpet_detach_channel(). Otherwise
Currently building the shim will modify shim.config in case some config
option was added or modified in the hypervisor.
Avoid that by copying shim.config to an intermediate file instead.
Signed-off-by: Juergen Gross
---
Not sure whether its worth to take that for 4.11.
In case the maintainers th
On 19/04/18 10:00, Jan Beulich wrote:
On 18.04.18 at 20:13, wrote:
>> @@ -151,6 +152,20 @@ static bool __init retpoline_safe(void)
>> boot_cpu_data.x86 != 6 )
>> return false;
>>
>> +if ( boot_cpu_has(X86_FEATURE_ARCH_CAPS) )
>> +{
>> +uint64_t caps;
>> +
On 18/04/18 23:52, Stefano Stabellini wrote:
On Tue, 17 Apr 2018, Julien Grall wrote:
On 17/04/18 11:52, Mirela Simonovic wrote:
Hi Julien,
Hi Mirela,
On Mon, Apr 16, 2018 at 5:21 PM, Julien Grall wrote:
On 16/04/18 14:41, Mirela Simonovic wrote:
On Mon, Apr 16, 2018 at 3:14 PM, Jul
On Wed, Apr 18, 2018 at 10:00:53AM -0600, Jan Beulich wrote:
> >>> On 18.04.18 at 12:26, wrote:
> > @@ -1019,6 +1020,12 @@ void __init noreturn __start_xen(unsigned long mbi_p)
> > bootsym(trampoline_xen_phys_start) = e;
> >
> > /*
> > + * All PTEs with PFNs a
Jan , thank you for your explanation.
Your mean : To avoid evaluating the cpumask twice in hpet_detach_channel(),
use a local variable to hold the result of cpumask_first(). Then
cpumask_empty() could be replaced by comparing the value of variable and
nr_cpu_ids.
I understand it right?
>>> On 19.04.18 at 10:56, wrote:
> Jan , thank you for your explanation.
> Your mean : To avoid evaluating the cpumask twice in hpet_detach_channel(),
> use a local variable to hold the result of cpumask_first(). Then
> cpumask_empty() could be replaced by comparing the value of variable a
>>> On 18.04.18 at 20:13, wrote:
> @@ -151,6 +152,20 @@ static bool __init retpoline_safe(void)
> boot_cpu_data.x86 != 6 )
> return false;
>
> +if ( boot_cpu_has(X86_FEATURE_ARCH_CAPS) )
> +{
> +uint64_t caps;
> +
> +rdmsrl(MSR_ARCH_CAPABILITIES, caps);
On 19/04/18 10:06, Andrew Cooper wrote:
> On 18/04/2018 23:15, Stefano Stabellini wrote:
>> xen/arch/arm/configs/renesas.config | 80
>> +
>> 1 file changed, 80 insertions(+)
>> create mode 100644 xen/arch/arm/configs/renesas.config
>>
>> diff --git a/xen/arch
flight 74633 distros-debian-wheezy real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74633/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-amd64-wheezy-netboot-pygrub 10 debian-di-install fail blocked
in 74581
baseline version
On Mon, Apr 16, 2018 at 04:26:09AM -0600, Jan Beulich wrote:
On 16.04.18 at 08:20, wrote:
>> On Fri, Apr 13, 2018 at 09:49:17AM -0600, Jan Beulich wrote:
>> On 30.03.18 at 08:59, wrote:
+static int do_microcode_update(void *_info)
+{
+struct microcode_info *info = _inf
On Thu, Apr 19, 2018 at 09:10:56AM +0100, Wei Liu wrote:
> On Tue, Apr 17, 2018 at 02:03:41PM +0100, Roger Pau Monne wrote:
> > Current interface to the gntdev in FreeBSD is wrong, and mostly worked
> > out of luck before the PTI FreeBSD fixes, when kernel and user-space
> > where sharing the same
On Mon, Apr 16, 2018 at 06:32:21PM +0100, Anthony PERARD wrote:
> This patch fix complilation error with #define DEBUG_RECEIVED of the
> macro DEBUG_REPORT_RECEIVED.
>
> error: field precision specifier ‘.*’ expects argument of type ‘int’, but
> argument 9 has type ‘ssize_t {aka long int}’
>
>
On 04/18/2018 07:01 PM, Dongwon Kim wrote:
On Wed, Apr 18, 2018 at 03:42:29PM +0300, Oleksandr Andrushchenko wrote:
On 04/18/2018 01:55 PM, Roger Pau Monné wrote:
On Wed, Apr 18, 2018 at 01:39:35PM +0300, Oleksandr Andrushchenko wrote:
On 04/18/2018 01:18 PM, Paul Durrant wrote:
-Original
On Mon, Apr 16, 2018 at 06:32:20PM +0100, Anthony PERARD wrote:
> Signed-off-by: Anthony PERARD
Acked-by: Wei Liu
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On Mon, Apr 16, 2018 at 06:32:19PM +0100, Anthony PERARD wrote:
> Signed-off-by: Anthony PERARD
I guess DEBUG was broken because in three cases a gc was not in scope
and in one case an argument was missing?
With the commit message updated:
Reviewed-by: Wei Liu
> ---
> tools/libxl/libxl_event
On 04/18/2018 08:01 PM, Dongwon Kim wrote:
On Wed, Apr 18, 2018 at 09:38:39AM +0300, Oleksandr Andrushchenko wrote:
On 04/17/2018 11:57 PM, Dongwon Kim wrote:
On Tue, Apr 17, 2018 at 09:59:28AM +0200, Daniel Vetter wrote:
On Mon, Apr 16, 2018 at 12:29:05PM -0700, Dongwon Kim wrote:
Yeah, I de
On Tue, Apr 17, 2018 at 02:03:41PM +0100, Roger Pau Monne wrote:
> Current interface to the gntdev in FreeBSD is wrong, and mostly worked
> out of luck before the PTI FreeBSD fixes, when kernel and user-space
> where sharing the same page tables.
where -> were?
>
> On FreeBSD ioctls have the siz
On 18/04/2018 23:15, Stefano Stabellini wrote:
> xen/arch/arm/configs/renesas.config | 80
> +
> 1 file changed, 80 insertions(+)
> create mode 100644 xen/arch/arm/configs/renesas.config
>
> diff --git a/xen/arch/arm/configs/renesas.config
> b/xen/arch/arm/co
>>> On 19.04.18 at 00:15, wrote:
> Add a Xen build target to count the lines of code of the source files
> built. Uses `cloc' to do the job.
>
> Generate the list of source files from the %.o targets, append output
> to "sourcelist".
>
> Remove sourcelist on clean, and also at the beginning of t
>>> On 19.04.18 at 00:15, wrote:
> --- /dev/null
> +++ b/xen/drivers/passthrough/arm/Kconfig
> @@ -0,0 +1,7 @@
> +
> +config HAS_SMMUv2
> + bool "ARM SMMUv2 driver"
> + default y
> + depends on ARM
> + ---help---
> + Driver for the ARM SMMU version 2, a popular IOMMU by ARM.
On 19/04/18 09:39, Jan Beulich wrote:
On 19.04.18 at 08:19, wrote:
>> On 18/04/18 18:12, Jan Beulich wrote:
>> On 18.04.18 at 10:30, wrote:
@@ -160,5 +161,20 @@ unsigned int flush_area_local(const void *va,
unsigned int flags)
local_irq_restore(irqfl);
>>> On 19.04.18 at 08:19, wrote:
> On 18/04/18 18:12, Jan Beulich wrote:
> On 18.04.18 at 10:30, wrote:
>>> @@ -160,5 +161,20 @@ unsigned int flush_area_local(const void *va, unsigned
>>> int flags)
>>>
>>> local_irq_restore(irqfl);
>>>
>>> +if ( flags & FLUSH_ROOT_PGTBL )
>>> +
>>> On 18.04.18 at 18:27, wrote:
> On 18/04/18 17:14, Jan Beulich wrote:
> On 18.04.18 at 18:02, wrote:
>>> On 18/04/18 16:43, Jan Beulich wrote:
>>> On 18.04.18 at 12:43, wrote:
> This avoids opencoding the functionality (and missing one bit of it), and
> and
> some comment
$ ./configure --help | grep -C 3 xen-pci-passthrough
virtfs VirtFS
mpath Multipath persistent reservation passthrough
xen xen backend driver support
xen-pci-passthrough
brlapi BrlAPI (Braile)
curlcurl connectivity
membarrier mem
>>> On 19.04.18 at 06:50, wrote:
> Thank you for reply. Maybe My description is not clear. Please allow me to
> explain it again.
> Multiple CPU may be share an channel(according to hpet_get_channel(), it is
> possible ). When one of them get the lock of
> channel(hpet_broadcast_exit()->hpet
98 matches
Mail list logo
