> -Original Message-
> From: Bertrand Marquis
> Sent: 10 September 2020 17:46
> To: Paul Durrant
> Cc: open list:X86 ; Durrant, Paul
> ; Jan Beulich
> ; Andrew Cooper ; Wei Liu
> ; Roger Pau Monné
> ; George Dunlap ; Ian Jackson
> ; Julien Grall ; Stefa
> -Original Message-
> From: Paul Durrant
> Sent: 04 September 2020 18:30
> To: 'Jan Beulich'
> Cc: xen-devel@lists.xenproject.org; Durrant, Paul ;
> 'Ian Jackson'
> ; 'Wei Liu' ; 'Andrew Cooper'
> ;
> 'George Dunlap' ; 'Julien Grall' ;
> 'Stefan
> -Original Message-
> From: Roger Pau Monné
> Sent: 15 September 2020 15:32
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; Durrant, Paul ;
> Ian Jackson
> ; Wei Liu ; Anthony PERARD
>
> Subject: RE: [EXTERNAL] [PATCH v2 1/2] libxl: provide a mech
> -Original Message-
> From: Jan Beulich
> Sent: 02 October 2020 09:48
> To: Roger Pau Monne ; Wei Liu ; Paul
> Durrant
> Cc: xen-devel@lists.xenproject.org; Andrew Cooper
> ; Durrant, Paul
>
> Subject: RE: [EXTERNAL] [PATCH v2 01/11] x86/hvm: drop vcpu p
> -Original Message-
> From: Andrew Cooper
> Sent: 02 October 2020 23:40
> To: Paul Durrant ; xen-devel@lists.xenproject.org
> Cc: Durrant, Paul ; Ian Jackson
> ; Wei Liu
>
> Subject: RE: [EXTERNAL] [PATCH v9 3/8] tools/misc: add xen-domctx to present
>
> -Original Message-
> From: Andrew Cooper
> Sent: 02 October 2020 23:42
> To: Paul Durrant ; xen-devel@lists.xenproject.org
> Cc: Durrant, Paul ; George Dunlap
> ; Ian Jackson
> ; Jan Beulich ; Julien Grall
> ; Stefano
> Stabellini ; Wei Liu
> Subject
> -Original Message-
> From: Andrew Cooper
> Sent: 02 October 2020 22:58
> To: Paul Durrant ; xen-devel@lists.xenproject.org
> Cc: Durrant, Paul ; Julien Grall ;
> Daniel De Graaf
> ; Ian Jackson ; Wei Liu
> ; George Dunlap
> ; Jan Beulich ; Stefano
&g
> -Original Message-
> From: Andrew Cooper
> Sent: 05 October 2020 15:30
> To: Paul Durrant ; xen-devel@lists.xenproject.org
> Cc: Durrant, Paul ; Julien Grall ; Jan
> Beulich
> ; Roger Pau Monné ; Wei Liu
>
> Subject: RE: [EXTERNAL] [PATCH] ioreq: cope wit
> -Original Message-
> From: Julien Grall
> Sent: 05 October 2020 15:42
> To: Paul Durrant ; xen-devel@lists.xenproject.org
> Cc: Durrant, Paul ; Jan Beulich ;
> Andrew Cooper
> ; Roger Pau Monné ; Wei Liu
>
> Subject: RE: [EXTERNAL] [PATCH] ioreq: cope wit
> -Original Message-
> From: George Dunlap
> Sent: 28 August 2020 11:48
> To: Tamas K Lengyel ; intel-...@intel.com;
> daniel.ki...@oracle.com; Roger
> Pau Monne ; Sergey Dyasli ;
> Christopher Clark
> ; Rich Persaud ; Kevin
> Pearson
> ; Juergen Gross ;
> -Original Message-
> From: Wei Liu
> Sent: 27 August 2020 10:58
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; Durrant, Paul ;
> Andrew Cooper
> ; Anthony PERARD ;
> George Dunlap
> ; Ian Jackson ; Jan
> Beulich ;
> Julien Grall ; Stefano S
> -Original Message-
> From: Tamas K Lengyel
> Sent: 29 September 2020 13:06
> To: Durrant, Paul
> Cc: Lengyel, Tamas ; p...@xen.org;
> xen-devel@lists.xenproject.org; Andrew
> Cooper ; Daniel De Graaf ;
> George Dunlap
> ; Ian Jackson ; Jan
> Be
> -Original Message-
> From: Lengyel, Tamas
> Sent: 28 September 2020 15:17
> To: p...@xen.org; xen-devel@lists.xenproject.org
> Cc: Durrant, Paul ; 'Andrew Cooper'
> ; 'Daniel De
> Graaf' ; 'George Dunlap' ;
> 'Ian Jackson'
> ; 'Jan Beulich' ; 'Julien
>
> -Original Message-
> From: Jan Beulich
> Sent: 16 September 2020 15:43
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; Durrant, Paul ;
> Ian Jackson
> ; Wei Liu ; Andrew Cooper
> ; George
> Dunlap ; Julien Grall ; Stefano
> Stabellini
>
&g
> -Original Message-
> From: Jan Beulich
> Sent: 28 May 2020 10:42
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; Durrant, Paul ;
> Ian Jackson
> ; Wei Liu ; Andrew Cooper
> ; George
> Dunlap ; Julien Grall ; Stefano
> Stabellini
>
> S
> -Original Message-
> From: Jan Beulich
> Sent: 22 May 2020 15:25
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; Durrant, Paul ;
> Julien Grall
> ; Andrew Cooper ; George Dunlap
> ;
> Ian Jackson ; Stefano Stabellini
> ; Wei Liu
> ; Volod
> -Original Message-
> From: Jan Beulich
> Sent: 22 May 2020 15:34
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; Durrant, Paul ;
> Ian Jackson
> ; Wei Liu ; Andrew Cooper
> ; George
> Dunlap ; Julien Grall ; Stefano
> Stabellini
>
> S
Kevin, ping?
This patch hasn't changed since v2.
Paul
> -Original Message-
> From: Paul Durrant
> Sent: 11 September 2020 09:20
> To: xen-devel@lists.xenproject.org
> Cc: Durrant, Paul ; Jan Beulich ;
> Kevin Tian
>
> Subject: [PATCH v8 1/8] x86/iommu: conv
> -Original Message-
> From: Jan Beulich
> Sent: 21 September 2020 14:32
> To: Julien Grall
> Cc: Durrant, Paul ; Stefano Stabellini
> ;
> andrew.coop...@citrix.com; George Dunlap ; Xia,
> Hongyan
> ; xen-devel@lists.xenproject.org
> Subject: RE: [EXTE
> -Original Message-
> From: Julien Grall
> Sent: 21 September 2020 12:41
> To: Jan Beulich ; Stefano Stabellini
> ;
> andrew.coop...@citrix.com; George Dunlap ; Durrant,
> Paul
>
> Cc: Xia, Hongyan ; xen-devel@lists.xenproject.org
> Subject: RE: [EXTE
> -Original Message-
> From: Jan Beulich
> Sent: 03 August 2020 16:59
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; Durrant, Paul ;
> Andrew Cooper
> ; Wei Liu ; Roger Pau Monné
>
> Subject: RE: [EXTERNAL] [PATCH v3 02/11] x86/iommu: add com
> -Original Message-
> From: Jan Beulich
> Sent: 06 August 2020 13:34
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; Durrant, Paul ;
> Kevin Tian
>
> Subject: RE: [EXTERNAL] [PATCH v4 12/14] vtd: use a bit field for root_entry
>
> CAUTION: This
> -Original Message-
> From: Paul Durrant
> Sent: 30 July 2020 15:29
> To: xen-devel@lists.xenproject.org
> Cc: Durrant, Paul ; Jan Beulich ;
> Andrew Cooper
> ; Wei Liu ; Roger Pau Monné
> ; George
> Dunlap ; Ian Jackson ;
> Julien Grall
> ;
> -Original Message-
> From: Jan Beulich
> Sent: 31 July 2020 14:41
> To: p...@xen.org
> Cc: xen-devel@lists.xenproject.org; Durrant, Paul ;
> 'Andrew Cooper'
> ; 'Wei Liu' ; 'Roger Pau Monné'
>
> Subject: RE: [EXTERNAL] [PATCH v2 2/2] x86/hvm: s
> -Original Message-
> From: Paul Durrant
> Sent: 31 July 2020 15:26
> To: xen-devel@lists.xenproject.org
> Cc: Durrant, Paul ; Jan Beulich ;
> Andrew Cooper
> ; Wei Liu ; Roger Pau Monné
>
> Subject: [EXTERNAL] [PATCH v3 1/2] x86/hvm: set 'ipat'
> -Original Message-
> From: Roger Pau Monné
> Sent: 13 August 2020 11:16
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; Durrant, Paul ;
> Wei Liu ; Jan
> Beulich ; Andrew Cooper
> Subject: RE: [EXTERNAL] [PATCH] x86 / viridian: remove the viridian
> -Original Message-
> From: Ian Jackson
> Sent: 05 August 2020 10:31
> To: p...@xen.org
> Cc: xen-devel@lists.xenproject.org; Durrant, Paul ;
> 'Wei Liu'
> Subject: RE: [EXTERNAL] [PATCH v2 4/4] tools/hotplug: modify set_mtu() to
> inform the frontend via
> -Original Message-
> From: Jan Beulich
> Sent: 06 August 2020 10:57
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; Durrant, Paul ;
> Jun Nakajima
> ; Kevin Tian ; Andrew Cooper
> ; George Dunlap ; Wei
> Liu ; Roger Pau
> Monné ; Ian Jackson
> -Original Message-
> From: Jürgen Groß
> Sent: 03 August 2020 06:09
> To: Paul Durrant ; xen-devel@lists.xenproject.org
> Cc: Durrant, Paul
> Subject: RE: [EXTERNAL] [PATCH 3/4] public/io/netif: specify MTU override node
>
> On 30.07.20 21:48, Paul Durra
> -Original Message-
> From: Jan Beulich
> Sent: 26 July 2020 09:36
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; Durrant, Paul ;
> Andrew Cooper
> ; Wei Liu ; Roger Pau Monné
> ; George
> Dunlap ; Ian Jackson ;
> Julien Grall
> ;
> -Original Message-
> From: Andrew Cooper
> Sent: 24 July 2020 20:01
> To: Paul Durrant ; xen-devel@lists.xenproject.org
> Cc: Durrant, Paul ; Jan Beulich ;
> George Dunlap
> ; Wei Liu ; Roger Pau Monné
> ; Kevin Tian
>
> Subject: RE: [EXTERNAL] [PATCH 5/
> -Original Message-
> From: Jan Beulich
> Sent: 26 July 2020 09:50
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; Durrant, Paul ;
> Andrew Cooper
> ; George Dunlap ; Wei
> Liu ; Roger Pau
> Monné ; Kevin Tian
> Subject: RE: [EXTERNAL] [PATCH 5/
> -Original Message-
> From: Jan Beulich
> Sent: 26 July 2020 09:14
> To: p...@xen.org
> Cc: 'Andrew Cooper' ;
> xen-devel@lists.xenproject.org; Durrant, Paul
> ; 'Lukasz Hawrylko' ;
> 'Wei Liu' ;
> 'Roger Pau Monné' ; 'Kevin Tian'
> Subject: RE: [EXTER
> -Original Message-
> From: Andrew Cooper
> Sent: 24 July 2020 20:09
> To: Paul Durrant ; xen-devel@lists.xenproject.org
> Cc: Durrant, Paul ; Jan Beulich ;
> Kevin Tian
>
> Subject: RE: [EXTERNAL] [PATCH 6/6] iommu: stop calling IOMMU page tables
>
> -Original Message-
> From: Andrew Cooper
> Sent: 24 July 2020 19:24
> To: Paul Durrant ; xen-devel@lists.xenproject.org
> Cc: Durrant, Paul ; Jan Beulich ;
> Kevin Tian
> ; Wei Liu ; Roger Pau Monné
>
> Subject: RE: [EXTERNAL] [PATCH 2/6] x86/iommu: add
> -Original Message-
> From: Jan Beulich
> Sent: 26 July 2020 09:28
> To: p...@xen.org
> Cc: 'Andrew Cooper' ;
> xen-devel@lists.xenproject.org; Durrant, Paul
> ; 'Kevin Tian'
> Subject: RE: [EXTERNAL] [PATCH 3/6] iommu: remove iommu_lookup_page() and the
> -Original Message-
> From: Tian, Kevin
> Sent: 14 August 2020 07:53
> To: Paul Durrant ; xen-devel@lists.xenproject.org
> Cc: Durrant, Paul ; Jan Beulich
> Subject: RE: [EXTERNAL] [PATCH v4 06/14] iommu: flush I/O TLB if iommu_map()
> or iommu_unmap() fail
>
> -Original Message-
[snip]
> > -static void iommu_free_page_table(struct page_info *pg)
> > -{
> > -unsigned int i, next_level = PFN_ORDER(pg) - 1;
> > -u64 pt_maddr = page_to_maddr(pg);
> > -struct dma_pte *pt_vaddr, *pte;
> > -
> > -PFN_ORDER(pg) = 0;
> > -pt_vaddr =
> -Original Message-
> From: Jan Beulich
> Sent: 27 November 2020 16:22
> To: Paul Durrant
> Cc: Durrant, Paul ; Andrew Cooper
> ; George Dunlap
> ; Ian Jackson ; Grall,
> Julien
> ; Jun Nakajima ; Kevin Tian
> ; Roger
> Pau Monné ; Stefano Stab
> -Original Message-
> From: Andrew Cooper
> Sent: 25 November 2020 11:31
> To: Paul Durrant ; xen-devel@lists.xenproject.org
> Cc: Durrant, Paul ; Elnikety, Eslam
> ; Christian Lindig
> ; David Scott ; Ian Jackson
> ; Wei
> Liu ; George Dunlap ; Jan
> -Original Message-
> From: Jan Beulich
> Sent: 25 November 2020 11:51
> To: p...@xen.org
> Cc: Durrant, Paul ; Elnikety, Eslam
> ; 'Christian Lindig'
> ; 'David Scott' ; 'Ian Jackson'
> ;
> 'Wei Liu' ; 'Andrew Cooper' ;
> 'George Dunlap'
> ; 'Julie
> -Original Message-
[snip]
> >> I've gone from you saying "You really need a solution that can restore
> >> the old VM environment, at least temporarily, for that customer." The
> >> "temporarily" to me implies that it is at least an option to tie a
> >> certain guest to a certain Xen
> -Original Message-
> From: Paul Durrant
> Sent: 07 December 2020 16:18
> To: p...@xen.org; 'Wei Liu'
> Cc: xen-devel@lists.xenproject.org; Durrant, Paul ;
> 'Oleksandr Andrushchenko'
> ; 'Ian Jackson' ;
> 'Anthony PERARD'
>
> Subject: RE: [EXTERNAL]
> -Original Message-
> From: Andrew Cooper
> Sent: 04 December 2020 17:45
> To: Stefano Stabellini
> Cc: Julien Grall ; Jan Beulich ;
> p...@xen.org; Durrant, Paul
> ; Elnikety, Eslam ; 'Ian Jackson'
> ;
> 'Wei Liu' ; 'Anthony PERARD' ;
> 'George
> -Original Message-
> From: Jan Beulich
> Sent: 25 November 2020 07:52
> To: Paul Durrant
> Cc: Durrant, Paul ; Wei Liu ; Andrew
> Cooper
> ; Roger Pau Monné ;
> xen-devel@lists.xenproject.org
> Subject: RE: [EXTERNAL] [PATCH v3 01/13] viridian: don't
> -Original Message-
> From: Jan Beulich
> Sent: 25 November 2020 09:36
> To: Andrew Cooper
> Cc: Durrant, Paul ; Elnikety, Eslam
> ; Christian Lindig
> ; David Scott ; Ian Jackson
> ; Wei
> Liu ; George Dunlap ; Julien Grall
> ; Stefano
> Stabellini
> -Original Message-
> From: Jan Beulich
> Sent: 19 November 2020 16:41
> To: p...@xen.org
> Cc: Durrant, Paul ; 'Wei Liu' ; 'Andrew
> Cooper'
> ; 'Roger Pau Monné' ;
> xen-devel@lists.xenproject.org
> Subject: RE: [EXTERNAL] [PATCH 03/10] vi
> -Original Message-
> From: Jan Beulich
> Sent: 20 November 2020 14:20
> To: Paul Durrant
> Cc: Durrant, Paul ; Wei Liu ; Andrew
> Cooper
> ; Roger Pau Monné ;
> xen-devel@lists.xenproject.org
> Subject: RE: [EXTERNAL] [PATCH v2 01/12] viridian: don't
> -Original Message-
> From: Jan Beulich
> Sent: 20 November 2020 15:09
> To: Paul Durrant
> Cc: Durrant, Paul ; Wei Liu ; Andrew
> Cooper
> ; Roger Pau Monné ;
> xen-devel@lists.xenproject.org
> Subject: RE: [EXTERNAL] [PATCH v2 05/12] viridian: use hyperc
> -Original Message-
> From: Jan Beulich
> Sent: 12 November 2020 08:38
> To: Paul Durrant
> Cc: Durrant, Paul ; Wei Liu ; Andrew
> Cooper
> ; Roger Pau Monné ;
> xen-devel@lists.xenproject.org
> Subject: RE: [EXTERNAL] [PATCH 02/10] viridian: move IPI
> -Original Message-
> From: Marek Marczykowski-Górecki
> Sent: 10 May 2021 20:43
> To: Michael Brown ; p...@xen.org
> Cc: p...@xen.org; xen-devel@lists.xenproject.org; net...@vger.kernel.org;
> wei@kernel.org; Durrant,
> Paul
> Subject: RE: [EXTERNAL] [P
> -Original Message-
> From: Marek Marczykowski-Górecki
> Sent: 11 May 2021 11:45
> To: Durrant, Paul
> Cc: Michael Brown ; p...@xen.org;
> xen-devel@lists.xenproject.org;
> net...@vger.kernel.org; wei@kernel.org
> Subject: RE: [EXTERNAL] [PATCH] xen-ne
On 11/10/2021 09:04, Jan Beulich wrote:
On 17.09.2021 13:00, Jan Beulich wrote:
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
On 18/10/2021 11:42, Ian Jackson wrote:
Jan Beulich writes ("[PATCH] x86/HVM: correct cleanup after failed
viridian_vcpu_init()"):
This happens after nestedhvm_vcpu_initialise(), so its effects also need
to be undone.
Fixes: 40a4a9d72d16 ("viridian: add init hooks")
Signed-off-by: Jan Beulich
On 22/09/2021 15:37, Jan Beulich wrote:
IVHD entries may specify that ATS is to be blocked for a device or range
of devices. Honor firmware telling us so.
While adding respective checks I noticed that the 2nd conditional in
amd_iommu_setup_domain_device() failed to check the IOMMU's capability.
On 22/09/2021 15:38, Jan Beulich wrote:
Making these dependent upon "iommu=debug" isn't really helpful in the
field. Where touching respective code anyway also make use of %pp and
%pd.
Requested-by: Andrew Cooper
Signed-off-by: Jan Beulich
Reviewed-by: Paul Durrant
... with one nit
On 22/09/2021 15:36, Jan Beulich wrote:
Doing this in amd_iommu_prepare() is too late for it, in particular, to
be used in amd_iommu_detect_one_acpi(), as a subsequent change will want
to do. Moving it immediately ahead of amd_iommu_detect_acpi() is
(luckily) pretty simple, (pretty importantly)
On 28/09/2021 08:47, Jan Beulich wrote:
On 28.09.2021 09:34, Durrant, Paul wrote:
On 22/09/2021 15:37, Jan Beulich wrote:
IVHD entries may specify that ATS is to be blocked for a device or range
of devices. Honor firmware telling us so.
While adding respective checks I noticed that the 2nd
On 22/09/2021 15:38, Jan Beulich wrote:
Disabling should be done in the opposite order of enabling: ATS wants to
be turned off before adjusting the DTE, just like it gets enabled only
after the DTE was suitably prepared. Note that we want ATS to be
disabled as soon as any of the DTEs involved in
On 23/11/2021 23:59, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
vPCI may map and unmap PCI device memory (BARs) being passed through which
may take a lot of time. For this those operations may be deferred to be
performed later, so that they can be safely preempted.
Currently
On 04/01/2022 07:53, Jan Beulich wrote:
On 14.12.2021 08:49, Jan Beulich wrote:
Attempting to wait when the backend hasn't been created yet can't work:
the function will complain "Backend ... does not exist". Move the
waiting past the creation of the backend (and that of other related
nodes),
On 18/11/2021 13:13, Jan Beulich wrote:
Both the wrong use of HV_STATUS_* and the return type of
hv_vpset_to_vpmask() can lead to viridian_hypercall()'s
ASSERT_UNREACHABLE() triggering when translating error codes from Xen
to Viridian representation.
Fixes: b4124682db6e ("viridian: add
On 18/11/2021 13:14, Jan Beulich wrote:
Both hvcall_flush_ex() and hvcall_ipi_ex() update "size" without
subsequently using the value; future compilers may warn about such.
Alongside dropping the updates, shrink the variables' scopes to
demonstrate that there are no outer scope uses.
On 18/11/2021 11:19, Andrew Cooper wrote:
On 18/11/2021 10:45, Jan Beulich wrote:
On 17.11.2021 19:26, Andrew Cooper wrote:
TLB flushing is a hotpath, and function pointer calls are
expensive (especially under repoline) for what amounts to an identity
transform on the data. Just pass the
On 18/11/2021 13:14, Jan Beulich wrote:
hvcall_{flush,ipi}_ex() use more almost identical code than what was
isolated into hv_vpset_to_vpmask(). Move that code there as well, to
have just one instance of it. This way all of HV_GENERIC_SET_SPARSE_4K
processing now happens in a single place.
On 18/11/2021 18:48, Andrew Cooper wrote:
TLB flushing is a hotpath, and function pointer calls are
expensive (especially under repoline) for what amounts to an identity
transform on the data. Just pass the vcpu_bitmap bitmap directly.
As we use NULL for all rather than none, introduce a
On 25/11/2021 22:55, Juergen Gross wrote:
Today RING_HAS_UNCONSUMED_*() macros are returning the number of
unconsumed requests or responses instead of a boolean as the name of
the macros would imply.
As this "feature" is already being used, rename the macros to
RING_NR_UNCONSUMED_*() and define
On 09/12/2021 04:17, Jan Beulich wrote:
Paul,
in 0fdb48ffe7a1 ("libxl: Make sure devices added by pci-attach are
reflected in the config") you've moved down the invocation of
libxl__create_pci_backend() from libxl__device_pci_add_xenstore().
In the PV case, soon after the original invocation
On 09/12/2021 04:58, Jason Andryuk wrote:
My attempt at a fix was this:
https://lore.kernel.org/xen-devel/20210812005700.3159-1-jandr...@gmail.com/
It was in terms of PCI & stubdom startup , but that is the same as PV
hotplug. There were questions about further re-work which went
unanswered,
On 10/12/2021 11:34, Jason Andryuk wrote:
commit f37f29d31488 "xen: slightly simplify bufioreq handling" hard
coded setting req.count = 1 during initial field setup before the main
loop. This missed a subtlety that an early exit from the loop when
there are no ioreqs to process, would have
On 03/12/2021 03:21, Jan Beulich wrote:
The SDM explicitly permits this, and since that's sensible behavior
don't special case AMD (where the PM doesn't explicitly say so).
Fixes: 52dba7bd0b36 ("x86emul: generalize wbinvd() hook")
Reported-by: Andrew Cooper
Signed-off-by: Jan Beulich
On 03/12/2021 03:23, Jan Beulich wrote:
This is specified (and asserted for in a number of places) to always be
CS. Passing this as an argument in various places is therefore
pointless. The price to pay is two simple new functions, with the
benefit of the PTWR case now gaining a more appropriate
On 08/12/2021 23:09, Juergen Gross wrote:
Today RING_HAS_UNCONSUMED_*() macros are returning the number of
unconsumed requests or responses instead of a boolean as the name of
the macros would imply.
As this "feature" is already being used, rename the macros to
RING_NR_UNCONSUMED_*() and define
On 13/01/2022 04:01, Jason Andryuk wrote:
commit 0fdb48ffe7a1 "libxl: Make sure devices added by pci-attach are
reflected in the config" broken PCI hotplug (xl pci-attach) for PV
domains when it moved libxl__create_pci_backend() later in the function.
This also broke HVM + stubdom PCI
On 11/01/2022 11:11, Roger Pau Monné wrote:
On Thu, Jan 06, 2022 at 09:10:13AM +, Maximilian Heyne wrote:
Given dom0 supports persistent grants but the guest does not.
Then, when attaching a block device during runtime of the guest, dom0
will enable persistent grants for this newly attached
On 16/02/2022 10:30, Roger Pau Monne wrote:
Introduce a new arch specific field to report whether an emulator
supports the Extended Destination ID field, so that the hypervisor can
refrain from exposing the feature if one of the emulators doesn't
support it.
Signed-off-by: Roger Pau Monné
---
On 22/02/2022 00:18, Marek Marczykowski-Górecki wrote:
This reverts commit 1f2565780e9b7218cf92c7630130e82dcc0fe9c2.
The 'hotplug-status' node should not be removed as long as the vif
device remains configured. Otherwise the xen-netback would wait for
re-running the network script even if it
On 22/02/2022 00:18, Marek Marczykowski-Górecki wrote:
This reverts commit 2afeec08ab5c86ae21952151f726bfe184f6b23d.
The reasoning in the commit was wrong - the code expected to setup the
watch even if 'hotplug-status' didn't exist. In fact, it relied on the
watch being fired the first time -
On 16/02/2022 11:32, Roger Pau Monné wrote:
On Wed, Feb 16, 2022 at 10:53:58AM +, Durrant, Paul wrote:
On 16/02/2022 10:30, Roger Pau Monne wrote:
Introduce a new arch specific field to report whether an emulator
supports the Extended Destination ID field, so that the hypervisor can
On 14/02/2022 10:48, James Dingwall wrote:
Hi,
I've been backporting this series to xen 4.14 and everything relating to the
backend seems to be working well. For the frontend I can see the mtu value
published to xenstore but it does't appear to be consumed to set the matching
mtu in the guest.
On 27/01/2022 14:47, Jan Beulich wrote:
This is, once again, to limit the number of indirect calls as much as
possible. The only hook invocation which isn't sensible to convert is
setup(). And of course Arm-only use sites are left alone as well.
Note regarding the introduction / use of local
On 27/01/2022 14:48, Jan Beulich wrote:
The actual function should always have lived in core x86 code; move it
there, replacing get_cache_line_size() by readily available (except very
early during boot; see the code comment) data. Also rename the function.
Drop the respective IOMMU hook,
On 27/01/2022 14:49, Jan Beulich wrote:
Let's use infrastructure we have available instead of an open-coded
wbinvd() invocation.
Signed-off-by: Jan Beulich
Reviewed-by: Paul Durrant
On 27/01/2022 14:49, Jan Beulich wrote:
The VT-d hook can indicate an error, which shouldn't be ignored. Convert
the hook's return value to a proper error code, and let that bubble up.
Signed-off-by: Jan Beulich
Reviewed-by: Paul Durrant
On 24/01/2022 16:02, Roger Pau Monne wrote:
By writing an empty "hotplug-status" xenstore node in the backend path
libxl can force Linux netback to wait for hotplug script execution
before proceeding to the 'connected' state.
This is required so that netback doesn't skip state 2 (InitWait) and
On 24/01/2022 10:44, Ross Lagerwall wrote:
In some cases, a particular mapcache entry may be mapped 256 times
causing the lock field to wrap to 0. For example, this may happen when
using emulated NVME and the guest submits a large scatter-gather write.
At this point, the entry map be remapped
On 25/01/2022 15:08, Jan Beulich wrote:
On 25.01.2022 15:22, Jan Beulich wrote:
We claim to support the insn, but so far the emulator has been handling
it as a NOP.
Signed-off-by: Jan Beulich
I'm sorry, I should have Cc-ed Paul here as well.
Acked-by: Paul Durrant
Jan
---
While
On 26/01/2022 13:43, Jason Andryuk wrote:
On Tue, Dec 14, 2021 at 8:40 AM Durrant, Paul wrote:
On 10/12/2021 11:34, Jason Andryuk wrote:
commit f37f29d31488 "xen: slightly simplify bufioreq handling" hard
coded setting req.count = 1 during initial field setup before the
On 25/10/2023 15:50, David Woodhouse wrote:
From: David Woodhouse
This allows us to use Xen PV networking with emulated Xen guests, and to
add them on the command line or hotplug.
Signed-off-by: David Woodhouse
---
hw/net/meson.build| 2 +-
hw/net/trace-events | 11 +
On 25/10/2023 15:50, David Woodhouse wrote:
From: David Woodhouse
There's no need to force the user to assign a vdev. We can automatically
assign one, starting at xvda and searching until we find the first disk
name that's unused.
This means we can now allow '-drive if=xen,file=xxx' to work
On 25/10/2023 15:50, David Woodhouse wrote:
From: David Woodhouse
The primary Xen console is special. The guest's side is set up for it by
the toolstack automatically and not by the standard PV init sequence.
Accordingly, its *frontend* doesn't appear in …/device/console/0 either;
instead it
On 25/10/2023 15:50, David Woodhouse wrote:
From: David Woodhouse
The primary console is special because the toolstack maps a page into
the guest for its ring, and also allocates the guest-side event channel.
The guest's grant table is even primed to export that page using a known
grant ref#.
On 25/10/2023 15:50, David Woodhouse wrote:
From: David Woodhouse
Most code which directly accesses nd_table[] and nb_nics uses them for
one of two things. Either "I have created a NIC device and I'd like a
configuration for it", or "I will create a NIC device *if* there is a
configuration for
On 25/10/2023 15:50, David Woodhouse wrote:
From: David Woodhouse
By noting the models for which a configuration was requested, we can give
the user an accurate list of which NIC models were actually available on
the platform/configuration that was otherwise chosen.
Signed-off-by: David
On 27/10/2023 11:25, David Woodhouse wrote:
On Fri, 2023-10-27 at 10:01 +0100, Durrant, Paul wrote:
This code is allocating a name automatically so I think the onus is on
it not create a needless clash which is likely to have unpredictable
results depending on what the guest is. Just avoid any
On 27/10/2023 09:45, David Woodhouse wrote:
On Fri, 2023-10-27 at 08:30 +0100, Durrant, Paul wrote:
+ if (blockdev->props.vdev.type == XEN_BLOCK_VDEV_TYPE_INVALID) {
+ XenBus *xenbus = XEN_BUS(qdev_get_parent_bus(DEVICE(xendev)));
+ char fe_path[XENSTORE_ABS_PATH_MAX
On 25/10/2023 15:50, David Woodhouse wrote:
From: David Woodhouse
Eliminate direct access to nd_table[] and nb_nics by processing the the
ISA NICs first and then calling pci_init_nic_devices() for the test.
It's important to do this *before* the subsequent patch which registers
the Xen PV
On 25/10/2023 15:50, David Woodhouse wrote:
From: David Woodhouse
When instantiating XenBus itself, for each NIC which is configured with
either the model unspecified, or set to to "xen" or "xen-net-device",
create a corresponding xen-net-device for it.
Now we can launch emulated Xen guests
On 25/10/2023 15:50, David Woodhouse wrote:
From: David Woodhouse
When fire_watch_cb() found the response buffer empty, it would call
deliver_watch() to generate the XS_WATCH_EVENT message in the response
buffer and send an event channel notification to the guest… without
actually *copying*
On 25/10/2023 15:50, David Woodhouse wrote:
From: David Woodhouse
Even on x86_64 the default protocol is the x86-32 one if the guest doesn't
specifically ask for x86-64.
Fixes: b6af8926fb85 ("xen: add implementations of xen-block connect and disconnect
functions...")
Signed-off-by: David
301 - 400 of 435 matches
Mail list logo
