On Sun, Dec 2, 2018 at 11:55 AM Julien Grall wrote:
>
> Hi,
>
> On 01/12/2018 01:33, Christopher Clark wrote:
> > * x86 PV domains are notified via event channel.
> >
> > PV guests are known to have the event channel software present in the guest
> > kernel, so it is fine to depend on and use it.
> -Original Message-
> From: Christopher Clark [mailto:christopher.w.cl...@gmail.com]
> Sent: 01 December 2018 01:33
> To: xen-devel@lists.xenproject.org
> Cc: Stefano Stabellini ; Julien Grall
> ; Andrew Cooper ; George
> Dunlap ; Ian Jackson ;
> Jan Beulich ; Konrad Rzeszutek Wilk
> ;
From: Talons Lee
Commit e657fcc clears cpu capability bit instead of using fake cpuid
value, the EXID should always be off for PV guest without depending
on cpuid value. So remove the cpuid check in xen_read_msr_safe() to
always clear the X2APIC_ENABLE bit.
Signed-off-by: Talons Lee
---
CC:
>>> On 03.12.18 at 22:03, wrote:
> To be used in constant initializations of mfn_t variables, such as:
>
> static mfn_t node = mfn_init(MM_ADDR);
>
> It is necessary because static inline functions cannot be used as static
> initializers.
We had been at this point once (quite some time ago),
>>> On 04.12.18 at 11:42, wrote:
> @@ -298,6 +299,45 @@ static void check_pdev(const struct pci_dev *pdev)
> #undef PCI_STATUS_CHECK
> }
>
> +static void apply_quirks(struct pci_dev *pdev)
> +{
> +uint16_t vendor = pci_conf_read16(pdev->seg, pdev->bus,
> +
On Mon, Dec 3, 2018 at 7:42 AM Jan Beulich wrote:
>
> >>> On 01.12.18 at 02:32, wrote:
> > http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/errno.h.html
> > describes these codes thus:
> > EMSGSIZE : "Message too large"
> > ECONNREFUSED : "Connection refused".
>
> If you were
On Fri, Nov 30, 2018 at 03:53:29AM -0700, Jan Beulich wrote:
> >>> On 29.11.18 at 18:11, wrote:
> > @@ -397,6 +426,7 @@ static struct pci_dev *alloc_pdev(struct pci_seg *pseg,
> > u8 bus, u8 devfn)
> > }
> >
> > check_pdev(pdev);
> > +apply_quirks(pdev);
>
> At which point
On 04/12/2018 11:25, Xin Li wrote:
> From: Talons Lee
>
> Commit e657fcc clears cpu capability bit instead of using fake cpuid
> value, the EXID should always be off for PV guest without depending
> on cpuid value. So remove the cpuid check in xen_read_msr_safe() to
> always clear the
This errata affect the values read from the BAR registers, and could
render vPCI (and by extension PVH Dom0 unusable).
HSE43 is a Haswell erratum where a non-BAR register is implemented at
the position where the first BAR of the device should be found in a
Power Control Unit device. Note that
From: Oleksandr Tyshchenko
Hi, all.
This is small patch series for ARM32 which needed to be able to bring
secondary CPUs up not only during the initial boot, but at runtime also.
For example, during CPU hotplug.
Actually these are follow-up patches to the following series [1], which covers
From: Oleksandr Tyshchenko
This is a follow-up patch to
commit 01a7e8ccef6e7d5718a251ad587567afbe723330
xen/arm: Remove __initdata and __init to enable CPU hotplug
Signed-off-by: Oleksandr Tyshchenko
---
xen/arch/arm/arm32/smpboot.c | 2 +-
xen/arch/arm/platform.c | 2 +-
2 files
From: Oleksandr Tyshchenko
To be able to use it for the hot pluged CPUs as well.
Signed-off-by: Oleksandr Tyshchenko
---
xen/arch/arm/xen.lds.S | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
index 245a0e0..003301a
> -Original Message-
> From: Christopher Clark [mailto:christopher.w.cl...@gmail.com]
> Sent: 01 December 2018 01:33
> To: xen-devel@lists.xenproject.org
> Cc: Andrew Cooper ; George Dunlap
> ; Ian Jackson ; Jan
> Beulich ; Julien Grall ; Konrad
> Rzeszutek Wilk ; Paul Durrant
> ; Stefano
Doug, ping?
On Thu, Nov 22, 2018 at 03:49:01PM +, Wei Liu wrote:
> Wei Liu (2):
> automation: add a qemu smoke test for clang build
> automation: break .gitlab-yaml into smaller files
>
> .gitlab-ci.yml | 400
> +---
>
On 04/12/2018 09:45, Jan Beulich wrote:
On 03.12.18 at 17:31, wrote:
>> On 03/12/2018 16:24, Jan Beulich wrote:
>> On 03.12.18 at 17:18, wrote:
This is a lingering TODO item from XSA-263. It adds support AMD's
MSR_VIRT_SPEC_CTRL interface, and changes Xen's "boot time global"
> -Original Message-
> From: Christopher Clark [mailto:christopher.w.cl...@gmail.com]
> Sent: 01 December 2018 01:33
> To: xen-devel@lists.xenproject.org
> Cc: Andrew Cooper ; George Dunlap
> ; Ian Jackson ; Jan
> Beulich ; Julien Grall ; Konrad
> Rzeszutek Wilk ; Paul Durrant
> ; Stefano
>>> On 03.12.18 at 20:37, wrote:
> On 06/11/2018 13:45, Jan Beulich wrote:
>> Now that there's an almost unconditional CR4 read right at the beginning
>> of x86_emulate(), centralize its reading there and use result and value
>> everywhere else without further invoking the hook.
>>
>>
> -Original Message-
> From: Christopher Clark [mailto:christopher.w.cl...@gmail.com]
> Sent: 01 December 2018 01:33
> To: xen-devel@lists.xenproject.org
> Cc: Daniel De Graaf ; Paul Durrant
> ; Stefano Stabellini ;
> Rich Persaud ; Ross Philipson
> ; Eric Chanudet ; James
> McKenzie ;
On 04/12/2018 10:25, Xin Li wrote:
> From: Talons Lee
>
> Commit e657fcc clears cpu capability bit instead of using fake cpuid
> value, the EXID should always be off for PV guest without depending
EXTD
> on cpuid value. So remove the cpuid check in xen_read_msr_safe() to
> always clear the
On Wed, Nov 21, 2018 at 03:12:05PM +, Paul Durrant wrote:
> This is a purely cosmetic patch that purges the name 'ioreq' from struct,
> variable and field names. (This name has been problematic for a long time
> as 'ioreq' is the name used for generic I/O requests coming from Xen).
> The patch
>>> On 04.12.18 at 10:10, wrote:
> On Mon, Dec 3, 2018 at 7:42 AM Jan Beulich wrote:
>>
>> >>> On 01.12.18 at 02:32, wrote:
>> > http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/errno.h.html
>> > describes these codes thus:
>> > EMSGSIZE : "Message too large"
>> >
>>> On 01.12.18 at 02:32, wrote:
> --- a/xen/common/argo.c
> +++ b/xen/common/argo.c
> @@ -28,6 +28,10 @@
> DEFINE_XEN_GUEST_HANDLE(argo_addr_t);
> DEFINE_XEN_GUEST_HANDLE(argo_ring_t);
>
> +/* Xen command line option to enable argo */
> +static bool __read_mostly opt_argo_enabled = 0;
The
> -Original Message-
> From: Christopher Clark [mailto:christopher.w.cl...@gmail.com]
> Sent: 04 December 2018 09:03
> To: Julien Grall
> Cc: xen-devel ; n...@arm.com; Andrew Cooper
> ; George Dunlap ; Ian
> Jackson ; Jan Beulich ; Konrad
> Rzeszutek Wilk ; Stefano Stabellini
> ; Tim
> -Original Message-
> From: Christopher Clark [mailto:christopher.w.cl...@gmail.com]
> Sent: 01 December 2018 01:33
> To: xen-devel@lists.xenproject.org
> Cc: Andrew Cooper ; George Dunlap
> ; Ian Jackson ; Jan
> Beulich ; Julien Grall ; Konrad
> Rzeszutek Wilk ; Stefano Stabellini
> ;
On Sun, Dec 2, 2018 at 12:11 PM Julien Grall wrote:
>
>
>
> On 01/12/2018 01:32, Christopher Clark wrote:
> > diff --git a/xen/include/public/argo.h b/xen/include/public/argo.h
> > index 20dabc0..5ad8e2b 100644
> > --- a/xen/include/public/argo.h
> > +++ b/xen/include/public/argo.h
> > @@ -21,6
On 04.12.18 10:44, Michal Suchánek wrote:
> On Fri, 30 Nov 2018 18:59:21 +0100
> David Hildenbrand wrote:
>
>> Let's introduce new types for different kinds of memory blocks and use
>> them in existing code. As I don't see an easy way to split this up,
>> do it in one hunk for now.
>>
>> acpi:
> -Original Message-
> From: Christopher Clark [mailto:christopher.w.cl...@gmail.com]
> Sent: 01 December 2018 01:33
> To: xen-devel@lists.xenproject.org
> Cc: Stefano Stabellini ; Julien Grall
> ; Paul Durrant ; Rich
> Persaud ; Ross Philipson ;
> Eric Chanudet ; James McKenzie
> ; Jason
On Wed, Nov 21, 2018 at 03:12:04PM +, Paul Durrant wrote:
> This is a purely cosmetic patch that substitutes the old 'struct XenBlkDev'
> name with 'XenQdiskDataPlane' and 'blkdev' field/variable names with
> 'dataplane', and then does necessary fix-up to adhere to coding style.
>
> No
>>> On 01.12.18 at 02:32, wrote:
> Signed-off-by: Christopher Clark
Here and elsewhere: Such additions, which we've found no need for
till now, should not be submitted without giving a reason for why
they become necessary or at least desirable.
> --- a/xen/include/public/xen.h
> +++
On Mon, Dec 3, 2018 at 8:49 AM Chris Patterson wrote:
>
> > == Future items
> >
> > The Linux device driver used to test this software is derived from the
> > OpenXT v4v Linux device driver, available at:
> > https://github.com/OpenXT/v4v
> > The Argo implementation is not yet ready to
On Mon, Dec 3, 2018 at 7:51 AM Jan Beulich wrote:
>
> >>> On 01.12.18 at 02:32, wrote:
> > --- a/xen/common/Kconfig
> > +++ b/xen/common/Kconfig
> > @@ -200,6 +200,26 @@ config LATE_HWDOM
> >
> > If unsure, say N.
> >
> > +config ARGO
> > +bool "Argo: hypervisor-mediated interdomain
> -Original Message-
> From: Christopher Clark [mailto:christopher.w.cl...@gmail.com]
> Sent: 01 December 2018 01:33
> To: xen-devel@lists.xenproject.org
> Cc: Andrew Cooper ; George Dunlap
> ; Ian Jackson ; Jan
> Beulich ; Julien Grall ; Konrad
> Rzeszutek Wilk ; Paul Durrant
> ; Stefano
On Tue, Dec 04, 2018 at 02:50:49AM -0500, Zhao Yan wrote:
> For some pci device, even its PCI_INTERRUPT_PIN is not 0, it actually
> doesn't support INTx mode, so its machine irq read from host sysfs is 0.
> In that case, report PCI_INTERRUPT_PIN as 0 to guest and let passthrough
> continue.
>
>
>>> On 03.12.18 at 18:36, wrote:
> On Fri, Nov 30, 2018 at 03:53:29AM -0700, Jan Beulich wrote:
>> >>> On 29.11.18 at 18:11, wrote:
>> > @@ -298,6 +299,34 @@ static void check_pdev(const struct pci_dev *pdev)
>> > #undef PCI_STATUS_CHECK
>> > }
>> >
>> > +static void apply_quirks(struct
> -Original Message-
> From: Christopher Clark [mailto:christopher.w.cl...@gmail.com]
> Sent: 01 December 2018 01:33
> To: xen-devel@lists.xenproject.org
> Cc: Jan Beulich ; Andrew Cooper
> ; Wei Liu ; Roger Pau
> Monne ; George Dunlap ;
> Ian Jackson ; Julien Grall ;
> Konrad Rzeszutek
>>> On 03.12.18 at 17:31, wrote:
> On 03/12/2018 16:24, Jan Beulich wrote:
> On 03.12.18 at 17:18, wrote:
>>> This is a lingering TODO item from XSA-263. It adds support AMD's
>>> MSR_VIRT_SPEC_CTRL interface, and changes Xen's "boot time global" SSBD
>>> setting into a per-vcpu setting.
On Fri, 30 Nov 2018 18:59:21 +0100
David Hildenbrand wrote:
> Let's introduce new types for different kinds of memory blocks and use
> them in existing code. As I don't see an easy way to split this up,
> do it in one hunk for now.
>
> acpi:
> Use DIMM or DIMM_UNREMOVABLE depending on
>>> On 03.12.18 at 18:10, wrote:
> flight 130895 xen-unstable real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/130895/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-amd64-amd64-pygrub 7 xen-boot
> -Original Message-
> From: Christopher Clark [mailto:christopher.w.cl...@gmail.com]
> Sent: 01 December 2018 01:33
> To: xen-devel@lists.xenproject.org
> Cc: Andrew Cooper ; George Dunlap
> ; Ian Jackson ; Jan
> Beulich ; Julien Grall ; Konrad
> Rzeszutek Wilk ; Stefano Stabellini
> ;
> -Original Message-
> From: Christopher Clark [mailto:christopher.w.cl...@gmail.com]
> Sent: 01 December 2018 01:33
> To: xen-devel@lists.xenproject.org
> Cc: Andrew Cooper ; George Dunlap
> ; Ian Jackson ; Jan
> Beulich ; Julien Grall ; Konrad
> Rzeszutek Wilk ; Stefano Stabellini
> ;
flight 130965 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130965/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-xtf-amd64-amd64-5 50 xtf/test-hvm64-lbr-tsx-vmentry fail like 130743
test-xtf-amd64-amd64-3 50
On 04/12/2018 12:45, Jan Beulich wrote:
On 04.12.18 at 12:26, wrote:
>> On 04/12/2018 09:45, Jan Beulich wrote:
>>> Nor can I see how hiding these MSRs from guests would improve
>>> the situation in this regard: Guests may still draw unwanted
>>> conclusions from not being able to read these
flight 130923 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130923/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-multivcpu 16 guest-start/debian.repeat fail REGR. vs.
130869
Tests which did
flight 130908 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130908/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR.
vs. 125898
>>> On 03.12.18 at 18:40, wrote:
> A subsequent patch will add semantically different versions of
> iommu_map/unmap() so, in advance of that change, this patch renames the
> existing functions to iommu_legacy_map/unmap() and modifies all call-sites.
Hmm, this is the second rename in pretty short
On Tue, Dec 04, 2018 at 05:46:38AM +, Connor Davis wrote:
> ‐‐‐ Original Message ‐‐‐
> On Monday, December 3, 2018 1:07 PM, Rian Quinn wrote:
> >>> > > IO Ports (some of these are odd):
> >>> > > - 0xCF8 - 0xCFF
> >>> > > - 0x4D0 (odd since PIT and ACPI is disable for everything that
On Tue, Dec 04, 2018 at 04:30:51AM -0700, Jan Beulich wrote:
> >>> On 04.12.18 at 11:42, wrote:
> > @@ -298,6 +299,45 @@ static void check_pdev(const struct pci_dev *pdev)
> > #undef PCI_STATUS_CHECK
> > }
> >
> > +static void apply_quirks(struct pci_dev *pdev)
> > +{
> > +uint16_t vendor
>>> On 04.12.18 at 13:18, wrote:
> Right, so you're saying that the series would be able to go in provided
> that the situation is not made worse than it currently is.
Well, I'm not the maintainer of this code, so in principle the
series can go in despite my reservations.
> As far as I can
On Mon, Dec 03, 2018 at 04:24:24PM +, Anthony PERARD wrote:
> On Wed, Nov 21, 2018 at 03:12:00PM +, Paul Durrant wrote:
> > +static void xen_device_event(void *opaque)
> > +{
> > +XenDevice *xendev = opaque;
> > +unsigned long port = xenevtchn_pending(xendev->xeh);
> > +
> > +
On 12/3/18 10:49 AM, Jan Beulich wrote:
On 30.11.18 at 22:59, wrote:
>> On 11/29/18 3:58 PM, Jan Beulich wrote:
>>> Altp2m-s don't matter here at all. My point is that the present,
>>> unpatched p2m_change_type_range() updates the log-dirty
>>> ranges with the unclipped [start,end), but
On Wed, Nov 21, 2018 at 03:12:06PM +, Paul Durrant wrote:
> This is a purely cosmetic patch that purges remaining use of 'blk' and
> 'ioreq' in local function names.
>
> No functional change.
>
> Signed-off-by: Paul Durrant
I don't think it's a good idee to use function names that could be
The Xenstore domid isn't set for HVM domains. This will result in
failure when booting a HVM domain on a system with Xenstore not running
in dom0.
Same applies for console domid, so set both.
This is broken since commit a2d9a6fa1fcd ("tools/libxenctrl: use new
xenforeignmemory API to seed grant
flight 130911 linux-4.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130911/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install
fail REGR. vs. 130155
>>> On 04.12.18 at 12:26, wrote:
> On 04/12/2018 09:45, Jan Beulich wrote:
>> Nor can I see how hiding these MSRs from guests would improve
>> the situation in this regard: Guests may still draw unwanted
>> conclusions from not being able to read these MSRs, or reading
>> all zeros.
>
> I can't
On 12/4/18 2:54 PM, Jan Beulich wrote:
On 04.12.18 at 13:18, wrote:
>> Right, so you're saying that the series would be able to go in provided
>> that the situation is not made worse than it currently is.
>
> Well, I'm not the maintainer of this code, so in principle the
> series can go in
On Wed, Nov 21, 2018 at 03:12:07PM +, Paul Durrant wrote:
> diff --git a/hw/block/xen-qdisk.c b/hw/block/xen-qdisk.c
> index 35f7b70480..8c88393832 100644
> --- a/hw/block/xen-qdisk.c
> +++ b/hw/block/xen-qdisk.c
> static void xen_qdisk_connect(XenQdiskDevice *qdiskdev, Error **errp)
> {
>
flight 75633 distros-debian-snapshot real [real]
http://osstest.xensource.com/osstest/logs/75633/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-amd64-weekly-netinst-pygrub 10 debian-di-install fail like
75623
>>> On 03.12.18 at 20:23, wrote:
> Signed-off-by: Andrew Cooper
With s/POP/POPF/g in all comments you add (in the first of them
an alternative would be to drop the mnemonic altogether)
Reviewed-by: Jan Beulich
Jan
___
Xen-devel mailing list
flight 130916 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130916/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install
fail REGR. vs. 130373
>>> On 04.12.18 at 14:41, wrote:
> On 04/12/2018 12:45, Jan Beulich wrote:
> On 04.12.18 at 12:26, wrote:
>>> On 04/12/2018 09:45, Jan Beulich wrote:
Nor can I see how hiding these MSRs from guests would improve
the situation in this regard: Guests may still draw unwanted
Instead of registering compat properties as globals, let's keep them
in their own array, to avoid mixing with user globals.
Introduce object_apply_global_props() function, to apply compatibility
properties from a GPtrArray.
Signed-off-by: Marc-André Lureau
---
include/hw/qdev-core.h | 10
>>> On 03.12.18 at 18:40, wrote:
> +static unsigned long flush_count(unsigned long dfn, unsigned int page_count,
> + unsigned int order)
> +{
> +unsigned long start = dfn / (1u << order);
> +unsigned long end = DIV_ROUND_UP(dfn + page_count, (1u << order));
>>> On 03.12.18 at 18:40, wrote:
> Now that the iommu_map() and iommu_unmap() operations take an order
> parameter and elide flushing there's no strong reason why modifying MMIO
> ranges in the p2m should be restricted to a 4k granularity simply because
> the IOMMU is enabled but shared page
>>> On 03.12.18 at 17:18, wrote:
> bti= was introduced with the original Spectre fixes (Jan 2018), but by the
> time Speculative Store Bypass came along (May 2018), it was superceeded by the
> more generic spec-ctrl=.
>
> Since then, we've had LazyFPU (June 2018) and L1TF (August 2018), which
On Wed, Nov 21, 2018 at 03:12:09PM +, Paul Durrant wrote:
> This patch adds a creator function for XenQdiskDevice-s so that they can
> be created automatically when the Xen toolstack instantiates a new
> PV backend. When the XenQdiskDevice is created this way it is also
> necessary to create a
Hi,
Title: xen/arm: link: ...
On 12/4/18 11:42 AM, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
To be able to use it for the hot pluged CPUs as well.
s/hot pluged/hot-plugged/
Signed-off-by: Oleksandr Tyshchenko
---
xen/arch/arm/xen.lds.S | 10 ++
1 file changed, 6
Hi Andrii,
On 12/3/18 2:36 PM, Andrii Anisov wrote:
On 03.12.18 15:53, Juergen Gross wrote:
On 03/12/2018 14:46, Andre Przywara wrote:
I think PERFCOUNTER is your friend.
CONFIG_LOCK_PROFILE and xen-lockprof on tools side?
Not sure it is still working, though. Its about 9 years since I
Since Linux 4.12, there has been a commit
a1e23a42f1bdc00e32fc4869caef12e4e6272f26
"rtc: cmos: Do not assume irq 8 for rtc when there are no legacy irqs"
The commit effectively disabled requesting IRQ 8 for systems without PIC
controller present (As in the case when used at dom0 under Xen)
On Tue, Dec 04, 2018 at 05:46:38AM +, Connor Davis wrote:
> >>> > > - 0x70
> >>> > > - 0x71
>
> These are accessed from reassert_nmi. This is only called from default_do_nmi
> in the version the guest is based on (4.20-rc2).
Ops, forgot to answer this one.
Xen sets the 'CMOS RTC Not
Hi Mirela,
On 11/29/18 2:02 PM, Mirela Simonovic wrote:
Hi Julien,
On Tue, Nov 27, 2018 at 7:36 PM Julien Grall wrote:
On 11/17/18 4:01 PM, Mirela Simonovic wrote:
Hi,
Hi Mirela,
On Sat, Nov 17, 2018 at 12:06 AM Stefano Stabellini
wrote:
On Sat, 17 Nov 2018, Dario Faggioli wrote:
Hi Oleksandr,
On 12/4/18 11:42 AM, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
This is a follow-up patch to
commit 01a7e8ccef6e7d5718a251ad587567afbe723330
xen/arm: Remove __initdata and __init to enable CPU hotplug
Signed-off-by: Oleksandr Tyshchenko
Acked-by: Julien Grall
On Tue, Dec 4, 2018 at 10:11 AM Chris Brannon wrote:
>
> Hi,
> I set up a network driver domain for a dom0; it uses HVM
> virtualization. It worked very well when not using a device model
> stubdomain, but when I requested the use of a device model stubdomain in
> my xl.cfg file, the domU
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
> Of Jan Beulich
> Sent: 04 December 2018 16:02
> To: Paul Durrant
> Cc: Kevin Tian ; Stefano Stabellini
> ; Wei Liu ; Konrad Rzeszutek
> Wilk ; Andrew Cooper ;
> Tim (Xen.org) ; George Dunlap
>>> On 04.12.18 at 17:53, wrote:
>> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
>> Of Jan Beulich
>> Sent: 04 December 2018 16:02
>>
>> >>> On 04.12.18 at 16:36, wrote:
>> >> From: Jan Beulich [mailto:jbeul...@suse.com]
>> >> Sent: 04 December 2018 15:17
>> >>
>>
> -Original Message-
> From: Qemu-devel [mailto:qemu-devel-
> bounces+paul.durrant=citrix@nongnu.org] On Behalf Of Paul Durrant
> Sent: 04 December 2018 15:20
> To: Anthony Perard
> Cc: Kevin Wolf ; Stefano Stabellini
> ; qemu-bl...@nongnu.org; qemu-de...@nongnu.org;
> Max Reitz ;
On Tue, Dec 4, 2018 at 7:13 PM Julien Grall wrote:
> Hi,
>
Hi, Julien
>
> Title: xen/arm: link: ...
>
ok
>
> On 12/4/18 11:42 AM, Oleksandr Tyshchenko wrote:
> > From: Oleksandr Tyshchenko
> >
> > To be able to use it for the hot pluged CPUs as well.
>
> s/hot pluged/hot-plugged/
>
ok
>
>
Hi,
I set up a network driver domain for a dom0; it uses HVM
virtualization. It worked very well when not using a device model
stubdomain, but when I requested the use of a device model stubdomain in
my xl.cfg file, the domU refused to boot. It gave the following error
message.
[76594.195404]
flight 130938 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130938/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install
fail REGR. vs.
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 04 December 2018 14:25
> To: Paul Durrant
> Cc: Brian Woods ; Suravee Suthikulpanit
> ; Andrew Cooper
> ; Roger Pau Monne ; Wei
> Liu ; xen-devel
> Subject: Re: [PATCH v2 1/4] amd-iommu: add flush iommu_ops
>
>
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 04 December 2018 15:21
> To: Paul Durrant
> Cc: Andrew Cooper ; Roger Pau Monne
> ; Wei Liu ; George Dunlap
> ; xen-devel
> Subject: Re: [PATCH v2 4/4] x86/mm/p2m: stop checking for IOMMU shared
> page tables in
Hi Stefano,
On 11/12/18 11:36 PM, Stefano Stabellini wrote:
On Mon, 12 Nov 2018, Julien Grall wrote:
Hi Stefano,
On 11/6/18 2:20 PM, Julien Grall wrote:
On 05/11/2018 17:56, Stefano Stabellini wrote:
On Mon, 5 Nov 2018, Julien Grall wrote:
On 02/11/2018 23:27, Stefano Stabellini wrote:
On
On Tue, Dec 04, 2018 at 03:20:04PM +, Paul Durrant wrote:
> > > +static char *disk_to_vbd_name(unsigned int disk)
> > > +{
> > > +unsigned int len = DIV_ROUND_UP(disk, 26);
> > > +char *name = g_malloc0(len + 1);
> > > +
> > > +do {
> > > +name[len--] = 'a' + (disk % 26);
>
>>> On 03.12.18 at 18:40, wrote:
> Now that the iommu_map() and iommu_unmap() operations take an order
> parameter and elide flushing there's no strong reason why modifying MMIO
> ranges in the p2m should be restricted to a 4k granularity simply because
> the IOMMU is enabled but shared page
On Tue, Dec 04, 2018 at 05:49:24AM +, Chen, Farrah wrote:
> Hi all,
>
> When I make grub, I met error " too few arguments to function
> 'grub_create_loader_cmdline'" with xen.
> I used git bisect and found the error occurred from commit:
> 4d4a8c96e3593d76fe7b025665ccdecc70a53c1f.
> Do you
On 30/11/2018 13:22, Christoph Hellwig wrote:
Error handling of the dma_map_single and dma_map_page APIs is a little
problematic at the moment, in that we use different encodings in the
returned dma_addr_t to indicate an error. That means we require an
additional indirect call to figure out if
On Wed, Nov 21, 2018 at 03:12:10PM +, Paul Durrant wrote:
> I have made many significant contributions to the Xen code in QEMU,
> particularly the recent patches introducing a new PV device framework.
> I intend to make further significant contributions, porting other PV back-
> ends to the
On Wed, Nov 21, 2018 at 03:12:08PM +, Paul Durrant wrote:
> +xen_backend_device_create(BUS(xenbus), type, name, opts, _err);
> +qobject_unref(opts);
> +
> +if (local_err) {
> +const char *msg = error_get_pretty(local_err);
> +
> +error_report("failed to create '%s'
On 11/5/18 11:21 PM, Julien Grall wrote:
On 11/5/18 7:47 PM, Stefano Stabellini wrote:
On Mon, 8 Oct 2018, Julien Grall wrote:
/*
+ * HCR_EL2.TVM
+ *
+ * ARMv8 (DDI 0487B.b): Table D1-37
In 0487D.a is D1-99
I haven't had the chance to download the latest spec (it was
>>> On 03.12.18 at 17:18, wrote:
> This appears to be a vestigial remnent of an old version of the
> XSA-254/Spectre series, and has never been used.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
___
Xen-devel mailing list
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 04 December 2018 14:51
> To: Paul Durrant
> Cc: Julien Grall ; Andrew Cooper
> ; Roger Pau Monne ; Wei
> Liu ; George Dunlap ; Ian
> Jackson ; Jun Nakajima ;
> Kevin Tian ; Stefano Stabellini
> ; xen-devel ;
>
On Mon, Dec 03, 2018 at 04:18:17PM +, Andy Cooper wrote:
> At the time of writing, the spec is available from:
>
>
> https://developer.amd.com/wp-content/resources/124441_AMD64_SpeculativeStoreBypassDisable_Whitepaper_final.pdf
>
> Future hardware (Zen v2) is expect to have hardware
>>> On 03.12.18 at 17:18, wrote:
> For gen-cpuid.py, fix a comment describing self.names, and generate the
> reverse mapping in self.values. Write out INIT_FEATURE_NAMES which maps a
> string name to a bit position.
>
> For parse_cpuid(), introduce a slightly fuzzy strcmp() to accept changes in
> -Original Message-
> From: Anthony PERARD [mailto:anthony.per...@citrix.com]
> Sent: 29 November 2018 16:06
> To: Paul Durrant
> Cc: qemu-bl...@nongnu.org; qemu-de...@nongnu.org; xen-
> de...@lists.xenproject.org; Kevin Wolf ; Max Reitz
> ; Stefano Stabellini
> Subject: Re: [PATCH
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 04 December 2018 15:17
> To: Paul Durrant
> Cc: Brian Woods ; Suravee Suthikulpanit
> ; Julien Grall ;
> Andrew Cooper ; Roger Pau Monne
> ; Wei Liu ; George Dunlap
> ; Ian Jackson ; Kevin
> Tian ; Stefano
> -Original Message-
> From: Anthony PERARD [mailto:anthony.per...@citrix.com]
> Sent: 04 December 2018 15:49
> To: Paul Durrant
> Cc: qemu-bl...@nongnu.org; qemu-de...@nongnu.org; xen-
> de...@lists.xenproject.org; Kevin Wolf ; Max Reitz
> ; Stefano Stabellini
> Subject: Re: [PATCH
>>> On 04.12.18 at 16:36, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 04 December 2018 15:17
>>
>> >>> On 03.12.18 at 18:40, wrote:
>> > --- a/xen/arch/arm/p2m.c
>> > +++ b/xen/arch/arm/p2m.c
>> > @@ -971,8 +971,17 @@ static int __p2m_set_entry(struct p2m_domain *p2m,
>> >
flight 131013 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131013/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-armhf-armhf-xl
On Mon, Dec 03, 2018 at 04:18:19PM +, Andy Cooper wrote:
> The need for per-core resources is a property of Fam17h hardware. The
> mechanim for calculating / allocating space is all a bit horrible, but is the
> best which can be done at this point. See the code comments for details.
>
>
>>> On 03.12.18 at 18:40, wrote:
> This patch removes any implicit flushing that occurs in the implementation
> of map and unmap operations and adds new iommu_map/unmap() wrapper
> functions. To maintain sematics of the iommu_legacy_map/unmap() wrapper
> functions, these are modified to call the
>>> On 04.12.18 at 16:22, wrote:
>> -Original Message-
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 04 December 2018 15:21
>> To: Paul Durrant
>> Cc: Andrew Cooper ; Roger Pau Monne
>> ; Wei Liu ; George Dunlap
>> ; xen-devel
>> Subject: Re: [PATCH v2 4/4] x86/mm/p2m: stop
1 - 100 of 148 matches
Mail list logo
