On 14.01.2021 16:01, Andrew Cooper wrote:
> On 14/01/2021 14:02, Jan Beulich wrote:
>> --- a/xen/common/page_alloc.c
>> +++ b/xen/common/page_alloc.c
>> @@ -2566,13 +2566,7 @@ __initcall(register_heap_trigger);
>>
>> struct domain *get_pg_owner(domid_t domid)
>> {
>> -struct domain *pg_owne
On 15/01/2021 09:57, Jan Beulich wrote:
> On 14.01.2021 20:02, Andrew Cooper wrote:
>> Bugs:
>>
>> 1) HPET/PIT issue on newer Intel systems. This has had literally tens
>> of reports across the devel and users mailing lists, and prevents Xen
>> from booting at all on the past two generations of In
On 24.11.2020 00:01, Michael Young wrote:
> On Tue, 17 Nov 2020, Andrew Cooper wrote:
>
>> If you're willing to have a go:
>>
>> For dom0 support, port Linux's decompressor into xen/common/ and plumb
>> it into xen/common/decompress.c
>>
>> For domU's, tools/libs/guest/xg_dom_bzimageloader.c and
>
On 15/01/2021 10:52, Andrew Cooper wrote:
> On 15/01/2021 09:57, Jan Beulich wrote:
>> On 14.01.2021 20:02, Andrew Cooper wrote:
>>> Bugs:
>>>
>>> 1) HPET/PIT issue on newer Intel systems. This has had literally tens
>>> of reports across the devel and users mailing lists, and prevents Xen
>>> fro
On 14.01.2021 20:19, Julien Grall wrote:
>
>
> On 23/12/2020 14:01, Julien Grall wrote:
>> Hi Jan,
>>
>> On 23/12/2020 13:48, Jan Beulich wrote:
>>> On 22.12.2020 16:43, Julien Grall wrote:
From: Julien Grall
The pgtables.lock is protecting access to the page list pgtables.list.
>
On 15.01.2021 11:59, Andrew Cooper wrote:
> On 15/01/2021 10:52, Andrew Cooper wrote:
>> 4) zstd support to unbreak Fedora. (I'm deliberately putting this in
>> the bugs rather than feature cateogry).
>
> Ha! I should have read further through my emails before replying.
What I've sent doesn't c
On 15/01/2021 10:05, Jan Beulich wrote:
> Rather than open-coding commonly used constructs in yet more places when
> pulling in zstd decompression support (and its xxhash prereq), pull out
> the custom bits into a commonly used header (for the hypervisor build;
> the tool stack and stubdom builds o
On 15/01/2021 10:06, Jan Beulich wrote:
> Taken from Linux at commit d89775fc929c ("lib/: replace HTTP links with
> HTTPS ones"), but split into separate 32-bit and 64-bit sources, since
> the immediate consumer (zstd) will need only the latter.
>
> Note that the building of this code is restricted
On Thu, 14 Jan 2021, Lee Jones wrote:
> On Thu, 14 Jan 2021, Jakub Kicinski wrote:
>
> > On Thu, 14 Jan 2021 08:33:49 + Lee Jones wrote:
> > > On Wed, 13 Jan 2021, Jakub Kicinski wrote:
> > >
> > > > On Wed, 13 Jan 2021 16:41:16 + Lee Jones wrote:
> > > > > Resending the stragglers aga
On 15/01/2021 10:06, Jan Beulich wrote:
> Taken from Linux at commit 1c4dd334df3a ("lib: decompress_unzstd: Limit
> output size") for unzstd.c (renamed from decompress_unzstd.c) and
> 36f9ff9e03de ("lib: Fix fall-through warnings for Clang") for zstd/,
> with bits from linux/zstd.h merged into suit
On 14.01.2021 19:53, Julien Grall wrote:
> On 23/12/2020 16:35, Jan Beulich wrote:
>> On 23.12.2020 17:19, Julien Grall wrote:
>>> On 23/12/2020 16:15, Jan Beulich wrote:
On 23.12.2020 17:07, Julien Grall wrote:
> I think I prefer the small race introduced (the pages will still be
> fr
On 15.01.2021 12:13, Andrew Cooper wrote:
> On 15/01/2021 10:05, Jan Beulich wrote:
>> Rather than open-coding commonly used constructs in yet more places when
>> pulling in zstd decompression support (and its xxhash prereq), pull out
>> the custom bits into a commonly used header (for the hypervis
On 15.01.2021 12:13, Andrew Cooper wrote:
> On 15/01/2021 10:05, Jan Beulich wrote:
>> Rather than open-coding commonly used constructs in yet more places when
>> pulling in zstd decompression support (and its xxhash prereq), pull out
>> the custom bits into a commonly used header (for the hypervis
Hi Jan,
On 15/01/2021 11:24, Jan Beulich wrote:
On 14.01.2021 19:53, Julien Grall wrote:
On 23/12/2020 16:35, Jan Beulich wrote:
On 23.12.2020 17:19, Julien Grall wrote:
On 23/12/2020 16:15, Jan Beulich wrote:
On 23.12.2020 17:07, Julien Grall wrote:
I think I prefer the small race introduc
Hi Volodymyr, Stefano,
On 14/01/2021 23:33, Stefano Stabellini wrote:
+ Bertrand, Andrew (see comment on alloc_heap_pages())
Long running hypercalls are usually considered security issues.
In this case, only the control domain can issue large memory allocation
(2GB at a time). Guest, would o
On 12.01.2021 20:48, Andrew Cooper wrote:
> The existing logic doesn't function in the general case for mapping a guests
> grant table, due to arbitrary 32 frame limit, and the default grant table
> limit being 64.
>
> In order to start addressing this, rework the existing grant table logic by
> i
Hi Rahul,
On 08/01/2021 14:46, Rahul Singh wrote:
Based on tag Linux 5.8.18 commit ab435ce49bd1d02e33dfec24f76955dc1196970b
Directory structure change for the SMMUv3 driver starting from
Linux 5.9, to revert the patches smoothly using the "git revert" command
we decided to choose Linux 5.8.18.
On 12.01.2021 20:48, Andrew Cooper wrote:
> The existing logic doesn't function in the general case for mapping a guests
> grant table, due to arbitrary 32 frame limit, and the default grant table
> limit being 64.
>
> In order to start addressing this, rework the existing grant table logic by
> i
Hello,
> On 14 Jan 2021, at 11:47 pm, Stefano Stabellini
> wrote:
>
> On Thu, 14 Jan 2021, Jan Beulich wrote:
>> On 13.01.2021 00:30, Stefano Stabellini wrote:
>>> On Tue, 12 Jan 2021, Jan Beulich wrote:
On 08.01.2021 15:46, Rahul Singh wrote:
> -Wimplicit-fallthrough warns when a swit
Hi Rahul,
On 08/01/2021 14:46, Rahul Singh wrote:
Implement the ffsll based on built-in function "__builtin_ffsll()"
ffsll will return one plus the index of the least significant 1-bit in
doublewords or if doublewords is zero, returns zero.
Signed-off-by: Rahul Singh
---
Changes in V4:
- Th
Hi Rahul,
On 08/01/2021 14:46, Rahul Singh wrote:
Merge the patch from linux to use fallthrough pseudo-keyword.
Please add more information about the patch you are backporting. Is it a
clean backport?
Replace the existing /* fall through */ comments and its variants with
the new pseudo-ke
From: Jiri Slaby
commit 78762b0e79bc1dd01347be061abdf505202152c9 upstream.
All these are functions which are invoked from elsewhere but they are
not typical C functions. So annotate them using the new SYM_CODE_START.
All these were not balanced with any END, so mark their ends by
SYM_CODE_END, a
Hi Rahul,
On 08/01/2021 14:46, Rahul Singh wrote:
Add support for ARM architected SMMUv3 implementation. It is based on
the Linux SMMUv3 driver.
Driver is currently supported as Tech Preview.
Major differences with regard to Linux driver are as follows:
2. Only Stage-2 translation is supported
Hello Oleksandr,
> On 12 Jan 2021, at 8:59 pm, Oleksandr wrote:
>
>
> On 12.01.21 11:41, Rahul Singh wrote:
>
> Hi Rahul
>
>
>>
-static int arm_smmu_of_xlate(struct device *dev, struct of_phandle_args
*args)
+static int arm_smmu_dt_xlate(struct device *dev,
+
On 15/01/2021 12:38, Rahul Singh wrote:
Hello Oleksandr,
On 12 Jan 2021, at 8:59 pm, Oleksandr wrote:
On 12.01.21 11:41, Rahul Singh wrote:
Hi Rahul
-static int arm_smmu_of_xlate(struct device *dev, struct of_phandle_args
*args)
+static int arm_smmu_dt_xlate(struct device *dev,
+
On 15.01.2021 13:14, Rahul Singh wrote:
> Hello,
>
>> On 14 Jan 2021, at 11:47 pm, Stefano Stabellini
>> wrote:
>>
>> On Thu, 14 Jan 2021, Jan Beulich wrote:
>>> On 13.01.2021 00:30, Stefano Stabellini wrote:
On Tue, 12 Jan 2021, Jan Beulich wrote:
> On 08.01.2021 15:46, Rahul Singh wro
On 14/01/2021 15:23, Jan Beulich wrote:
> It's at least odd to check counters which aren't going to be
> incremented. And it's also not helpful to use open-coded literal numbers
> in these checks.
>
> Calculate the increment values first and derive from them the mask to
> use in the checks.
>
> Als
On Thu, Jan 14, 2021 at 12:54:22PM +0100, Jan Beulich wrote:
> On 12.01.2021 18:32, Roger Pau Monne wrote:
> > @@ -967,10 +879,10 @@ static void hvm_pirq_eoi(struct pirq *pirq)
> > * since interrupt is still not EOIed
> > */
> > if ( --pirq_dpci->pending ||
> > - !pt_irq_ne
On 14/01/2021 15:23, Jan Beulich wrote:
> Forever since the fix for XSA-230 the 2nd of the comments ahead of
> fixup_status_for_copy_pin() has been stale - there's nothing specific to
> transitive grants there anymore.
>
> Move the function up, drop the "copy" part from its name again, add a
> "rea
On 15.01.2021 14:09, Andrew Cooper wrote:
> On 14/01/2021 15:23, Jan Beulich wrote:
>> --- a/xen/common/grant_table.c
>> +++ b/xen/common/grant_table.c
>> @@ -323,22 +323,25 @@ shared_entry_header(struct grant_table *
>> /* Active grant entry - used for shadowing GTF_permit_access grants. */
>> s
On 15.01.2021 14:25, Andrew Cooper wrote:
> On 14/01/2021 15:23, Jan Beulich wrote:
>> --- a/xen/common/grant_table.c
>> +++ b/xen/common/grant_table.c
>> @@ -908,6 +908,25 @@ static int _set_status(const grant_entry
>> return _set_status_v2(shah, status, rd, act, readonly, mapflag,
>> ld
On 15/01/2021 13:26, Jan Beulich wrote:
> On 15.01.2021 14:09, Andrew Cooper wrote:
>> On 14/01/2021 15:23, Jan Beulich wrote:
>>> @@ -1052,19 +1063,19 @@ map_grant_ref(
>>> shah = shared_entry_header(rgt, ref);
>>> act = active_entry_acquire(rgt, ref);
>>>
>>> -/* Make sure we do n
On 15/01/2021 13:33, Jan Beulich wrote:
> On 15.01.2021 14:25, Andrew Cooper wrote:
>> On 14/01/2021 15:23, Jan Beulich wrote:
>>> --- a/xen/common/grant_table.c
>>> +++ b/xen/common/grant_table.c
>>> @@ -908,6 +908,25 @@ static int _set_status(const grant_entry
>>> return _set_status_v2(s
On Fri, 15 Jan 2021, Christophe Leroy wrote:
>
>
> Le 15/01/2021 à 12:18, Lee Jones a écrit :
> > On Thu, 14 Jan 2021, Lee Jones wrote:
> >
> > > On Thu, 14 Jan 2021, Jakub Kicinski wrote:
> > >
> > > > On Thu, 14 Jan 2021 08:33:49 + Lee Jones wrote:
> > > > > On Wed, 13 Jan 2021, Jakub Ki
On Thu, Jan 14, 2021 at 5:22 AM Roger Pau Monné wrote:
>
> On Wed, Jan 13, 2021 at 04:31:33PM -0500, Jason Andryuk wrote:
> > On Wed, Jan 13, 2021 at 1:34 PM Jason Andryuk wrote:
> > >
> > > On Wed, Jan 13, 2021 at 1:06 PM Roger Pau Monné
> > > wrote:
> > > >
> > > > On Wed, Jan 13, 2021 at 10:
flight 158427 qemu-mainline real [real]
flight 158435 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/158427/
http://logs.test-lab.xenproject.org/osstest/logs/158435/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be
Le 15/01/2021 à 12:18, Lee Jones a écrit :
On Thu, 14 Jan 2021, Lee Jones wrote:
On Thu, 14 Jan 2021, Jakub Kicinski wrote:
On Thu, 14 Jan 2021 08:33:49 + Lee Jones wrote:
On Wed, 13 Jan 2021, Jakub Kicinski wrote:
On Wed, 13 Jan 2021 16:41:16 + Lee Jones wrote:
Resending the s
On 15.01.2021 14:35, Andrew Cooper wrote:
> On 15/01/2021 13:26, Jan Beulich wrote:
>> On 15.01.2021 14:09, Andrew Cooper wrote:
>>> On 14/01/2021 15:23, Jan Beulich wrote:
@@ -1052,19 +1063,19 @@ map_grant_ref(
shah = shared_entry_header(rgt, ref);
act = active_entry_acqui
On 15/01/2021 14:21, Jan Beulich wrote:
> On 15.01.2021 14:35, Andrew Cooper wrote:
>> On 15/01/2021 13:26, Jan Beulich wrote:
>>> On 15.01.2021 14:09, Andrew Cooper wrote:
On 14/01/2021 15:23, Jan Beulich wrote:
> @@ -1052,19 +1063,19 @@ map_grant_ref(
> shah = shared_entry_heade
Hello,
The following series aims to fix some shortcomings of guest interrupt
handling when using passthrough devices. The first 3 patches are
bugfixes, which I think should solve the issue(s) that caused the dpci
EOI timer to be introduced. However neither me nor others seem to be able
to reproduc
In vioapic_update_EOI the irq_lock will be dropped in order to forward
the EOI to the dpci handler, so there's a window between clearing IRR
and checking if the line is asserted where IRR can change behind our
back.
Fix this by checking whether IRR is set before attempting to inject a
new interrup
When an IO-APIC pin is switched from level to edge trigger mode the
IRR bit is cleared, so it can be used as a way to EOI an interrupt at
the IO-APIC level.
Such EOI however does not get forwarded to the dpci code like it's
done for the local APIC initiated EOI. This change adds the code in
order
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 doing so can bring the
interrupt controller state out of sync with the dpci handling logic,
that expects a notification
Current interrupt pass though code will setup a timer for each
interrupt injected to the guest that requires an EOI from the guest.
Such timer would perform two actions if the guest doesn't EOI the
interrupt before a given period of time. The first one is deasserting
the virtual line, the second is
This patch is a result of a downstream bug report[1]. Xen fails to
create a HVM domain while running under VMware Fusion 12.1.0 on
a modern Intel Core i9 CPU:
(XEN) VMX: CPU0 has insufficient CPU-Based Exec Control (b5b9fffe; requires
2299968c)
(XEN) VMX: failed to initialise.
It seems that Appl
Linus,
Please git pull the following tag:
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
for-linus-5.11-rc4-tag
xen: branch for v5.11-rc4
It contains:
- A series for fixing a regression when running as a fully virtualized
guest on an old Xen hypervisor not supporting PV interrup
Linus,
Please git pull the following tag:
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
for-linus-5.11-rc4-tag
xen: branch for v5.11-rc4
It contains:
- A series for fixing a regression when running as a fully virtualized
guest on an old Xen hypervisor not supporting PV interrup
Oleksandr writes:
> On 14.01.21 05:58, Wei Chen wrote:
>> Hi Oleksandr,
>
> Hi Wei
>>> @@ -1090,6 +1091,40 @@ static int acquire_grant_table(struct domain *d,
>>> unsigned int id,
>>> return 0;
>>> }
>>>
>>> +static int acquire_ioreq_server(struct domain *d,
>>> +
On Fri, Jan 15, 2021 at 03:30:50PM +0100, Hubert Jasudowicz wrote:
> This patch is a result of a downstream bug report[1]. Xen fails to
> create a HVM domain while running under VMware Fusion 12.1.0 on
> a modern Intel Core i9 CPU:
>
> (XEN) VMX: CPU0 has insufficient CPU-Based Exec Control (b5b9f
On 15/01/2021 14:30, Hubert Jasudowicz wrote:
> This patch is a result of a downstream bug report[1]. Xen fails to
> create a HVM domain while running under VMware Fusion 12.1.0 on
> a modern Intel Core i9 CPU:
>
> (XEN) VMX: CPU0 has insufficient CPU-Based Exec Control (b5b9fffe; requires
> 22999
Oleksandr Tyshchenko writes:
> From: Oleksandr Tyshchenko
>
> The IOREQ is about to be common feature and Arm will have its own
> implementation.
>
> But the name of the function is pretty generic and can be confusing
> on Arm (we already have a try_handle_mmio()).
>
> In order not to rename t
flight 158434 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158434/
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, Jan 15, 2021 at 03:28:20PM +0100, Roger Pau Monne wrote:
> Current interrupt pass though code will setup a timer for each
> interrupt injected to the guest that requires an EOI from the guest.
> Such timer would perform two actions if the guest doesn't EOI the
> interrupt before a given per
Oleksandr Tyshchenko writes:
> 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 for the IOREQ ser
This is a revert of f5cfa0985673 plus a rework of the comment that
accompanies the setting of the flag so we don't forget why it needs to
be unconditionally set: it's indicating whether the version of Xen has
the original issue fixed and IOMMU entries are created for
grant/foreign maps.
Signed-off
Hi list,
Another "popular" thread on XCP-ng forum [1], started in october 2020,
allowed us to detect that patch 12 from the XSA-332 advisory [2] had a
very significant impact on network performance in the case of pfSense VMs.
We reproduced the issue internally (well, we reproduced "something". T
On Tue, Jan 12, 2021 at 07:12:22PM +0100, Manuel Bouyer wrote:
> From: Manuel Bouyer
>
> On NetBSD the lock directory is in /var/run/
>
> Signed-off-by: Manuel Bouyer
Reviewed-by: Roger Pau Monné
Thanks, Roger.
On Fri, Jan 15, 2021 at 04:09:19PM +0100, Roger Pau Monné wrote:
> On Tue, Jan 12, 2021 at 07:12:22PM +0100, Manuel Bouyer wrote:
> > From: Manuel Bouyer
> >
> > On NetBSD the lock directory is in /var/run/
> >
> > Signed-off-by: Manuel Bouyer
>
> Reviewed-by: Roger Pau Monné
thanks
I alread
Getting rid of the literal number has been something I've been
hoping to see happen for perhaps over 10 years, along with
doing away with some unnecessary refusal of operations. The
other patch is "collateral damage" from doing that change.
1: gnttab: adjust pin count overflow checks
2: gnttab: co
It's at least odd to check counters which aren't going to be
incremented, resulting in failure just because prior operations may
have left an entry in an unusual state. And it's also not helpful to
use open-coded literal numbers in these checks.
Calculate the increment values first and derive from
> Features:
>
> 1) acquire_resource fixes.
>
> Not really a new feature - entirely bugfixing a preexisting one.
> Developed by me to help 2). Reasonably well acked, but awaiting feedback
> on v3.
>
> 2) External Processor Trace support.
>
> Development by Michał. Depends on 1), and awaiting a
Forever since the fix for XSA-230 the 2nd of the comments ahead of
fixup_status_for_copy_pin() has been stale - there's nothing specific to
transitive grants there anymore.
Move the function up, drop the "copy" part from its name again, add a
"readonly" parameter, and use it also on other paths ha
Hi Oleksandr,
On 12/01/2021 21:52, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
As a lot of x86 code can be re-used on Arm later on, this
patch makes some preparation to x86/hvm/ioreq.c before moving
to the common code. This way we will get a verbatim copy
for a code movement in subs
It's not overly difficult for a domain to figure out its ID, so
requiring the use of DOMID_SELF in a very limited set of places isn't
really helpful towards keeping the ID opaque to the guest.
Signed-off-by: Jan Beulich
---
v2: Comment on this version specific behavior in the respective public
Hi Oleksandr,
On 12/01/2021 21:52, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
This patch continues to make some preparation to x86/hvm/ioreq.c
before moving to the common code.
Add IOREQ_STATUS_* #define-s and update candidates for moving
since X86EMUL_* shouldn't be exposed to th
> -Original Message-
> From: Jan Beulich
> Sent: 15 January 2021 11:07
> To: Julien Grall ; Paul Durrant
> Cc: hongy...@amazon.co.uk; Julien Grall ;
> xen-devel@lists.xenproject.org; Andrew
> Cooper
> Subject: Re: [PATCH for-4.15 2/4] xen/iommu: x86: Free the IOMMU page-tables
> with t
On 15.01.2021 16:01, Roger Pau Monne wrote:
> This is a revert of f5cfa0985673 plus a rework of the comment that
> accompanies the setting of the flag so we don't forget why it needs to
> be unconditionally set: it's indicating whether the version of Xen has
> the original issue fixed and IOMMU ent
Hi Oleksandr,
On 12/01/2021 21:52, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
The IOREQ is about to be common feature and Arm will have its own
implementation.
But the name of the function is pretty generic and can be confusing
on Arm (we already have a try_handle_mmio()).
In ord
Hi Oleksandr,
On 12/01/2021 21:52, 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 pa
flight 158432 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158432/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-xl-arndale 8 xen-boot fail in 158424 pass in 158432
test-amd64-amd64-xl-qemuu-win7-a
Hi Oleksandr,
On 12/01/2021 21:52, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
The IOREQ is a common feature now and this helper will be used
on Arm as is. Move it to xen/ioreq.h and remove "hvm" prefix.
Although PIO handling on Arm is not introduced with the current series
(it wil
Hi Stefano,
Stefano Stabellini writes:
[...]
>>
>> ARMv8 platform. Namely Renesas Rcar H3 SoC on Salvator board.
>>
>> To accurately determine latency, I employed one of timer counter units
>> (TMUs) available on the SoC. This is 32-bit timer with auto-reload,
>> that can generate interrupt
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 more when
> the block script is called to unconfigure the vnd.
> Check xparam only at configure time, and just unconfigure any vnd present
> in the
On 15/01/2021 15:13, Manuel Bouyer wrote:
> On Fri, Jan 15, 2021 at 04:09:19PM +0100, Roger Pau Monné wrote:
>> On Tue, Jan 12, 2021 at 07:12:22PM +0100, Manuel Bouyer wrote:
>>> From: Manuel Bouyer
>>>
>>> On NetBSD the lock directory is in /var/run/
>>>
>>> Signed-off-by: Manuel Bouyer
>> Revie
On Tue, Jan 12, 2021 at 07:12:26PM +0100, Manuel Bouyer wrote:
> From: Manuel Bouyer
>
> NetBSD doens't need xenbackendd with xl toolstack so don't build it.
> Remove now unused xenbackendd directory/files.
>
> Signed-off-by: Manuel Bouyer
Reviewed-by: Roger Pau Monné
Thanks, Roger.
Hi Oleksandr,
On 12/01/2021 21:52, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
The IOREQ is a common feature now and these helpers will be used
on Arm as is. Move them to xen/ioreq.h and replace "hvm" prefixes
with "ioreq".
Signed-off-by: Oleksandr Tyshchenko
Reviewed-by: Paul Dur
Hi Oleksandr,
On 12/01/2021 21:52, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
The IOREQ is a common feature now and these structs will be used
on Arm as is. Move them to xen/ioreq.h and remove "hvm" prefixes.
Signed-off-by: Oleksandr Tyshchenko
Acked-by: Jan Beulich
CC: Julien G
On 12.01.2021 20:48, Andrew Cooper wrote:
> @@ -446,6 +430,31 @@ int compat_memory_op(unsigned int cmd,
> XEN_GUEST_HANDLE_PARAM(void) compat)
>
> #undef XLAT_mem_acquire_resource_HNDL_frame_list
>
> +if ( xen_frame_list && cmp.mar.nr_frames )
> +{
> +/
On 15/01/2021 15:14, Jan Beulich wrote:
> It's at least odd to check counters which aren't going to be
> incremented, resulting in failure just because prior operations may
> have left an entry in an unusual state.
I wouldn't say it's an unusual state. It can happen legally when you
map the same
Hi Oleksandr,
On 12/01/2021 21:52, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
The IOREQ is a common feature now and this struct will be used
on Arm as is. Move it to common struct domain. This also
significantly reduces the layering violation in the common code
(*arch.hvm* usage).
Hi Julien,
Julien Grall writes:
> Hi Volodymyr, Stefano,
>
> On 14/01/2021 23:33, Stefano Stabellini wrote:
>> + Bertrand, Andrew (see comment on alloc_heap_pages())
>
> Long running hypercalls are usually considered security issues.
>
> In this case, only the control domain can issue large mem
On Tue, Jan 12, 2021 at 07:12:27PM +0100, Manuel Bouyer wrote:
> From: Manuel Bouyer
>
> On NetBSD use the system-provided headers for ioctl and related definitions,
> they are up to date and have more chances to match the kernel's idea of
> the ioctls and structures.
> Remove now-unused NetBSD/e
On 15/01/2021 11:43, Jan Beulich wrote:
>> --- a/xen/common/grant_table.c
>> +++ b/xen/common/grant_table.c
>> @@ -4013,6 +4013,59 @@ static int gnttab_get_shared_frame_mfn(struct domain
>> *d,
>> return 0;
>> }
>>
>> +int gnttab_acquire_resource(
>> +struct domain *d, unsigned int id,
On Tue, Jan 12, 2021 at 07:12:25PM +0100, Manuel Bouyer wrote:
> From: Manuel Bouyer
>
> Some Xen version didn't set the vifname in xenstore; just build one if
> not present.
I think the current version (what's going to become 4.15) should write
the vifname in all cases? If not that's likely an
On Tue, Jan 12, 2021 at 07:12:40PM +0100, Manuel Bouyer wrote:
> From: Manuel Bouyer
>
> writable definition of errno on NetBSD.
>
> Signed-off-by: Manuel Bouyer
Reviewed-by: Roger Pau Monné
Thanks, Roger.
On 12.01.2021 20:48, Andrew Cooper wrote:
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -4628,7 +4628,6 @@ int arch_acquire_resource(struct domain *d, unsigned
> int type,
> if ( id != (unsigned int)ioservid )
> break;
>
> -rc = 0;
> for ( i = 0;
On 15.01.2021 16:38, Andrew Cooper wrote:
> On 15/01/2021 15:14, Jan Beulich wrote:
>> It's at least odd to check counters which aren't going to be
>> incremented, resulting in failure just because prior operations may
>> have left an entry in an unusual state.
>
> I wouldn't say it's an unusual s
On 15.01.2021 17:03, Andrew Cooper wrote:
> On 15/01/2021 11:43, Jan Beulich wrote:
>>> +mfn_t tmp;
>>> +void **vaddrs;
>>> +int rc;
>>> +
>>> +/* Overflow checks */
>>> +if ( frame + nr_frames < frame )
>>> +return -EINVAL;
>>> +
>>> +tot_frames = frame + nr_frames;
On 15.01.2021 17:26, Jan Beulich wrote:
> On 15.01.2021 17:03, Andrew Cooper wrote:
>> On 15/01/2021 11:43, Jan Beulich wrote:
+mfn_t tmp;
+void **vaddrs;
+int rc;
+
+/* Overflow checks */
+if ( frame + nr_frames < frame )
+return -EINV
On 12.01.2021 22:52, Oleksandr Tyshchenko wrote:
> @@ -1080,6 +1104,27 @@ int hvm_unmap_io_range_from_ioreq_server(struct domain
> *d, ioservid_t id,
> return rc;
> }
>
> +/* Called with ioreq_server lock held */
> +int arch_ioreq_server_map_mem_type(struct domain *d,
> +
On Fri, 15 Jan 2021 13:38:48 + Lee Jones wrote:
> Okay, so what would you like me to do? Would you like me to re-submit
> the set based only on net-next
Yes, rebase your patches on net-next, recheck everything builds okay
and resubmit. You should always develop against the tree that will
merg
On 15/01/2021 11:56, Jan Beulich wrote:
>> +/* Grow table if necessary. */
>> +grant_write_lock(gt);
>> +rc = -EINVAL;
>> +switch ( id )
>> +{
>> +case XENMEM_resource_grant_table_id_shared:
>> +vaddrs = gt->shared_raw;
>> +rc = gnttab_get_shared_frame_mfn(d,
On 15/01/2021 15:45, Volodymyr Babchuk wrote:
Hi Julien,
Julien Grall writes:
Hi Volodymyr, Stefano,
On 14/01/2021 23:33, Stefano Stabellini wrote:
+ Bertrand, Andrew (see comment on alloc_heap_pages())
Long running hypercalls are usually considered security issues.
In this case, only
On Tue, Jan 12, 2021 at 07:12:35PM +0100, Manuel Bouyer wrote:
> From: Manuel Bouyer
>
> NetBSD uses the same uuid library as FreeBSD. As this is in a
> __FreeBSD__ || __NetBSD__ block, just drop the #ifdef __FreeBSD__
> and dead code.
>
> Signed-off-by: Manuel Bouyer
Reviewed-by: Roger Pau Mo
flight 158438 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158438/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 158434
build-armhf
On 13/01/2021 18:02, Marek Marczykowski-Górecki wrote:
> On Wed, Jan 13, 2021 at 03:45:10PM +, Andrew Cooper wrote:
>> On 12/01/2021 17:35, Ian Jackson wrote:
>>> * When appropriately configured, the xen.git build system
>>>will ship them into dist/install/usr/local/
>>>
>>> * There w
On Fri, 15 Jan 2021, Jan Beulich wrote:
> On 15.01.2021 13:14, Rahul Singh wrote:
> > Hello,
> >
> >> On 14 Jan 2021, at 11:47 pm, Stefano Stabellini
> >> wrote:
> >>
> >> On Thu, 14 Jan 2021, Jan Beulich wrote:
> >>> On 13.01.2021 00:30, Stefano Stabellini wrote:
> On Tue, 12 Jan 2021, Jan
flight 158433 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158433/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemuu-rhel6hvm-intel 7 xen-install fail REGR. vs. 152332
test-amd64-i386-qem
The pull request you sent on Fri, 15 Jan 2021 15:31:53 +0100:
> git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
> for-linus-5.11-rc4-tag
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/dcda487c9c2e80ad177cdc34ae2068bbe5dada07
Thank you!
--
Deet-doot-dot, I
flight 158440 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158440/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 158434
build-armhf
1 - 100 of 188 matches
Mail list logo
