On 04/04/2024 15:08, Ross Lagerwall wrote:
A malicious or buggy guest may generated buffered ioreqs faster than
QEMU can process them in handle_buffered_iopage(). The result is a
livelock - QEMU continuously processes ioreqs on the main thread without
iterating through the main loop which
On 11/12/2023 09:14, Nicola Vetrini wrote:
This is consistent with other instances of the same function
and also resolves a violation of MISRA C:2012 Rule 8.4.
No functional change.
Signed-off-by: Nicola Vetrini
Reviewed-by: Stefano Stabellini
---
xen/arch/x86/hvm/viridian/synic.c | 2 +-
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 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
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
The loop over nd_table[] to add PCI NICs is repeated in quite a few
places. Add a helper function to do it.
Some platforms also try to instantiate a specific model in a specific
slot, to match the real hardware. Add
On 25/10/2023 15:50, David Woodhouse wrote:
From: David Woodhouse
This will instantiate any NICs which live on a given bus type. Each bus
is allowed *one* substitution (for PCI it's virtio → virtio-net-pci, for
Xen it's xen → xen-net-device; no point in overengineering it unless we
actually
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 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
To support Xen guests using the Q35 chipset, the unplug protocol needs
to also remove AHCI disks.
Make pci_xen_ide_unplug() more generic, iterating over the children
of the PCI device and destroying the "ide-hd" devices. That
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
In net_cleanup() we only need to delete the netdevs, as those may have
state which outlives Qemu when it exits, and thus may actually need to
be cleaned up on exit.
The nics, on the other hand, are owned by the device which
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
When the Xen guest asks to unplug *emulated* NICs, it's kind of unhelpful
also to unplug the peer of the *Xen* PV NIC.
Signed-off-by: David Woodhouse
---
hw/i386/xen/xen_platform.c | 9 +++--
1 file changed, 7
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
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
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
Upstream Xen now ignores this flag¹, since the only guest kernel ever to
use it was buggy.
¹ https://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=19c6cbd909
Signed-off-by: David Woodhouse
Reviewed-by: Paul Durrant
---
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
On 25/10/2023 15:50, David Woodhouse wrote:
From: David Woodhouse
The xen_evtchn_soft_reset() function requires the iothread mutex, but is
also called for the EVTCHNOP_reset hypercall. Ensure the mutex is taken
in that case.
Fixes: a15b10978fe6 ("hw/xen: Implement EVTCHNOP_reset")
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 20/10/2023 14:37, David Woodhouse wrote:
[snip]
[0]
https://elixir.bootlin.com/linux/latest/source/drivers/tty/hvc/hvc_xen.c#L258
I'm not convinced I believe what the comment says there about evtchn 0
being theoretically valid. I don't believe zero is a valid evtchn#, is
it?
gfn 0 might
On 03/08/2023 12:46, Jan Beulich wrote:
On 27.07.2023 20:41, Stefano Stabellini wrote:
On Thu, 27 Jul 2023, Jan Beulich wrote:
In the latter case the variable altogether is then unused and hence gets
dropped, eliminating a Misra Rule 5.3 violation. I'm afraid I mistakenly
introduced both
On 05/07/2022 13:49, Jan Beulich wrote:
This way intel_iommu_unmap_page() ends up quite a bit more similar to
intel_iommu_map_page().
No functional change intended.
Signed-off-by: Jan Beulich
Reviewed-by: Kevin Tian
Reviewed-by: Roger Pau Monné
Reviewed-by: Paul Durrant
On 05/07/2022 13:49, Jan Beulich wrote:
Signed-off-by: Jan Beulich
Reviewed-by: Kevin tian
Reviewed-by: Roger Pau Monné
Reviewed-by: Paul Durrant
On 05/07/2022 13:48, Jan Beulich wrote:
When a page table ends up with all contiguous entries (including all
identical attributes), it can be replaced by a superpage entry at the
next higher level. The page table itself can then be scheduled for
freeing.
The adjustment to LEVEL_MASK is merely
On 05/07/2022 13:48, Jan Beulich wrote:
When a page table ends up with all contiguous entries (including all
identical attributes), it can be replaced by a superpage entry at the
next higher level. The page table itself can then be scheduled for
freeing.
Signed-off-by: Jan Beulich
Reviewed-by:
On 05/07/2022 13:48, Jan Beulich wrote:
When a page table ends up with no present entries left, it can be
replaced by a non-present entry at the next higher level. The page table
itself can then be scheduled for freeing.
Note that while its output isn't used there yet,
On 05/07/2022 13:47, Jan Beulich wrote:
When a page table ends up with no present entries left, it can be
replaced by a non-present entry at the next higher level. The page table
itself can then be scheduled for freeing.
Note that while its output isn't used there yet,
On 05/07/2022 13:47, Jan Beulich wrote:
Page tables are used for two purposes after allocation: They either
start out all empty, or they are filled to replace a superpage.
Subsequently, to replace all empty or fully contiguous page tables,
contiguous sub-regions will be recorded within
On 05/07/2022 13:47, Jan Beulich wrote:
This is a re-usable helper (kind of a template) which gets introduced
without users so that the individual subsequent patches introducing such
users can get committed independently of one another.
See the comment at the top of the new file. To demonstrate
On 05/07/2022 13:46, Jan Beulich wrote:
... depending on feature availability (and absence of quirks).
Also make the page table dumping function aware of superpages.
Signed-off-by: Jan Beulich
Reviewed-by: Kevin Tian
Reviewed-by: Roger Pau Monné
Reviewed-by: Paul Durrant
On 05/07/2022 13:45, Jan Beulich wrote:
No separate feature flags exist which would control availability of
these; the only restriction is HATS (establishing the maximum number of
page table levels in general), and even that has a lower bound of 4.
Thus we can unconditionally announce 2M and 1G
On 05/07/2022 13:45, Jan Beulich wrote:
Before actually enabling their use, provide a means to suppress it in
case of problems. Note that using the option can also affect the sharing
of page tables in the VT-d / EPT combination: If EPT would use large
page mappings but the option is in effect,
On 05/07/2022 13:44, Jan Beulich wrote:
For vendor specific code to support superpages we need to be able to
deal with a superpage mapping replacing an intermediate page table (or
hierarchy thereof). Consequently an iommu_alloc_pgtable() counterpart is
needed to free individual page tables while
On 05/07/2022 13:44, Jan Beulich wrote:
For large page mappings to be easily usable (i.e. in particular without
un-shattering of smaller page mappings) and for mapping operations to
then also be more efficient, pass batches of Dom0 memory to iommu_map().
In dom0_construct_pv() and its helpers
On 05/07/2022 13:43, Jan Beulich wrote:
From: Roger Pau Monné
The loop in iommu_{,un}map() can be arbitrary large, and as such it
needs to handle preemption. Introduce a new flag that signals whether
the function should do preemption checks, returning the number of pages
that have been
On 13/07/2022 09:48, Juergen Gross wrote:
xenvif_rx_next_skb() is expecting the rx queue not being empty, but
in case the loop in xenvif_rx_action() is doing multiple iterations,
the availability of another skb in the rx queue is not being checked.
This can lead to crashes:
[40072.537261] BUG:
On 26/06/2022 10:46, Bernhard Beschow wrote:
The only user of xen_set_pci_link_route() is
xen_piix_pci_write_config_client() which implements PIIX-specific logic in
the xen namespace. This makes xen-hvm depend on PIIX which could be
avoided if xen_piix_pci_write_config_client() was implemented
On 26/06/2022 10:46, Bernhard Beschow wrote:
xen_piix_pci_write_config_client() is implemented in the xen sub tree and
uses PIIX constants internally, thus creating a direct dependency on
PIIX. Now that xen_set_pci_link_route() is stubbable, the logic of
xen_piix_pci_write_config_client() can be
On 18/05/2022 14:09, Stefan Hajnoczi wrote:
Commit 1b7fd729559c ("block: rename buffer_alignment to
guest_block_size") noted:
At this point, the field is set by the device emulation, but completely
ignored by the block layer.
The last time the value of buffer_alignment/guest_block_size
On 08/05/2022 11:34, Bernhard Beschow wrote:
This function was declared in a generic and public header, implemented
in a device-specific source file but only used in xen_platform. Given its
'aux' parameter, this function is more xen-specific than piix-specific.
Also, the hardcoded magic
On 05/05/2022 18:51, Julien Grall wrote:
From: Julien Grall
Xen provides hypercalls to shutdown (SCHEDOP_shutdown{,_code}) and
resume a domain (XEN_DOMCTL_resumedomain). They can be used for checkpoint
where the expectation is the domain should continue as nothing happened
afterwards.
On 28/04/2022 22:23, Jakub Kicinski wrote:
Defining local versions of NAPI_POLL_WEIGHT with the same
values in the drivers just makes refactoring harder.
Drop the special defines in a bunch of drivers where the
removal is relatively simple so grouping into one patch
does not impact
On 21/04/2022 15:27, Jan Beulich wrote:
At their use sites the numeric suffixes are at least odd to read, first
and foremost for PCI_DEVFN2() where the suffix doesn't even match the
number of arguments. Make use of count_args() such that a single flavor
each suffices (leaving aside helper
On 21/04/2022 15:26, Jan Beulich wrote:
There's no good reason to use these when we already have a pci_sbdf_t
type object available. This extends to the use of PCI_BUS() in
pci_ecam_map_bus() as well.
No change to generated code (with gcc11 at least, and I have to admit
that I didn't expect
On 19/04/2022 10:39, Jan Beulich wrote:
Besides the reporter's issue of hitting a NULL deref when !CONFIG_GDBSX,
XEN_DOMCTL_test_assign_device can legitimately end up having NULL passed
here, when the domctl was passed DOMID_INVALID.
Fixes: 71e617a6b8f6 ("use is_iommu_enabled() where
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 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 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 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 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: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 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: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: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 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/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 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 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 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 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: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 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 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 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 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 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 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 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 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 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 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/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 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 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:
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: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 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: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)
> -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
> -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: 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-
[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: 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: 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: 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-
> 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 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: 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: 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: 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: 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: 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: 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: 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: 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
1 - 100 of 435 matches
Mail list logo
