On Tue, Mar 19, 2019 at 08:50:05PM -0700, Munehisa Kamata wrote:
> On 3/18/2019 3:02 AM, Oleksandr Andrushchenko wrote:
> > +Amazon
> > pls see inline
> Hi Oleksandr,
>
> Let me add some comments as the original author of the series.
>
> >
> > On 3/14/19 9:00 PM, Julien Grall wrote:
> >> Hi,
>
On Wed, Mar 20, 2019 at 01:28:47PM -0400, Jason Andryuk wrote:
> On Fri, Mar 15, 2019 at 12:28 PM Andrew Cooper
> wrote:
> >
> > On 15/03/2019 09:17, Paul Durrant wrote:
> > >> -Original Message-
> > >> From: Jason Andryuk [mailto:jandr...@gmail.com]
> > >> Sent: 14 March 2019 18:16
> >
On Thu, Mar 21, 2019 at 08:26:20PM +, Andrew Cooper wrote:
> It turns out that this code was previously dead.
>
> c/s dcf41790 " x86/mmcfg/drhd: Move acpi_mmcfg_init() call before calling
> acpi_parse_dmar()" resulted in PCI segment 0 now having been initialised
> enough for
flight 133943 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133943/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-examine 4 memdisk-try-append fail REGR. vs. 133902
Tests which did not
Hi,
Looks like the new website doesn't list Xen 4.8.5:
https://xenproject.org/downloads/xen-project-archives/xen-project-4-8-series/
https://xenproject.org/xen-project-archives/
Both have 4.8.4 as the latest version.
--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because
flight 133941 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133941/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt-pair 22 guest-migrate/src_host/dst_host fail REGR. vs.
132889
This run is configured for baseline tests only.
flight 83765 xen-4.11-testing real [real]
http://osstest.xensource.com/osstest/logs/83765/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64
flight 133977 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133977/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm
Le mar. 19 mars 2019 19:40, Markus Armbruster a écrit :
> Markus Armbruster writes:
>
> > Dear board code maintainers,
> >
> > This is a (rather late) follow-up to the last QEMU summit. Minutes[*]:
> >
> > * Deprecating unmaintained features (devices, targets, backends) in QEMU
> >
> >
flight 133940 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133940/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt-pair 22 guest-migrate/src_host/dst_host fail REGR.
vs. 130965
Tests
On 21/03/2019 20:26, Andrew Cooper wrote:
> It turns out that this code was previously dead.
>
> c/s dcf41790 " x86/mmcfg/drhd: Move acpi_mmcfg_init() call before calling
> acpi_parse_dmar()" resulted in PCI segment 0 now having been initialised
> enough for acpi_parse_one_drhd() to not take the
It turns out that this code was previously dead.
c/s dcf41790 " x86/mmcfg/drhd: Move acpi_mmcfg_init() call before calling
acpi_parse_dmar()" resulted in PCI segment 0 now having been initialised
enough for acpi_parse_one_drhd() to not take the
/* Skip checking if segment is not accessible
Hi Andrii,
On 3/18/19 1:38 PM, Andrii Anisov wrote:
On 18.03.19 14:25, Julien Grall wrote:
As I already said multiple times before, please try to explain
everything in your first e-mail...
I know. I'm trying to provide enough info in the cover letter. But it
seems I do not succeed.
Putting
Hi,
On 3/20/19 7:01 AM, Jan Beulich wrote:
Julien Grall 03/20/19 12:19 AM >>>
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -1320,7 +1320,7 @@ static int __init debugtrace_init(void)
}
__initcall(debugtrace_init);
>
-#endif /* !NDEBUG */
+#endif /* !DEBUG_TRACE_DUMP
Hi,
On 3/20/19 7:08 AM, Jan Beulich wrote:
Julien Grall 03/20/19 12:21 AM >>>
Signed-off-by: Julien Grall
Acked-by: Jan Beulich
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -2003,7 +2003,7 @@ static int free_l4_table(struct page_info *page)
* 2. We never call _put_page_type() on a
(+ Stefano, Wei and Ian)
Hello,
Apologies for the late answer.
First of all, please avoid sending e-mail using HTML encoding. E-mail on
mailing should only be plain text.
On 3/20/19 9:28 AM, rambl...@sina.com wrote:
> On 18/03/2019 06:50, rambl...@sina.com wrote:
> > Hello,
> Hello,
On 21/03/2019 13:17, Andrew Cooper wrote:
> On 20/03/2019 20:22, Igor Druzhinin wrote:
>> Since commit dcf41790 ("x86/mmcfg/drhd: Move acpi_mmcfg_init() call
>> before calling acpi_parse_dmar()") PCI segment 0 is now known early
>> which made the sanity check on DRHD definition structure to work.
> -Original Message-
> From: Anthony PERARD [mailto:anthony.per...@citrix.com]
> Sent: 21 March 2019 17:23
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; Konrad Rzeszutek Wilk
>
> Subject: Re: [Xen-devel] [PATCH] public/io/blkif.h: make the comments on
> "sectors"
On 19/03/19 23:06, Boris Ostrovsky wrote:
On 3/19/19 4:02 PM, Jennifer Herbert wrote:
The ACPI tables doesn't always contain all IRQs for legacy devices
such as RTC. Since no PIC controller is visible for a PV linux guest,
under Xen, legacy_pic currently defaults to the null_legacy_pic -
Hi,
On 3/20/19 7:05 AM, Jan Beulich wrote:
Julien Grall 03/20/19 12:21 AM >>>
The function is unused and could potentially lead a to trigger the
BUG_ON() in p2m_change_type_one if misused as the p2m type is not
sanitized.
So remove it.
I don't think I agree - the entire file is effectively
Hi Andrew,
On 3/20/19 11:13 AM, Andrew Cooper wrote:
On 19/03/2019 23:20, Julien Grall wrote:
The function is unused and could potentially lead a to trigger the
BUG_ON() in p2m_change_type_one if misused as the p2m type is not
sanitized.
So remove it.
Signed-off-by: Julien Grall
Either
> > I think this is how the currents implementations are working:
> > media/disk size = "sectors" * "sector-size"
> > then, "sectors" and "sector-size" are never used again.
>
> Not true, unfortunately. At least the Windows frontends are (mis)coded to use
> sector numbers directly in
Boot Hangs at: HVM: HAP page sizes: 4kB, 2MB or Adding cpu [INSERT 1-7]
to runqueue 0
Log (preserved for 6 months at https://pastebin.com/BDPP7Pzk)
fs0:\efi\gentoo> man_xen.efiip startup.nsh, any other key to continue.
Xen 4.12.0-rc (c/s Mon Feb 25 13:06:22 2019 + git:f393b82fe5-dirty)
On Wed, Mar 20, 2019 at 08:22:03PM +, Igor Druzhinin wrote:
> Since commit dcf41790 ("x86/mmcfg/drhd: Move acpi_mmcfg_init() call
> before calling acpi_parse_dmar()") PCI segment 0 is now known early
> which made the sanity check on DRHD definition structure to work.
> This, in turn, caused a
HI Everyone
My name is diego. I'm very interesting in extend the XenOprof to ARM64 based
architectures, and also integrate some tools for hypervisor and application
profiling and performance evaluation.
I read the documentation for Oprofile a perf which is in the wiki page and I
noticed that
> -Original Message-
> From: Anthony PERARD [mailto:anthony.per...@citrix.com]
> Sent: 21 March 2019 15:24
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; Konrad Rzeszutek Wilk
>
> Subject: Re: [Xen-devel] [PATCH] public/io/blkif.h: make the comments on
> "sectors"
> -Original Message-
> From: Anthony PERARD [mailto:anthony.per...@citrix.com]
> Sent: 21 March 2019 15:00
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; qemu-bl...@nongnu.org;
> qemu-de...@nongnu.org; Stefan Hajnoczi
> ; Stefano Stabellini ; Kevin
> Wolf ; Max
> Reitz
>
flight 133939 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133939/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-arndale 5 host-ping-check-native fail REGR. vs. 133909
On Thu, Mar 21, 2019 at 12:24:46PM +, Sergey Dyasli wrote:
>Hi Chao,
>
>Updating microcode in parallel by default should be fine, but I think
>there are no guarantees that a parallel application will be fine for
>all future microcodes. To retain the ability to update microcode on cores
flight 83763 distros-debian-wheezy real [real]
http://osstest.xensource.com/osstest/logs/83763/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvopsbroken
build-i386
flight 133944 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133944/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
freebsd 4a9d286decd81333b85f908e650cd4e81adaa93e
baseline version:
freebsd
On 21/03/2019 14:17, Andrew Cooper wrote:
> On 20/03/2019 20:22, Igor Druzhinin wrote:
>> Since commit dcf41790 ("x86/mmcfg/drhd: Move acpi_mmcfg_init() call
>> before calling acpi_parse_dmar()") PCI segment 0 is now known early
>> which made the sanity check on DRHD definition structure to work.
On 20/03/2019 20:22, Igor Druzhinin wrote:
> Since commit dcf41790 ("x86/mmcfg/drhd: Move acpi_mmcfg_init() call
> before calling acpi_parse_dmar()") PCI segment 0 is now known early
> which made the sanity check on DRHD definition structure to work.
> This, in turn, caused a regression on some
This run is configured for baseline tests only.
flight 83762 ovmf real [real]
http://osstest.xensource.com/osstest/logs/83762/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm
> -Original Message-
> From: Anthony PERARD [mailto:anthony.per...@citrix.com]
> Sent: 21 March 2019 12:22
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; Konrad Rzeszutek Wilk
>
> Subject: Re: [Xen-devel] [PATCH] public/io/blkif.h: make the comments on
> "sectors"
Hi Chao,
Updating microcode in parallel by default should be fine, but I think
there are no guarantees that a parallel application will be fine for
all future microcodes. To retain the ability to update microcode on cores
sequentially and give some choice to a user, I developed the below patch.
On Wed, Mar 20, 2019 at 12:52:28PM +, Paul Durrant wrote:
> Currently the comment at line #267 claims that the value should be
> expressed in number logical sectors, whereas the comment at line #613
> states that the value should be expressed strictly in units of 512 bytes.
>
> Signed-off-by:
This is the next piece of CPUID work, and associated cleanup for the existing
logic.
Andrew Cooper (4):
libx86: Introduce x86_cpuid_lookup_vendor()
x86/cpuid: Drop get_cpu_vendor() completely
tools/libxc: Use x86_cpuid_lookup_vendor() rather than opencoding the logic
libx86: Recalculate
get_cpu_vendor() tries to do a number of things, and ends up doing none of
them well.
For calculating the vendor itself, use x86_cpuid_lookup_vendor() which is
implemented in a far more efficient manner than looping over cpu_devs[].
For setting up this_cpu, set it up once on the BSP only, rather
This doesn't address any of the assumptions that "anything which isn't AMD is
Intel". This logic is expected to be replaced wholesale with libx86 in the
longterm.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
CC: Sergey Dyasli
---
Also introduce constants for the vendor strings in CPUID leaf 0.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
CC: Sergey Dyasli
---
tools/tests/cpu-policy/test-cpu-policy.c | 37
xen/include/asm-x86/x86-vendors.h|
When filling a policy, either from CPUID or an incomming leaf stream,
recalculate the synthesised vendor value. All callers are expected to want
this behaviour.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
CC: Sergey Dyasli
---
xen/arch/x86/cpuid.c
> -Original Message-
> From: Anthony PERARD [mailto:anthony.per...@citrix.com]
> Sent: 21 March 2019 11:42
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; qemu-bl...@nongnu.org;
> qemu-de...@nongnu.org; Stefano Stabellini
> ; Kevin Wolf ; Max Reitz
>
> Subject: Re: [PATCH]
On Wed, Mar 20, 2019 at 02:28:25PM +, Paul Durrant wrote:
> ...and properly enable it when synthesizing a drive.
>
> The Xen toolstack sets 'discard-enable' to '1' in xenstore when it wants
> to enable discard on a specified image. The code in
> xen_block_driver_create() correctly parses this
flight 133934 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133934/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemut-rhel6hvm-amd 12 guest-start/redhat.repeat fail REGR. vs.
133580
On 11/03/2019 07:57, Chao Gao wrote:
> Updating microcode is less error prone when caches have been flushed and
> depending on what exactly the microcode is updating. For example, some
> of the issues around certain Broadwell parts can be addressed by doing a
> full cache flush.
>
> [linux
Hi,
On 03/20/2019 09:08 PM, Gustavo A. R. Silva wrote:
> Hi all,
>
> Friendly ping:
>
> Who can take this?
I'll take this for v5.2.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics
> Thanks
> --
> Gustavo
>
> On 2/28/19 5:51 AM, Oleksandr
flight 133936 xen-4.11-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133936/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install
fail never pass
Hi,
On 3/20/19 7:37 PM, Volodymyr Babchuk wrote:
Julien Grall writes:
Anyway, you should explain how you decide the placement of each
hypercall_preempt_check(). For instance, if the lists are quite big,
then you may want add a preempt check in the loop.
I see your point there. Check in the
On 3/21/19 7:20 AM, Amit Tomer wrote:
Hi,
Hi,
Apart from this and the unneeded addition to early-printk.txt (which
Julien mentioned already) this looks now correct to me.
I was wondering, if it's a good idea to have
"CONFIG_EARLY_PRINTK=meson,0xc81004c0"
documented in Rules.mk.
It would
Signed-off-by: Amit Singh Tomar
---
TODO:
* Capture XEN boot info on WIKI.
Changes since v1:
* Fixed coding style issue.
* Undone changes in early-printk.txt.
Changes since RFC:
* Replaced LDRH with LDR, with this there
is no scattered output on
The meson-uart.c is an ARM specific UART driver for the Amlogic MESON
SoC family.
Signed-off-by: Amit Singh Tomar
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index ba7527c..aff7f81 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -182,6 +182,7 @@
This patch adds driver for UART controller present on Amlogic Meson
SoCs and it has been tested on Nanopi K2 board based on S905 SoC.
Controller registers defination is taken from Linux 4.20.
https://github.com/torvalds/linux/blob/v4.20-rc1/drivers/tty/serial/meson_uart.c
Signed-off-by: Amit
Hi,
> Apart from this and the unneeded addition to early-printk.txt (which
> Julien mentioned already) this looks now correct to me.
I was wondering, if it's a good idea to have
"CONFIG_EARLY_PRINTK=meson,0xc81004c0"
documented in Rules.mk.
It would give fair idea to someone who is new to Xen,
flight 133938 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133938/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf fbdfef35cb82b3e0beed2ceb0243ef129d2e55ce
baseline version:
ovmf
55 matches
Mail list logo
