flight 165076 qemu-mainline real [real]
flight 165105 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/165076/
http://logs.test-lab.xenproject.org/osstest/logs/165105/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be
flight 165052 xen-unstable real [real]
flight 165101 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/165052/
http://logs.test-lab.xenproject.org/osstest/logs/165101/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be r
flight 165097 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165097/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
> From: Jan Beulich
> Sent: Friday, September 17, 2021 7:00 PM
>
> We shouldn't silently truncate respective values.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Kevin Tian
> ---
> Strictly speaking we shouldn't use uint_t here at all. I wasn't sure
> though whether going straight to unsigned
> From: Jan Beulich
> Sent: Friday, September 17, 2021 7:00 PM
>
> Whether to clear an IOMMU's bit in the domain's bitmap should depend on
> all devices the domain can control. For the hardware domain this
> includes hidden devices, which are associated with DomXEN.
>
> While touching related lo
On Thu, 16 Sep 2021, Luca Fancellu wrote:
> > On 16 Sep 2021, at 02:16, Stefano Stabellini wrote:
> >
> > On Wed, 15 Sep 2021, Luca Fancellu wrote:
> >> This patch introduces the support for dom0less configuration
> >> when using UEFI boot on ARM, it permits the EFI boot to
> >> continue if no do
On Fri, 17 Sep 2021, Stefano Stabellini wrote:
> On Fri, 17 Sep 2021, Oleksandr wrote:
> > > > +
> > > > + dt_dprintk("Find unallocated memory for extended regions\n");
> > > > +
> > > > + unalloc_mem = rangeset_new(NULL, NULL, 0);
> > > > + if ( !unalloc_mem )
> > > > + return -ENO
On Fri, 17 Sep 2021, Luca Fancellu wrote:
> > On 16 Sep 2021, at 21:16, Stefano Stabellini wrote:
> >
> > On Thu, 16 Sep 2021, Jan Beulich wrote:
> >> On 16.09.2021 17:07, Luca Fancellu wrote:
> >>> I explain here my understanding on dom0less, this feature is used to
> >>> start domUs at
> >>> X
On Fri, 17 Sep 2021, Oleksandr wrote:
> > > +
> > > + dt_dprintk("Find unallocated memory for extended regions\n");
> > > +
> > > + unalloc_mem = rangeset_new(NULL, NULL, 0);
> > > + if ( !unalloc_mem )
> > > + return -ENOMEM;
> > > +
> > > + /* Start with all available RAM */
>
Hi Oleksandr,
Why do you want to enable pciback on ARM? Is it only to "disable" a PCI
device in Dom0 so that it can be safely assigned to a DomU?
I am asking because actually I don't think we want to enable the PV PCI
backend feature of pciback on ARM, right? That would clash with the PCI
assignm
On Fri, 17 Sep 2021, Jan Beulich wrote:
> The on-commit editing of 5260e8fb93f0 ("xen: re-define assign_pages and
> introduce a new function assign_page") didn't go quite far enough: A
> local variable and a function argument also would have wanted adjusting.
>
> Signed-off-by: Jan Beulich
Revie
On 17.09.21 18:52, Julien Grall wrote:
Hi Julien
On 16/09/2021 00:10, Oleksandr wrote:
+ * The extended regions will be prevalidated by the memory hotplug
path
+ * in Linux which requires for any added address range to be
within maximum
+ * possible addressable physical memory range for w
On Fri, 17 Sep 2021, Jan Beulich wrote:
> While the hypervisor hasn't been enforcing this, we would still better
> avoid issuing requests with GFNs not aligned to the requested order.
> Instead of altering the value also in the call to panic(), drop it
> there for being static and hence easy to det
On 17.09.21 18:48, Julien Grall wrote:
Hi Oleksandr,
Hi Julien
On 10/09/2021 23:18, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
The extended region (safe range) is a region of guest physical
address space which is unused and could be safely used to create
grant/foreign mappi
flight 165021 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165021/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 164993
test-amd64-i386-xl-qemut-win7-amd64 19
On 9/17/21 3:24 AM, Juergen Gross wrote:
> On 17.09.21 08:50, Jan Beulich wrote:
>> On 17.09.2021 08:47, Juergen Gross wrote:
>>> On 17.09.21 08:40, Jan Beulich wrote:
On 17.09.2021 03:34, Boris Ostrovsky wrote:
>
> On 9/16/21 11:04 AM, Jan Beulich wrote:
>> {
>> co
flight 165069 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165069/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On Fri, Sep 17, 2021, Peter Zijlstra wrote:
> On Thu, Sep 16, 2021 at 09:37:43PM +, Sean Christopherson wrote:
> So I don't mind exporting __static_call_return0, but exporting a raw
> static_call is much like exporting a function pointer :/
Ya, that part is quite gross.
> > The unregister pat
flight 165028 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165028/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-i386-libvirt
The pull request you sent on Fri, 17 Sep 2021 13:35:26 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
> for-linus-5.15b-rc2-tag
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/c6460daea23dcd160f2dc497c64b4c882ea1de69
Thank you!
--
Deet-doot-dot,
s/only/Only/ in subject
On Fri, Sep 17, 2021 at 12:48:03PM +0200, Jan Beulich wrote:
> The driver's module init function, pcifront_init(), invokes
> xen_pv_domain() first thing. That construct produces constant "false"
> when !CONFIG_XEN_PV. Hence there's no point building the driver in
> non-PV c
flight 165019 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165019/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-xsm 8 xen-boot fail REGR. vs. 152332
test-arm64-arm64-li
> On 17 Sep 2021, at 16:46, Roger Pau Monne wrote:
>
> Hello,
>
> The first two patches of this series allows setting the preisoutly host
> wide command line `gnttab` option on a per domain basis. That means
> selecting the max allowed grant table version and whether transitive
> grants are a
Hi Jan,
On 17/09/2021 14:47, Jan Beulich wrote:
On 17.09.2021 11:41, Andrew Cooper wrote:
On 17/09/2021 10:27, Julien Grall wrote:
Hi,
(+ some AWS folks)
On 17/09/2021 11:17, Jan Beulich wrote:
On 16.09.2021 19:52, Andrew Cooper wrote:
On 16/09/2021 13:30, Jan Beulich wrote:
On 16.09.2021
On 16/09/2021 00:10, Oleksandr wrote:
+ * The extended regions will be prevalidated by the memory hotplug path
+ * in Linux which requires for any added address range to be within
maximum
+ * possible addressable physical memory range for which the linear
mapping
+ * could be created.
+ * F
Hi Oleksandr,
On 10/09/2021 23:18, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
The extended region (safe range) is a region of guest physical
address space which is unused and could be safely used to create
grant/foreign mappings instead of wasting real RAM pages from
the domain mem
Allow setting max_grant_version to 0 in order to disable grant table
usage by a domain. This prevents allocating the grant-table structure
inside of Xen and requires guards to be added in several functions in
order to prevent dereferencing the structure.
Note that a domain without a grant table co
Restore the previous way of mapping the xenstore ring using foreign
memory. Use xenforeignmemory instead of libxc in order to avoid adding
another dependency on a unstable interface.
This in turn requires storing the gfn into xs_state_connection for
resume purposes, which breaks the current format
Exploiting the talloc clean up routines to close the Xen interfaces
is cumbersome, specially when atexit can be used to the same effect.
Convert xc and gnttab to use atexit which allows to drop one
indirection from the storing variables.
No functional change intended.
Signed-off-by: Roger Pau Mo
Introduce a new domain create field so that toolstack can specify the
maximum grant table version usable by the domain. This is plumbed into
xl and settable by the user as max_grant_version.
Previously this was only settable on a per host basis using the
gnttab command line option.
Signed-off-by:
This patch replaces the usage of xc_map_foreign_range with
xenforeignmemory_map from the stable xenforeignmemory library. Note
there are still other uses of libxc functions which prevents removing
the dependency.
No functional change intended.
Signed-off-by: Roger Pau Monné
---
tools/console/Ma
Introduce a new grant options flags field in domain create and use it
to signal whether transitive grants are allowed on the domain. This is
settable from xl using the transitive_grants option.
Signed-off-by: Roger Pau Monné
---
docs/man/xl.cfg.5.pod.in| 6 ++
docs/man/xl.conf.5
Hello,
The first two patches of this series allows setting the preisoutly host
wide command line `gnttab` option on a per domain basis. That means
selecting the max allowed grant table version and whether transitive
grants are allowed.
The last 4 patches attempt to implement support for creating
flight 165017 qemu-mainline real [real]
flight 165067 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/165017/
http://logs.test-lab.xenproject.org/osstest/logs/165067/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be
On Fri, Sep 17, 2021 at 3:26 AM Jan Beulich wrote:
>
> On 16.09.2021 17:04, Tamas K Lengyel wrote:
> > During fork reset operation the parent domain doesn't need to be gathered
> > using
> > rcu_lock_live_remote_domain_by_id as the fork reset doesn't modify anything
> > on
> > the parent. The pa
On 15.09.21 22:10, Oleksandr wrote:
Hi Stefano.
[snip]
+static int __init find_memory_holes(const struct kernel_info *kinfo,
+ struct meminfo *ext_regions)
+{
+ struct dt_device_node *np;
+ struct rangeset *mem_holes;
+ paddr_t start, end;
+ un
On 17/09/2021 14:10, Jan Beulich wrote:
> On 17.09.2021 10:45, Andrew Cooper wrote:
>> @@ -1336,13 +1338,16 @@ update_runq_load(const struct scheduler *ops,
>> {
>> struct {
>> uint64_t rq_avgload, b_avgload;
>> -unsigned rq_load:16, rq_id:8, shift:8;
>> -
On 17/09/2021 13:58, Jan Beulich wrote:
> On 17.09.2021 10:45, Andrew Cooper wrote:
>> --- a/xen/common/trace.c
>> +++ b/xen/common/trace.c
>> @@ -686,22 +686,21 @@ void __trace_var(u32 event, bool_t cycles, unsigned
>> int extra,
>> unsigned long flags;
>> u32 bytes_to_tail, bytes_to_wr
On 9/17/21 8:09 AM, Jan Beulich wrote:
> On 10.09.2021 22:13, Daniel P. Smith wrote:
>> --- a/xen/common/Kconfig
>> +++ b/xen/common/Kconfig
>> @@ -200,23 +200,20 @@ config XENOPROF
>>
>>If unsure, say Y.
>>
>> -config XSM
>> -bool "Xen Security Modules support"
>> +config XSM_CONFI
On 17.09.2021 10:45, Andrew Cooper wrote:
> @@ -1336,13 +1338,16 @@ update_runq_load(const struct scheduler *ops,
> {
> struct {
> uint64_t rq_avgload, b_avgload;
> -unsigned rq_load:16, rq_id:8, shift:8;
> -} d;
> -d.rq_id = rqd->id;
> -
On 17.09.2021 10:45, Andrew Cooper wrote:
> Four TRC_MEM_* records supply custom structures with tail padding, leaking
> stack rubble into the trace buffer. Three of the records were fine in 32-bit
> builds of Xen, due to the relaxed alignment of 64-bit integers, but
> POD_SUPERPAGE_SPLITER was br
From: Oleksandr Andrushchenko
Xen-pciback driver was designed to be built for x86 only. But it
can also be used by other architectures, e.g. Arm.
Re-structure the driver in a way that it can be built for other
platforms as well.
Signed-off-by: Oleksandr Andrushchenko
Signed-off-by: Anastasiia L
On 17.09.2021 10:45, Andrew Cooper wrote:
> --- a/xen/common/trace.c
> +++ b/xen/common/trace.c
> @@ -686,22 +686,21 @@ void __trace_var(u32 event, bool_t cycles, unsigned int
> extra,
> unsigned long flags;
> u32 bytes_to_tail, bytes_to_wrap;
> unsigned int rec_size, total_size;
>
On 10.09.2021 22:13, Daniel P. Smith wrote:
> Hidden behind macro magic is an alternative xsm hook interface dedicated for
> use when the dummy/default policy is the only one built. This alternative
> interface increases code complexity and code size in the core security
> framework of Xen.
What d
On 10.09.2021 22:13, Daniel P. Smith wrote:
> --- a/xen/common/Kconfig
> +++ b/xen/common/Kconfig
> @@ -200,23 +200,20 @@ config XENOPROF
>
> If unsure, say Y.
>
> -config XSM
> - bool "Xen Security Modules support"
> +config XSM_CONFIGURABLE
> + bool "Configure Xen Security Mod
Linus,
Please git pull the following tag:
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
for-linus-5.15b-rc2-tag
xen: branch for v5.15-rc2
It contains:
- The first hunk of a Xen swiotlb fixup series fixing multiple minor
issues and doing some small cleanups
- Some further Xen rel
> On 16 Sep 2021, at 21:16, Stefano Stabellini wrote:
>
> On Thu, 16 Sep 2021, Jan Beulich wrote:
>> On 16.09.2021 17:07, Luca Fancellu wrote:
>>> I explain here my understanding on dom0less, this feature is used to start
>>> domUs at
>>> Xen boot in parallel, the name is misleading but it do
Hidden devices are associated with DomXEN but usable by the
hardware domain. Hence they need flushing as well when all devices are
to have flushes invoked.
While there drop a redundant ATS-enabled check and constify the first
parameter of the involved function.
Signed-off-by: Jan Beulich
--- a/
We shouldn't silently truncate respective values.
Signed-off-by: Jan Beulich
---
Strictly speaking we shouldn't use uint_t here at all. I wasn't sure
though whether going straight to unsigned int wouldn't be viewed as
introducing inconsistencies.
---
v2: New.
--- a/xen/drivers/passthrough/vtd/io
Whether to clear an IOMMU's bit in the domain's bitmap should depend on
all devices the domain can control. For the hardware domain this
includes hidden devices, which are associated with DomXEN.
While touching related logic
- convert the "current device" exclusion check to a simple pointer
comp
It has occurred to me that the recent vPCI-related discussion about
hidden devices has some relevance also elsewhere. In the course of
addressing review comments of what is now patch 1 I then came to
notice yet another quirk.
1: VT-d: consider hidden devices when unmapping
2: VT-d: PCI segments ar
Hi Jan,
>>> In order to be sure to catch all uses like this one (including ones
>>> which make it upstream in parallel to yours), I think you will want
>>> to rename the original IO_TLB_SEGSIZE to e.g. IO_TLB_DEFAULT_SEGSIZE.
>>
>> I don't understand your point. Can you clarify this?
>
> There'
The code is unreachable for HVM or PVH, and it also makes little sense
in auto-translated environments. On Arm, with
xen_{create,destroy}_contiguous_region() both being stubs, I have a hard
time seeing what good the Xen specific variant does - the generic one
ought to be fine for all purposes there
xen_swiotlb and pci_xen_swiotlb_init() are only used within the file
defining them, so make them static and remove the stubs. Otoh
pci_xen_swiotlb_detect() has a use (as function pointer) from the main
pci-swiotlb.c file - convert its stub to a #define to NULL.
Signed-off-by: Jan Beulich
Reviewed
The driver's module init function, pcifront_init(), invokes
xen_pv_domain() first thing. That construct produces constant "false"
when !CONFIG_XEN_PV. Hence there's no point building the driver in
non-PV configurations.
Drop the (now implicit and generally wrong) X86 dependency: At present,
XEN_PV
While the hypervisor hasn't been enforcing this, we would still better
avoid issuing requests with GFNs not aligned to the requested order.
Instead of altering the value also in the call to panic(), drop it
there for being static and hence easy to determine without being part
of the panic message.
The primary intention really was the last patch, there you go (on top
of what is already in xen/tip.git for-linus-5.15) ...
1: swiotlb-xen: ensure to issue well-formed XENMEM_exchange requests
2: PCI: only build xen-pcifront in PV-enabled environments
3: xen/pci-swiotlb: reduce visibility of symbo
Hi Jan,
> On 17 Sep 2021, at 10:58, Jan Beulich wrote:
>
> The on-commit editing of 5260e8fb93f0 ("xen: re-define assign_pages and
> introduce a new function assign_page") didn't go quite far enough: A
> local variable and a function argument also would have wanted adjusting.
>
> Signed-off-by:
The on-commit editing of 5260e8fb93f0 ("xen: re-define assign_pages and
introduce a new function assign_page") didn't go quite far enough: A
local variable and a function argument also would have wanted adjusting.
Signed-off-by: Jan Beulich
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_all
On 17.09.2021 11:36, Roman Skakun wrote:
> I use Xen PV display. In my case, PV display backend(Dom0) allocates
> contiguous buffer via DMA-API to
> to implement zero-copy between Dom0 and DomU.
Why does the buffer need to be allocated by Dom0? If it was allocated
by DomU, it could use grants to g
On 17.09.2021 11:41, Andrew Cooper wrote:
> On 17/09/2021 10:27, Julien Grall wrote:
>> Hi,
>>
>> (+ some AWS folks)
>>
>> On 17/09/2021 11:17, Jan Beulich wrote:
>>> On 16.09.2021 19:52, Andrew Cooper wrote:
On 16/09/2021 13:30, Jan Beulich wrote:
> On 16.09.2021 13:10, Dmitry Isaikin wro
flight 165015 xen-unstable real [real]
flight 165046 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/165015/
http://logs.test-lab.xenproject.org/osstest/logs/165046/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be r
On 2021-09-17 10:36, Roman Skakun wrote:
Hi, Christoph
I use Xen PV display. In my case, PV display backend(Dom0) allocates
contiguous buffer via DMA-API to
to implement zero-copy between Dom0 and DomU.
Well, something's gone badly wrong there - if you have to shadow the
entire thing in a bou
On 17/09/2021 10:27, Julien Grall wrote:
> Hi,
>
> (+ some AWS folks)
>
> On 17/09/2021 11:17, Jan Beulich wrote:
>> On 16.09.2021 19:52, Andrew Cooper wrote:
>>> On 16/09/2021 13:30, Jan Beulich wrote:
On 16.09.2021 13:10, Dmitry Isaikin wrote:
> From: Dmitry Isaykin
>
> This s
Hi, Christoph
I use Xen PV display. In my case, PV display backend(Dom0) allocates
contiguous buffer via DMA-API to
to implement zero-copy between Dom0 and DomU.
When I start Weston under DomU, I got the next log in Dom0:
```
[ 112.554471] CPU: 0 PID: 367 Comm: weston Tainted: G O
5.10.0-yocto-st
Hi,
(+ some AWS folks)
On 17/09/2021 11:17, Jan Beulich wrote:
On 16.09.2021 19:52, Andrew Cooper wrote:
On 16/09/2021 13:30, Jan Beulich wrote:
On 16.09.2021 13:10, Dmitry Isaikin wrote:
From: Dmitry Isaykin
This significantly speeds up concurrent destruction of multiple domains on x86.
All three of these records have tail padding, leaking stack rubble into the
trace buffer. Introduce an explicit _pad field and have the compiler zero the
padding automatically.
Signed-off-by: Andrew Cooper
---
CC: George Dunlap
CC: Ian Jackson
CC: Jan Beulich
CC: Stefano Stabellini
CC: Wei L
There is no need for bitfields anywhere - use more sensible types. There is
also no need to cast 'd' to (unsigned char *) before passing it to a function
taking void *.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: George Dunlap
CC: Ian Jackson
CC: Jan Beulich
CC: Stefano Stabel
Four TRC_MEM_* records supply custom structures with tail padding, leaking
stack rubble into the trace buffer. Three of the records were fine in 32-bit
builds of Xen, due to the relaxed alignment of 64-bit integers, but
POD_SUPERPAGE_SPLITER was broken right from the outset.
We could pack the dat
Patches 1-3 fix actual or latent bugs causing uninitialised stack to leak into
the trace buffers. Xentrace is a developer/debugging activity restricted to
fully privileged entities, so the leaking of uninitialised stack contents is
not a security concern here.
Patches 4-6 are various pieces of cl
* Delete trailing whitespace
* Replace an opencoded DIV_ROUND_UP()
* Drop bogus smp_rmb() - spin_lock_irqsave() has full smp_mb() semantics.
Signed-off-by: Andrew Cooper
---
CC: George Dunlap
CC: Ian Jackson
CC: Jan Beulich
CC: Stefano Stabellini
CC: Wei Liu
CC: Julien Grall
CC: Dario Fa
It is pointless to write all 6 entries and only consume the useful subset.
bloat-o-meter shows quite how obscene the overhead is in vmx_vmexit_handler(),
weighing in at 11% of the function arranging unread zeroes on the stack, and
8% for svm_vmexit_handler().
add/remove: 0/0 grow/shrink: 0/20 up
In the case that 'extra' isn't a multiple of uint32_t, the calculation rounds
the number of bytes up, causing later logic to read unrelated bytes beyond the
end of the object.
Also, asserting that the object is within TRACE_EXTRA_MAX, but truncating it
in release builds is rude.
Instead, reject a
Hi Stefano,
> On 16 Sep 2021, at 22:20, Stefano Stabellini wrote:
>
> On Thu, 16 Sep 2021, Bertrand Marquis wrote:
>> Sanitize CTR_EL0 value between cores and taint Xen if incompatible
>> values are found.
>>
>> In the case of different i-cache types, the sanitize ctr_el0 will have a
>> sanitiz
Hi Stefano,
> On 16 Sep 2021, at 21:47, Stefano Stabellini wrote:
>
> acquire_domstatic_pages currently takes an unsigned long nr_mfns
> parameter, but actually it cannot handle anything larger than an
> unsigned int nr_mfns. That's because acquire_domstatic_pages is based on
> assign_pages whic
Hi Oleksandr, Stefano,
> On 14 Sep 2021, at 5:31 am, Oleksandr Andrushchenko
> wrote:
>
>
> On 14.09.21 00:02, Stefano Stabellini wrote:
>> On Mon, 13 Sep 2021, Oleksandr Andrushchenko wrote:
>>> On 10.09.21 15:01, Rahul Singh wrote:
Hi Stefano,
> On 10 Sep 2021, at 12:34 am, St
On 17.09.21 08:13, Jan Beulich wrote:
While working on XSA-361 and its follow-ups, I failed to spot another
place where the kernel mapping part of an operation was not treated the
same as the user space part. Detect and propagate errors and add a 2nd
pr_debug().
Signed-off-by: Jan Beulich
Rev
Hi Oleksandr,
> On 17 Sep 2021, at 7:13 am, Oleksandr Andrushchenko
> wrote:
>
> Hi, Rahul!
>
> On 15.09.21 23:33, Stefano Stabellini wrote:
>> On Wed, 15 Sep 2021, Rahul Singh wrote:
>>> Hi Oleksandr, Stefano,
>>>
On 15 Sep 2021, at 6:30 am, Oleksandr Andrushchenko
wrote:
>
On Thu, Sep 16, 2021 at 09:37:43PM +, Sean Christopherson wrote:
> On Sat, Aug 28, 2021, Peter Zijlstra wrote:
> Argh, sorry, I somehow managed to miss all of your replies. I'll get back to
> this series next week. Thanks for the quick response!
>
> > Lets keep the whole intel_pt crud insid
On 17.09.21 00:30, Stefano Stabellini wrote:
Hi Stefano
On Thu, 16 Sep 2021, Oleksandr wrote:
On Wed, 15 Sep 2021, Oleksandr wrote:
On Fri, 10 Sep 2021, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
The extended region (safe range) is a region of guest physical
address space whi
On 16.09.2021 17:04, Tamas K Lengyel wrote:
> During fork reset operation the parent domain doesn't need to be gathered
> using
> rcu_lock_live_remote_domain_by_id as the fork reset doesn't modify anything on
> the parent. The parent is also guaranteed to be paused while forks are active.
> This p
On 17.09.21 08:50, Jan Beulich wrote:
On 17.09.2021 08:47, Juergen Gross wrote:
On 17.09.21 08:40, Jan Beulich wrote:
On 17.09.2021 03:34, Boris Ostrovsky wrote:
On 9/16/21 11:04 AM, Jan Beulich wrote:
{
const struct desc_ptr *desc = this_cpu_ptr(&idt_desc);
+ unsigned i, co
82 matches
Mail list logo
