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 Tue, Dec 04, 2018 at 10:39:03PM +, Woods, Brian wrote:
>On Thu, Nov 29, 2018 at 10:22:10AM +0100, Roger Pau Monné wrote:
>> On Thu, Nov 29, 2018 at 10:40:32AM +0800, Chao Gao wrote:
>> > On Wed, Nov 28, 2018 at 01:00:14PM +0100, Roger Pau Monné wrote:
>> > >On Wed, Nov 28, 2018 at
On Tue, Dec 04, 2018 at 10:30:18AM +0100, Roger Pau Monné wrote:
> 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,
flight 130954 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130954/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-xtf-amd64-amd64-5 69 xtf/test-hvm64-xsa-278 fail blocked in 130212
The problem is that we call this with a spin lock held.
The call tree is:
pvcalls_front_accept() holds bedata->socket_lock.
-> create_active()
-> __get_free_pages() uses GFP_KERNEL
The create_active() function is only called from pvcalls_front_accept()
with a spin_lock held, The
I find some pass-thru devices don't work any more across guest reboot.
Assigning it to another guest also meets the same issue. And the only
way to make it work again is un-binding and binding it to pciback.
Someone reported this issue one year ago [1]. More detail also can be
found in [2].
The
On 11/30/18 2:42 AM, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> based frontends. Currently the frontends which implement
> similar code for sharing big buffers between frontend and
> backend are para-virtualized DRM and sound drivers.
> Both define the same way to share
On Tue, 4 Dec 2018, Julien Grall wrote:
> A follow-up patch will re-purpose the valid bit of LPAE entries to
> generate fault even on entry containing valid information.
>
> This means that when translating a guest VA to guest PA (e.g IPA) will
> fail if the Stage-2 entries used have the valid
On Tue, 4 Dec 2018, Julien Grall wrote:
> The LPAE format allows to store information in an entry even with the
> valid bit unset. In a follow-up patch, we will take advantage of this
> feature to re-purpose the valid bit for generating a translation fault
> even if an entry contains valid
On Tue, 4 Dec 2018, Julien Grall wrote:
> A lot of the headers are not necessary, so remove them. At the same
> time, re-order them alphabetically.
>
> Signed-off-by: Julien Grall
Reviewed-by: Stefano Stabellini
> ---
> xen/arch/arm/p2m.c | 18 +-
> 1 file changed, 5
On Wed, Nov 28, 2018 at 09:55:59AM +, Paul Durrant wrote:
> The page merging logic makes use of bits 1-8 and bit 63 of a PTE, which
> used to be specified as 'ignored'. However, bits 5 and 6 are now specified
> as 'accessed' and 'dirty' bits and their use only remains safe as long as
> the DTE
flight 130966 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130966/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
freebsd b1bbabbbe7be2b91c44cbda5b20cc58e7f870627
baseline version:
freebsd
On Thu, Nov 29, 2018 at 10:22:10AM +0100, Roger Pau Monné wrote:
> On Thu, Nov 29, 2018 at 10:40:32AM +0800, Chao Gao wrote:
> > On Wed, Nov 28, 2018 at 01:00:14PM +0100, Roger Pau Monné wrote:
> > >On Wed, Nov 28, 2018 at 01:34:12PM +0800, Chao Gao wrote:
> > >> ... and search caches to find a
flight 130939 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130939/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-examine 8 reboot fail REGR. vs. 128858
On Tue, Dec 04, 2018 at 04:41:34PM +, Robin Murphy wrote:
> I'd have been inclined to put the default check here, i.e.
>
> - return 0
> + return dma_addr == DMA_MAPPING_ERROR
>
> such that the callback retains full precedence and we don't have to deal
> with the non-trivial removals
When using the Xen debug console and printing the IOMMU intremap tables,
it prints everything in the IVRS range regardless if it has an intr
remap or not. Add some logic to cause an entry to only be printed if
the intr remap table isn't empty.
Signed-off-by: Brian Woods
---
CC: Paul Durrant
Things I've learned and improved while setting osstest standalone myself.
First two patches add support for dnsmasq (note: I don't have setup to check if
haven't broken dhcp3 in the process!). Other patches are mostly independent.
Marek Marczykowski-Górecki (7):
DhcpWatch: extract dhcp3 parsing
Otherwise it will match 169.254.0.0/16 route, which has always /16
netmask, instead of what really is used on the local network.
Signed-off-by: Marek Marczykowski-Górecki
---
ts-xen-install | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/ts-xen-install b/ts-xen-install
index
Things I've learned when setting it up myself.
Signed-off-by: Marek Marczykowski-Górecki
---
README | 29 +
1 file changed, 25 insertions(+), 4 deletions(-)
diff --git a/README b/README
index 4e4066a..a4520c8 100644
--- a/README
+++ b/README
@@ -305,6 +305,12 @@ To
dnsmasq use much simpler format - one lease by line with fields
separated with spaces. Add separate function to parse this format and
plug it info check_ip.
Signed-off-by: Marek Marczykowski-Górecki
---
Osstest/DhcpWatch/leases.pm | 40 +++---
README
with-lock-ex comes from a Debian-only, not installed by default
chiark-utils-bin package, while flock have equivalent functionality and
is part of standard util-linux package.
This is especially important for apt-get call under the lock
(TestSupport.pm:target_run_pkgmanager_install function),
Do not clone the whole history to save time, disk space and bandwidth.
This reduce (on my machine) Linux clone from over half an hour to few
minutes.
Signed-off-by: Marek Marczykowski-Górecki
---
This should be fine, unless this function is also used when preparing
for bisection. Is it?
---
Preparation for dnsmasq support. Keep generic code in check_ip, but
extract format-specific handling into separat function. No intentional
behaviour change (besides slightly different warning reporting).
Signed-off-by: Marek Marczykowski-Górecki
---
Osstest/DhcpWatch/leases.pm | 131
Package names are slightly different. Additionally some parts are
Debian-only.
Signed-off-by: Marek Marczykowski-Górecki
---
README | 14 ++
1 file changed, 14 insertions(+)
diff --git a/README b/README
index a4520c8..c883728 100644
--- a/README
+++ b/README
@@ -290,6 +290,7 @@
On Mon, Dec 03, 2018 at 04:18:21PM +, Andy Cooper wrote:
> The semantics of MSR_VIRT_SPEC_CTRL are that unknown bits are write-discard
> and read as zero. Only VIRT_SPEC_CTRL.SSBD is defined at the moment.
>
> To facilitate making this per-guest, the legacy SSBD state needs context
>
On 12/4/18 10:26 PM, Julien Grall wrote:
> With the recent changes, a P2M entry may be populated but may as not
> valid. In some situation, it would be useful to know whether the entry
I think you mean to say "may not be valid"?
> has been marked available to guest in order to perform a specific
GUEST_BUG_ON may be used in other files doing guest emulation.
Signed-off-by: Julien Grall
Acked-by: Stefano Stabellini
---
The patch was previously sent separately.
Changes in v2:
- Add Stefano's acked-by
---
xen/arch/arm/traps.c| 24
The LPAE format allows to store information in an entry even with the
valid bit unset. In a follow-up patch, we will take advantage of this
feature to re-purpose the valid bit for generating a translation fault
even if an entry contains valid information.
So we need a different way to know
On Mon, Dec 03, 2018 at 04:18:20PM +, Andy Cooper wrote:
> It is critical that MSR_AMD64_LS_CFG is never modified outside of this
> function, to avoid trampling on sibling settings.
>
> For now, pass in NULL from the boot paths and just set Xen's default. Later
> patches will plumb in guest
At the moment, the implementation of Set/Way operations will go through
all the entries of the guest P2M and flush them. However, this is very
expensive and may render unusable a guest OS using them.
For instance, Linux 32-bit will use Set/Way operations during secondary
CPU bring-up. As the
A follow-up patch will re-purpose the valid bit of LPAE entries to
generate fault even on entry containing valid information.
This means that when translating a guest VA to guest PA (e.g IPA) will
fail if the Stage-2 entries used have the valid bit unset. Because of
that, we need to fallback to
Currently a Stage-2 translation fault could happen:
1) MMIO emulation
2) Another pCPU was modifying the P2M using Break-Before-Make
3) Guest Physical address is not mapped
A follow-up patch will re-purpose the valid bit in an entry to generate
translation fault. This would be used to
A couple of places in the code will need to clear/set flags in HCR_EL2
for a given vCPU and then replicate into the hardware. Introduce
helpers and replace open-coded version.
Signed-off-by: Julien Grall
Reviewed-by: Stefano Stabellini
---
The patch was previously sent separately and reviewed
The function will be easier to re-use in a follow-up patch if you have
only the begin and end.
At the same time, rename the function to reflect the change in the
prototype.
Signed-off-by: Julien Grall
Reviewed-by: Stefano Stabellini
---
Changes in v2:
- Add Stefano's reviewed-by
This will make changes in a follow-up patch easier.
Signed-off-by: Julien Grall
---
Changes in v2:
- Patch added
---
xen/arch/arm/domctl.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/xen/arch/arm/domctl.c b/xen/arch/arm/domctl.c
index
Hi all,
This is version 2 of the series to implement set/way. For more details see
patch #16.
A branch with the code is available at:
https://xenbits.xen.org/git-http/people/julieng/xen-unstable.git
branch cacheflush/v2
Cheers,
Julien Grall (17):
xen/arm: Introduce helpers to clear/flags
p2m_cache_flush_range does not yet support preemption, this may be an
issue as cleaning the cache can take a long time. While the current
caller (XEN_DOMCTL_cacheflush) does not stricly require preemption, this
will be necessary for new caller in a follow-up patch.
The preemption implemented is
A follow-up patch will add support for preemption in p2m_cache_flush_range.
Because of the complexity for the 2 loops, it would be necessary to add
preemption in both of them.
This can be avoided by merging the 2 loops together and still keeping
the code fairly simple to read and extend.
A follow-up patch will require to emulate some accesses to system
registers trapped by HCR_EL2.TVM. When set, all NS EL1 writes to the
virtual memory control registers will be trapped to the hypervisor.
This patch adds the infrastructure to passthrough the access to the host
registers.
Note that
The function leave_hypervisor_tail is called before each return to the
guest vCPU. It has two main purposes:
1) Process physical CPU work (e.g rescheduling) if required
2) Prepare the physical CPU to run the guest vCPU
2) will always be done once we finished to process physical CPU work.
A follow-up patch will require to emulate some accesses to some
co-processors registers trapped by HCR_EL2.TVM. When set, all NS EL1 writes
to the virtual memory control registers will be trapped to the hypervisor.
This patch adds the infrastructure to passthrough the access to host
registers.
Currently, we only allow to flush cache on regions mapped as p2m_ram_{rw,ro}.
There are no real problem in cache flushing any RAM regions such as grants
and foreign mapping. Therefore, relax the check to allow flushing the
cache on any RAM region.
Signed-off-by: Julien Grall
Reviewed-by:
With the recent changes, a P2M entry may be populated but may as not
valid. In some situation, it would be useful to know whether the entry
has been marked available to guest in order to perform a specific
action. So extend p2m_get_entry to return the value of bit[0] (valid bit).
Signed-off-by:
Set/Way operations are used to perform maintenance on a given cache.
At the moment, Set/Way operations are not trapped and therefore a guest
OS will directly act on the local cache. However, a vCPU may migrate to
another pCPU in the middle of the processor. This will result to have
cache with
A lot of the headers are not necessary, so remove them. At the same
time, re-order them alphabetically.
Signed-off-by: Julien Grall
---
xen/arch/arm/p2m.c | 18 +-
1 file changed, 5 insertions(+), 13 deletions(-)
diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index
On Tue, 4 Dec 2018, Jan Beulich wrote:
> >>> 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.
>
On Tue, 4 Dec 2018, Wen Yang wrote:
> The problem is that we call this with a spin lock held.
> The call tree is:
> pvcalls_front_accept() holds bedata->socket_lock.
> -> create_active()
> -> __get_free_pages() uses GFP_KERNEL
>
> The create_active() function is only called from
On Tue, 4 Dec 2018, Julien Grall wrote:
> 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
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
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.
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]
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:
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
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)
> -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
>
>
>>> 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
>> >>
>>
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
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
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
> -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 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 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: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
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 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
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
>>> 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 Mon, Dec 03, 2018 at 04:18:18PM +, Andy Cooper wrote:
> Introduce a new synthetic LEGACY_SSBD feature and set it if we find
> VIRT_SPEC_CTRL offered by our hypervisor, or if we find a working bit in an
> LS_CFG register.
>
> Signed-off-by: Andrew Cooper
Reviewd-by: Brian Woods
--
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 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 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,
>> >
> -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 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 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);
>
> -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
>>> 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
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 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'
> -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
> -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
>>> 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 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
> -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 ;
>
> -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
>
>
>>> 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
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
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 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));
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
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 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
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
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/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
>>> 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
>>> 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
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
1 - 100 of 148 matches
Mail list logo
