On 19.01.21 11:57, Roger Pau Monne wrote:
This is inline with the specification described in blkif.h:
* discard-granularity: should be set to the physical block size if
node is not present.
* discard-alignment, discard-secure: should be set to 0 if node not
present.
This was detecte
On 26.01.21 18:01, David Woodhouse wrote:
From: David Woodhouse
In commit 3499ba8198ca ("xen: Fix event channel callback via INTX/GSI")
I reworked the triggering of xenbus_probe().
I tried to simplify things by taking out the workqueue based startup
triggered from wake_waiting(); the somewhat
These are grouped into a series largely because of their origin,
not so much because there are (heavy) dependencies among them.
The main change from v4 is the dropping of the two patches trying
to do away with the double event lock acquires in interdomain
channel handling. See also the individual p
Neither evtchn_status() nor domain_dump_evtchn_info() nor
flask_get_peer_sid() need to hold the per-domain lock - they all only
read a single channel's state (at a time, in the dump case).
Signed-off-by: Jan Beulich
---
v4: New.
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@
Especially for the use in evtchn_move_pirqs() (called when moving a vCPU
across pCPU-s) and the ones in EOI handling in PCI pass-through code,
serializing perhaps an entire domain isn't helpful when no state (which
isn't e.g. further protected by the per-channel lock) changes.
Unfortunately this i
port_is_valid() and evtchn_from_port() are fine to use without holding
any locks. Accordingly acquire the per-domain lock slightly later in
evtchn_close() and evtchn_bind_vcpu().
Signed-off-by: Jan Beulich
---
v4: New.
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -610,17
The combination is pretty common, so adding a simple local helper seems
worthwhile. Make it const- and type-correct, in turn requiring the
two called function to also be const-correct (and at this occasion also
make them type-correct).
Signed-off-by: Jan Beulich
Acked-by: Julien Grall
---
v4: Ne
First of all avoid "long" when "int" suffices, i.e. in particular when
merely conveying error codes. 32-bit values are slightly cheaper to
deal with on x86, and their processing is at least no more expensive on
Arm. Where possible use evtchn_port_t for port numbers and unsigned int
for other unsign
The per-vCPU virq_lock, which is being held anyway, together with there
not being any call to evtchn_port_set_pending() when v->virq_to_evtchn[]
is zero, provide sufficient guarantees. Undo the lock addition done for
XSA-343 (commit e045199c7c9c "evtchn: address races with
evtchn_reset()"). Update
On 26.01.2021 20:03, Stefano Stabellini wrote:
> From: Stefano Stabellini
>
> Add an "(EXPERT)" tag to the one-line description of Kconfig options
> that depend on EXPERT. (Not where just the prompt depends on EXPERT.)
>
> Today we only have one such option: XEN_SHSTK.
>
> Signed-off-by: Stefan
On 26.01.2021 18:59, Ian Jackson wrote:
> Manuel Bouyer writes ("Re: [PATCH] Fix error: array subscript has type
> 'char'"):
>> On Thu, Jan 14, 2021 at 03:16:15PM +0100, Manuel Bouyer wrote:
>>> On Thu, Jan 14, 2021 at 02:25:05PM +0100, Jan Beulich wrote:
Which means you're shifting the undef
On 27.01.2021 09:31, Jan Beulich wrote:
> But yes, I'm not the maintainer of this code, so if you're
> happy with such risks, so be it.
And actually I was only partly right here - there's one hunk
here affecting code I'm the maintainer just as much as you
are. At least there I'd like to ask that .
On 26.01.2021 17:21, Roger Pau Monné wrote:
> On Tue, Jan 26, 2021 at 03:52:54PM +0100, Jan Beulich wrote:
>> On 26.01.2021 12:06, Roger Pau Monne wrote:
>>> When force unbinding a MSI the used IRQ would get added to the domain
>>> irq-pirq tree as -irq -pirq,
>>
>> I think it's -pirq at index irq,
On Tue, Jan 26, 2021 at 11:42:23PM +0100, Manuel Bouyer wrote:
> On Mon, Jan 18, 2021 at 09:36:42AM +0100, Roger Pau Monné wrote:
> > [...]
> >
> > Note also that there are networking modes that don't use a bridge, so
> > you could likely end up with nics[i].bridge == NULL?
>
> I couldn't cause t
On Tue, Jan 26, 2021 at 02:55:09PM -0600, Bjorn Helgaas wrote:
> From: Bjorn Helgaas
>
> Fix misspelling of "physical".
>
> Signed-off-by: Bjorn Helgaas
Acked-by: Roger Pau Monné
Thanks, Roger.
On Tue, Jan 26, 2021 at 05:57:49PM +0100, Jan Beulich wrote:
> On 26.01.2021 14:45, Roger Pau Monne wrote:
> > When pins are cleared from either ISR or IRR as part of the
> > initialization sequence forward the clearing of those pins to the dpci
> > EOI handler, as it is equivalent to an EOI. Not d
On Tue, Jan 26, 2021 at 06:07:23PM +0100, Jan Beulich wrote:
> Ian,
>
> On 26.01.2021 14:45, Roger Pau Monne wrote:
> > The following series aims to fix some shortcomings of guest interrupt
> > handling when using passthrough devices. The first 5 patches are
> > bugfixes or cleanups, which I think
On 26.01.2021 18:31, Andrew Cooper wrote:
> On 07/01/2021 13:53, Jan Beulich wrote:
>>> + !((hpet_cfg = hpet_read32(HPET_CFG)) & HPET_CFG_LEGACY) )
>>> +{
>>> +unsigned int c0_cfg, ticks, count;
>>> +
>>> +/* Stop the main counter. */
>>> +hpet_write32(hpet_cfg &
On 27.01.2021 10:15, Roger Pau Monné wrote:
> On Tue, Jan 26, 2021 at 05:57:49PM +0100, Jan Beulich wrote:
>> On 26.01.2021 14:45, Roger Pau Monne wrote:
>>> When pins are cleared from either ISR or IRR as part of the
>>> initialization sequence forward the clearing of those pins to the dpci
>>> EO
On Tue, Jan 26, 2021 at 06:05:08PM +0100, Manuel Bouyer wrote:
> On Mon, Jan 18, 2021 at 06:54:11PM +0100, Roger Pau Monné wrote:
> > On Tue, Jan 12, 2021 at 07:12:32PM +0100, Manuel Bouyer wrote:
> > > From: Manuel Bouyer
> > >
> > > Implement gnttab interface on NetBSD.
> > > The kernel interfa
When booting a kernel which has been built with CONFIG_AMD_MEM_ENCRYPT
enabled as a Xen pv guest a warning is issued for each processor:
[5.964347] [ cut here ]
[5.968314] WARNING: CPU: 0 PID: 1 at
/home/gross/linux/head/arch/x86/xen/enlighten_pv.c:660 get_trap_add
On Tue, Jan 26, 2021 at 05:47:49PM +0100, Manuel Bouyer wrote:
> On Fri, Jan 15, 2021 at 04:27:12PM +0100, Roger Pau Monné wrote:
> > On Tue, Jan 12, 2021 at 07:12:24PM +0100, Manuel Bouyer wrote:
> > > From: Manuel Bouyer
> > >
> > > When a domain is destroyed, xparams may not be available any m
On 27/01/2021 09:38, Juergen Gross wrote:
> diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c
> index 4409306364dc..ca5ac10fcbf7 100644
> --- a/arch/x86/xen/enlighten_pv.c
> +++ b/arch/x86/xen/enlighten_pv.c
> @@ -583,6 +583,12 @@ DEFINE_IDTENTRY_RAW(xenpv_exc_debug)
>
On 26.01.2021 18:51, Elliott Mitchell wrote:
> On Tue, Jan 26, 2021 at 12:08:15PM +0100, Jan Beulich wrote:
>> On 25.01.2021 18:46, Elliott Mitchell wrote:
>>> On Mon, Jan 25, 2021 at 10:56:25AM +0100, Jan Beulich wrote:
On 24.01.2021 05:47, Elliott Mitchell wrote:
>
> ---
> Change
On Wed, Jan 27, 2021 at 10:40:43AM +0100, Roger Pau Monné wrote:
> That's weird. Linux hotplug script will unconditionally read the
> params node and we had no complaints there. Can you assert this still
> happens with the latest version of Xen?
It does with Xen 4.13 for sure.
>
> As said I thi
On Wed, Jan 27, 2021 at 10:06:43AM +0100, Roger Pau Monné wrote:
> On Tue, Jan 26, 2021 at 11:42:23PM +0100, Manuel Bouyer wrote:
> > On Mon, Jan 18, 2021 at 09:36:42AM +0100, Roger Pau Monné wrote:
> > > [...]
> > >
> > > Note also that there are networking modes that don't use a bridge, so
> > >
On 23/12/2020 20:32, Igor Druzhinin wrote:
> LBR, C-state MSRs should correspond to Ice Lake desktop according to
> External Design Specification vol.2 for both models.
>
> Ice Lake-X is known to expose IF_PSCHANGE_MC_NO in IA32_ARCH_CAPABILITIES MSR
> (confirmed on Whitley SDP) which means the err
On 26.01.21 11:15, Jan Beulich wrote:
Hi Jan
On 25.01.2021 20:08, Oleksandr Tyshchenko wrote:
--- a/xen/include/xen/dm.h
+++ b/xen/include/xen/dm.h
@@ -19,6 +19,8 @@
#include
+#include
+
struct dmop_args {
domid_t domid;
unsigned int nr_bufs;
How come this becomes n
flight 158704 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158704/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen 07edcd17fa2dce80250b3dd31e561268bc4663a9
baseline version:
xen 452d
flight 158662 qemu-mainline real [real]
flight 158703 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/158662/
http://logs.test-lab.xenproject.org/osstest/logs/158703/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be
On 26.01.21 02:14, Oleksandr wrote:
Hello, all
On 26.01.21 01:20, Julien Grall wrote:
Hi Julien, Stefano
On Mon, 25 Jan 2021 at 20:56, Stefano Stabellini
wrote:
Julien,
Hi,
This seems to be an arm randconfig failure:
https://gitlab.com/xen-project/patchew/xen/-/pipelines/246632953
h
On 27.01.2021 10:54, Oleksandr wrote:
>
> On 26.01.21 11:15, Jan Beulich wrote:
>
> Hi Jan
>
>> On 25.01.2021 20:08, Oleksandr Tyshchenko wrote:
>>> --- a/xen/include/xen/dm.h
>>> +++ b/xen/include/xen/dm.h
>>> @@ -19,6 +19,8 @@
>>>
>>> #include
>>>
>>> +#include
>>> +
>>> struct dmo
On 21.01.2021 09:50, Oleksandr wrote:
> On 20.01.21 17:50, Julien Grall wrote:
>> On 17/01/2021 18:52, Oleksandr wrote:
>>> error2.txt - when add #include to xen/ioreq.h
>>
>> It looks like the error is happening in dm.c rather than xen/dm.h. Any
>> reason to not include in dm.c directly?
> Incl
On 27.01.21 10:43, Andrew Cooper wrote:
On 27/01/2021 09:38, Juergen Gross wrote:
diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c
index 4409306364dc..ca5ac10fcbf7 100644
--- a/arch/x86/xen/enlighten_pv.c
+++ b/arch/x86/xen/enlighten_pv.c
@@ -583,6 +583,12 @@ DEFINE_IDTENTR
From: Paul Durrant
Prior to commit 4a8c31a1c6f5 ("xen/blkback: rework connect_ring() to avoid
inconsistent xenstore 'ring-page-order' set by malicious blkfront"), the
behaviour of xen-blkback when connecting to a frontend was:
- read 'ring-page-order'
- if not present then expect a single page r
While gcc doesn't warn about this because of it being static inline,
clang does, causing the build to fail there because of -Werror.
Fixes: d8099d94dfaa ("libxenguest: add get_unaligned_le32()")
Reported-by: Andrew Cooper
Signed-off-by: Jan Beulich
--- a/tools/libs/guest/xg_dom_decompress_lz4.c
On 27/01/2021 10:34, Jan Beulich wrote:
> While gcc doesn't warn about this because of it being static inline,
> clang does, causing the build to fail there because of -Werror.
>
> Fixes: d8099d94dfaa ("libxenguest: add get_unaligned_le32()")
> Reported-by: Andrew Cooper
> Signed-off-by: Jan Beuli
On 27.01.2021 11:13, Oleksandr wrote:
> On 26.01.21 02:14, Oleksandr wrote:
>> On 26.01.21 01:20, Julien Grall wrote:
>>> On Mon, 25 Jan 2021 at 20:56, Stefano Stabellini
>>> wrote:
This seems to be an arm randconfig failure:
https://gitlab.com/xen-project/patchew/xen/-/pipelines/2
On 27.01.2021 11:30, Paul Durrant wrote:
> From: Paul Durrant
>
> Prior to commit 4a8c31a1c6f5 ("xen/blkback: rework connect_ring() to avoid
> inconsistent xenstore 'ring-page-order' set by malicious blkfront"), the
> behaviour of xen-blkback when connecting to a frontend was:
>
> - read 'ring-p
flight 158702 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158702/
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 27.01.2021 11:26, Jürgen Groß wrote:
> On 27.01.21 10:43, Andrew Cooper wrote:
>> On 27/01/2021 09:38, Juergen Gross wrote:
>>> diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c
>>> index 4409306364dc..ca5ac10fcbf7 100644
>>> --- a/arch/x86/xen/enlighten_pv.c
>>> +++ b/arch/
> -Original Message-
> From: Jan Beulich
> Sent: 27 January 2021 10:57
> To: Paul Durrant
> Cc: Paul Durrant ; Konrad Rzeszutek Wilk
> ; Roger Pau
> Monné ; Jens Axboe ; Dongli Zhang
> ;
> linux-ker...@vger.kernel.org; linux-bl...@vger.kernel.org;
> xen-devel@lists.xenproject.org
> Sub
On 27.01.21 12:51, Jan Beulich wrote:
Hi Jan
On 27.01.2021 11:13, Oleksandr wrote:
On 26.01.21 02:14, Oleksandr wrote:
On 26.01.21 01:20, Julien Grall wrote:
On Mon, 25 Jan 2021 at 20:56, Stefano Stabellini
wrote:
This seems to be an arm randconfig failure:
https://gitlab.com/xen-projec
On 27.01.2021 12:09, Paul Durrant wrote:
>> -Original Message-
>> From: Jan Beulich
>> Sent: 27 January 2021 10:57
>> To: Paul Durrant
>> Cc: Paul Durrant ; Konrad Rzeszutek Wilk
>> ; Roger Pau
>> Monné ; Jens Axboe ; Dongli Zhang
>> ;
>> linux-ker...@vger.kernel.org; linux-bl...@vger.k
On 27.01.2021 12:15, Oleksandr wrote:
> On 27.01.21 12:51, Jan Beulich wrote:
>> On 27.01.2021 11:13, Oleksandr wrote:
>>> On 26.01.21 02:14, Oleksandr wrote:
On 26.01.21 01:20, Julien Grall wrote:
> On Mon, 25 Jan 2021 at 20:56, Stefano Stabellini
> wrote:
>> This seems to be an
On 27/01/2021 10:26, Jürgen Groß wrote:
> On 27.01.21 10:43, Andrew Cooper wrote:
>> On 27/01/2021 09:38, Juergen Gross wrote:
>>> diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c
>>> index 4409306364dc..ca5ac10fcbf7 100644
>>> --- a/arch/x86/xen/enlighten_pv.c
>>> +++ b/arch/
On 27.01.21 13:22, Jan Beulich wrote:
Hi Jan
On 27.01.2021 12:15, Oleksandr wrote:
On 27.01.21 12:51, Jan Beulich wrote:
On 27.01.2021 11:13, Oleksandr wrote:
On 26.01.21 02:14, Oleksandr wrote:
On 26.01.21 01:20, Julien Grall wrote:
On Mon, 25 Jan 2021 at 20:56, Stefano Stabellini
wrot
> -Original Message-
> From: Jan Beulich
> Sent: 27 January 2021 11:21
> To: p...@xen.org
> Cc: 'Paul Durrant' ; 'Konrad Rzeszutek Wilk'
> ; 'Roger Pau
> Monné' ; 'Jens Axboe' ; 'Dongli Zhang'
> ; linux-ker...@vger.kernel.org;
> linux-bl...@vger.kernel.org; xen-
> de...@lists.xenproject.
On 27/01/2021 09:28, Jan Beulich wrote:
> On 26.01.2021 18:31, Andrew Cooper wrote:
>> On 07/01/2021 13:53, Jan Beulich wrote:
+ !((hpet_cfg = hpet_read32(HPET_CFG)) & HPET_CFG_LEGACY) )
+{
+unsigned int c0_cfg, ticks, count;
+
+/* Stop the main
On 27.01.2021 12:33, Paul Durrant wrote:
>> -Original Message-
>> From: Jan Beulich
>> Sent: 27 January 2021 11:21
>> To: p...@xen.org
>> Cc: 'Paul Durrant' ; 'Konrad Rzeszutek Wilk'
>> ; 'Roger Pau
>> Monné' ; 'Jens Axboe' ; 'Dongli Zhang'
>> ; linux-ker...@vger.kernel.org;
>> linux-bl.
flight 158700 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158700/
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-armhf-libvirt
On Tue, Jan 26, 2021 at 10:22 PM Stefano Stabellini
wrote:
> On Tue, 26 Jan 2021, Jukka Kaartinen wrote:
> > On Tue, Jan 26, 2021 at 2:54 AM Stefano Stabellini <
> sstabell...@kernel.org> wrote:
> > On Sat, 23 Jan 2021, Jukka Kaartinen wrote:
> > > Thanks for the response!
> > >
On 27.01.21 12:24, Jan Beulich wrote:
Hi Jan
On 21.01.2021 09:50, Oleksandr wrote:
On 20.01.21 17:50, Julien Grall wrote:
On 17/01/2021 18:52, Oleksandr wrote:
error2.txt - when add #include to xen/ioreq.h
It looks like the error is happening in dm.c rather than xen/dm.h. Any
reason to n
Em ter., 26 de jan. de 2021 às 08:48, Jan Beulich escreveu:
>
> On 25.01.2021 20:37, Claudemir Todo Bom wrote:
> > I've managed to get the debug messages on the screen using
> > vga=text-80x50,keep and disabling all messages from the kernel. Two
> > images are attached with the output running the
On 27.01.2021 13:22, Oleksandr wrote:
> On 27.01.21 12:24, Jan Beulich wrote:
>> On 21.01.2021 09:50, Oleksandr wrote:
>>> On 20.01.21 17:50, Julien Grall wrote:
On 17/01/2021 18:52, Oleksandr wrote:
> error2.txt - when add #include to xen/ioreq.h
It looks like the error is happening
Jan Beulich writes ("Re: [PATCH] Fix error: array subscript has type 'char'"):
> I did read that part of the spec before replying.
I find this quite astonishing. You claimed that FreeBSD's libc was
buggy *after having read the spec to which you agree it conforms*.
> Irrespective of the wording
On 27.01.21 12:23, Andrew Cooper wrote:
On 27/01/2021 10:26, Jürgen Groß wrote:
On 27.01.21 10:43, Andrew Cooper wrote:
On 27/01/2021 09:38, Juergen Gross wrote:
diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c
index 4409306364dc..ca5ac10fcbf7 100644
--- a/arch/x86/xen/en
On 27/01/2021 13:59, Jürgen Groß wrote:
> On 27.01.21 12:23, Andrew Cooper wrote:
>> On 27/01/2021 10:26, Jürgen Groß wrote:
>>> On 27.01.21 10:43, Andrew Cooper wrote:
On 27/01/2021 09:38, Juergen Gross wrote:
> diff --git a/arch/x86/xen/enlighten_pv.c
> b/arch/x86/xen/enlighten_pv.c
On 27.01.2021 14:53, Ian Jackson wrote:
> Jan Beulich writes ("Re: [PATCH] Fix error: array subscript has type 'char'"):
>> On 27.01.2021 09:31, Jan Beulich wrote:
>>> But yes, I'm not the maintainer of this code, so if you're
>>> happy with such risks, so be it.
>>
>> And actually I was only partl
Hi Oleksandr,
On 25/01/2021 19:08, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
This patch adds remaining bits needed for the IOREQ support on Arm.
Besides just calling vcpu_ioreq_handle_completion() we need to handle
it's return value to make sure that all the vCPU works are done be
Recent Intel client devices have disabled the legacy PIT for powersaving
reasons, breaking compatibility with a traditional IBM PC. Xen depends on a
legacy timer interrupt to check that the IO-APIC/PIC routing is configured
correctly, and fails to boot with:
(XEN) **
On 25.01.2021 12:07, Jan Beulich wrote:
> --- a/xen/arch/x86/mm/shadow/common.c
> +++ b/xen/arch/x86/mm/shadow/common.c
> @@ -1623,6 +1623,9 @@ void shadow_hash_delete(struct domain *d
> typedef int (*hash_vcpu_callback_t)(struct vcpu *v, mfn_t smfn, mfn_t
> other_mfn);
> typedef int (*hash_doma
On 27/01/2021 10:51, Jan Beulich wrote:
On 27.01.2021 11:13, Oleksandr wrote:
On 26.01.21 02:14, Oleksandr wrote:
On 26.01.21 01:20, Julien Grall wrote:
On Mon, 25 Jan 2021 at 20:56, Stefano Stabellini
wrote:
This seems to be an arm randconfig failure:
https://gitlab.com/xen-project/patc
While only value computations of an object are disallowed in the
presence of another unsequenced side effect, at least gcc 4.3 looks to
extend this to taking the object's address. The resulting warning causes
the build to fail, because of -Werror.
While there also correct an adjacent comment.
Fix
The call to lu_read_state() would remain unresolved in this case. Frame
the construct by a suitable #ifdef, and while at it also frame command
line handling related pieces similarly.
Fixes: 9777fa6b6ea0 ("tools/xenstore: evaluate the live update flag when
starting")
Signed-off-by: Jan Beulich
-
flight 158681 linux-5.4 real [real]
flight 158706 linux-5.4 real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/158681/
http://logs.test-lab.xenproject.org/osstest/logs/158706/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
t
In commit 032a96e5ef38 tools/libxl/ was split into
tools/libs/light/ and tools/libs/guest/. Wasn't the latter
rather meant to be tools/libs/util/, as that's the other part
of what had previously resided under tools/libxl/?
Jan
Jan Beulich writes ("[PATCH] libxlutil: avoid almost-undefined behavior"):
> While only value computations of an object are disallowed in the
> presence of another unsequenced side effect, at least gcc 4.3 looks to
> extend this to taking the object's address. The resulting warning causes
> the bui
On 27.01.2021 16:29, Julien Grall wrote:
>
>
> On 27/01/2021 10:51, Jan Beulich wrote:
>> On 27.01.2021 11:13, Oleksandr wrote:
>>> On 26.01.21 02:14, Oleksandr wrote:
On 26.01.21 01:20, Julien Grall wrote:
> On Mon, 25 Jan 2021 at 20:56, Stefano Stabellini
> wrote:
>> This seem
Jan Beulich writes ("[PATCH] xenstored: fix build on libc without O_CLOEXEC"):
> The call to lu_read_state() would remain unresolved in this case. Frame
> the construct by a suitable #ifdef, and while at it also frame command
> line handling related pieces similarly.
>
> Fixes: 9777fa6b6ea0 ("tool
Jan Beulich writes ("MAINTAINERS vs libxl"):
> In commit 032a96e5ef38 tools/libxl/ was split into
> tools/libs/light/ and tools/libs/guest/. Wasn't the latter
> rather meant to be tools/libs/util/, as that's the other part
> of what had previously resided under tools/libxl/?
I think so, yes.
Ian.
> -Original Message-
> From: Jan Beulich
> Sent: Tuesday, January 26, 2021 9:22 AM
> To: Cooper, Andrew
> Cc: Lengyel, Tamas ; Roger Pau Monné
> ; Wei Liu ; Nakajima, Jun
> ; Tian, Kevin ; Michał
> Leszczyński ; Tamas K Lengyel
> ; Xen-devel
> Subject: Re: [PATCH v7 09/10] xen/vmtrace:
On 27.01.21 16:36, Jan Beulich wrote:
In commit 032a96e5ef38 tools/libxl/ was split into
tools/libs/light/ and tools/libs/guest/. Wasn't the latter
rather meant to be tools/libs/util/, as that's the other part
of what had previously resided under tools/libxl/?
Oh, indeed.
Juergen
OpenPGP
On 27.01.21 16:49, Julien Grall wrote:
Hi Oleksandr,
Hi Julien, Stefano
On 25/01/2021 19:08, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
This patch adds remaining bits needed for the IOREQ support on Arm.
Besides just calling vcpu_ioreq_handle_completion() we need to handle
Manuel Bouyer writes ("[PATCH] NetBSD hotplug: Introduce locking functions"):
> From: Manuel Bouyer
>
> On NetBSD, some block device configuration requires serialisation.
> Introcuce locking functions, and use them in the block script where
> appropriate.
Reviewed-by: Ian Jackson
Manuel Bouyer writes ("[PATCH] xenpmd.c: use dynamic allocation"):
> From: Manuel Bouyer
>
> On NetBSD, d_name is larger than 256, so file_name[284] may not be large
> enough (and gcc emits a format-truncation error).
> Use asprintf() instead of snprintf() on a static on-stack buffer.
Reviewed-b
Ian Jackson writes ("Re: [PATCH] libs/light: make it build without
setresuid()"):
> Manuel Bouyer writes ("Re: [PATCH] libs/light: make it build without
> setresuid()"):
> > On Wed, Jan 20, 2021 at 05:10:36PM +, Ian Jackson wrote:
> > > My last mail had in it a thing that claims to be a proof
The other half of the originally combined code lives in tools/libs/util/,
not tools/libs/guest/ (which was split off of libxc).
Signed-off-by: Jan Beulich
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -363,8 +363,8 @@ M: Ian Jackson
M: Wei Liu
M: Anthony PERARD
S: Supported
-F: t
Jan Beulich writes ("[PATCH] MAINTAINERS: correct split libxl paths"):
> The other half of the originally combined code lives in tools/libs/util/,
> not tools/libs/guest/ (which was split off of libxc).
Reviewed-by: Ian Jackson
When splitting libxl into libs/light and libs/util the related
MAINTAINERS entry was modified in a wrong way.
Reported-by: Jan Beulich
Fixes: 032a96e5ef38f96 ("maintainers: fix libxl paths")
Signed-off-by: Juergen Gross
---
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
Jan Beulich writes ("Re: [PATCH] Fix error: array subscript has type 'char'
[and 1 more messages]"):
> I don't think I've ever come across that part of a platform
> API/ABI spec. Instead my understanding so far was that good
> platform headers would be ignorant of the user's choice of
> char's sig
On 27.01.2021 17:21, Ian Jackson wrote:
> Jan Beulich writes ("Re: [PATCH] Fix error: array subscript has type 'char'
> [and 1 more messages]"):
>> I don't think I've ever come across that part of a platform
>> API/ABI spec. Instead my understanding so far was that good
>> platform headers would b
Hi Oleksandr,
On 25/01/2021 19:08, Oleksandr Tyshchenko wrote:
***
Patch series [8] was rebased on recent "staging branch"
(5e31789 tools/ocaml/libs/xb: Do not crash after xenbus is unmapped) and tested
on
Renesas Salvator-X board + H3 ES3.0 SoC (Arm64) with virtio-mmio disk backend
[9]
runni
On 25.01.2021 20:08, Oleksandr Tyshchenko wrote:
> Changes V4 -> V5:
>- add Julien's and Paul's R-b
>- update patch description
>- remove single use variable in arch_ioreq_server_map_mem_type_completed()
>- put multiple function parameters on a single line in the header
> where
On 27.01.21 18:43, Julien Grall wrote:
Hi Oleksandr,
Hi Julien
On 25/01/2021 19:08, Oleksandr Tyshchenko wrote:
***
Patch series [8] was rebased on recent "staging branch"
(5e31789 tools/ocaml/libs/xb: Do not crash after xenbus is unmapped)
and tested on
Renesas Salvator-X board + H3 ES
> On Jan 27, 2021, at 4:32 PM, Jan Beulich wrote:
>
> On 27.01.2021 17:21, Ian Jackson wrote:
>> Jan Beulich writes ("Re: [PATCH] Fix error: array subscript has type 'char'
>> [and 1 more messages]"):
>>> I don't think I've ever come across that part of a platform
>>> API/ABI spec. Instead my
On 25.01.2021 20:08, Oleksandr Tyshchenko wrote:
> From: Oleksandr Tyshchenko
>
> As a lot of x86 code can be re-used on Arm later on, this patch
> moves previously prepared IOREQ support to the common code
> (the code movement is verbatim copy).
>
> The "legacy" mechanism of mapping magic pages
On 27.01.2021 17:52, George Dunlap wrote:
>
>
>> On Jan 27, 2021, at 4:32 PM, Jan Beulich wrote:
>>
>> On 27.01.2021 17:21, Ian Jackson wrote:
>>> Jan Beulich writes ("Re: [PATCH] Fix error: array subscript has type 'char'
>>> [and 1 more messages]"):
I don't think I've ever come across th
George Dunlap writes ("Re: [PATCH] Fix error: array subscript has type 'char'
[and 1 more messages]"):
> > On Jan 27, 2021, at 4:32 PM, Jan Beulich wrote:
> > On 27.01.2021 17:21, Ian Jackson wrote:
> >> Are you OK with me checking in the current patch or should I ask the
> >> other committers fo
Hi Jan,
On 26/01/2021 09:15, Jan Beulich wrote:
On 25.01.2021 20:08, Oleksandr Tyshchenko wrote:
--- a/xen/include/xen/dm.h
+++ b/xen/include/xen/dm.h
@@ -19,6 +19,8 @@
#include
+#include
+
struct dmop_args {
domid_t domid;
unsigned int nr_bufs;
How come this becomes
On 27.01.2021 18:01, Julien Grall wrote:
> Hi Jan,
>
> On 26/01/2021 09:15, Jan Beulich wrote:
>> On 25.01.2021 20:08, Oleksandr Tyshchenko wrote:
>>> --- a/xen/include/xen/dm.h
>>> +++ b/xen/include/xen/dm.h
>>> @@ -19,6 +19,8 @@
>>>
>>> #include
>>>
>>> +#include
>>> +
>>> struct dmo
On 27/01/2021 16:50, Oleksandr wrote:
On 27.01.21 18:43, Julien Grall wrote:
Hi Oleksandr,
Hi Julien
On 25/01/2021 19:08, Oleksandr Tyshchenko wrote:
***
Patch series [8] was rebased on recent "staging branch"
(5e31789 tools/ocaml/libs/xb: Do not crash after xenbus is unmapped)
and
On 27.01.21 19:33, Julien Grall wrote:
Hi Julien
On 27/01/2021 16:50, Oleksandr wrote:
On 27.01.21 18:43, Julien Grall wrote:
Hi Oleksandr,
Hi Julien
On 25/01/2021 19:08, Oleksandr Tyshchenko wrote:
***
Patch series [8] was rebased on recent "staging branch"
(5e31789 tools/ocaml/
On 27/01/2021 16:17, Juergen Gross wrote:
> When splitting libxl into libs/light and libs/util the related
> MAINTAINERS entry was modified in a wrong way.
>
> Reported-by: Jan Beulich
> Fixes: 032a96e5ef38f96 ("maintainers: fix libxl paths")
> Signed-off-by: Juergen Gross
Acked-by: Andrew Coope
On 27/01/2021 17:37, Oleksandr wrote:
On 27.01.21 19:33, Julien Grall wrote:
Hi Julien
On 27/01/2021 16:50, Oleksandr wrote:
On 27.01.21 18:43, Julien Grall wrote:
Hi Oleksandr,
Hi Julien
On 25/01/2021 19:08, Oleksandr Tyshchenko wrote:
***
Patch series [8] was rebased on rece
On 27.01.21 19:42, Julien Grall wrote:
Hi
On 27/01/2021 17:37, Oleksandr wrote:
On 27.01.21 19:33, Julien Grall wrote:
Hi Julien
On 27/01/2021 16:50, Oleksandr wrote:
On 27.01.21 18:43, Julien Grall wrote:
Hi Oleksandr,
Hi Julien
On 25/01/2021 19:08, Oleksandr Tyshchenko wro
Hi,
On 25/01/2021 19:08, Oleksandr Tyshchenko wrote:
+enum io_state try_fwd_ioserv(struct cpu_user_regs *regs,
+ struct vcpu *v, mmio_info_t *info)
+{
+struct vcpu_io *vio = &v->io;
+ioreq_t p = {
+.type = IOREQ_TYPE_COPY,
+.addr = info->gpa,
+
On 25/01/2021 23:40, Oleksandr wrote:
On 26.01.21 01:13, Julien Grall wrote:
Hi,
Hi Julien
Hi Oleksandr,
On Mon, 25 Jan 2021 at 19:09, Oleksandr Tyshchenko
wrote:
***
Please note, this patch depends on the following which is
on review:
https://patchwork.kernel.org/patch/11816689/
On 27.01.21 20:33, Julien Grall wrote:
Hi Julien
Hi,
On 25/01/2021 19:08, Oleksandr Tyshchenko wrote:
+enum io_state try_fwd_ioserv(struct cpu_user_regs *regs,
+ struct vcpu *v, mmio_info_t *info)
+{
+ struct vcpu_io *vio = &v->io;
+ ioreq_t p = {
+
On Wed, Jan 27, 2021 at 03:57:06PM +, Ian Jackson wrote:
> Manuel Bouyer writes ("[PATCH] NetBSD hotplug: Introduce locking functions"):
> > From: Manuel Bouyer
> >
> > On NetBSD, some block device configuration requires serialisation.
> > Introcuce locking functions, and use them in the bloc
1 - 100 of 167 matches
Mail list logo
