> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Monday, December 21, 2015 9:23 PM
> To: Xu, Quan
> Cc: 'andrew.coop...@citrix.com' ;
> 'george.dun...@eu.citrix.com' ; Wu, Feng
> ; Nakajima, Jun ; Tian, Kevin
> ; 'xen-devel@lists.xen.org' ;
> 'k...@xen.org' ; '
Add a new function libxl_read_sysfs_file_contents to handle sysfs file
specially. It would be used in later pvusb work.
Signed-off-by: Chunyan Liu
---
Changes:
* remove unnecessary null pointer check after libxl__alloc and
libxl__realloc
tools/libxl/libxl_internal.h | 4 +++
tools/libxl/
Add code to support pvusb in domain config file. One could specify
usbctrl and usb in domain's configuration file and create domain,
then usb controllers will be created and usb device would be attached
to guest automatically.
One could specify usb controllers and usb devices in config file
like t
Add pvusb commands: usbctrl-attach, usbctrl-detach, usb-list,
usbdev-attach and usbdev-detach.
To attach a usb device to guest through pvusb, one could follow
following example:
#xl usbctrl-attach test_vm version=1 ports=8
#xl usb-list test_vm
will show the usb controllers and port usage unde
Signed-off-by: Chunyan Liu
Signed-off-by: Simon Cao
Reviewed-by: Wei Liu
---
tools/libxl/libxl.c | 5 ++---
tools/libxl/libxl_internal.h | 3 +++
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 00d9ec4..43d5709 100644
--- a
This patch series is to add pvusb toolstack work, supporting hot add|remove
USB device to|from guest and specify USB device in domain configuration file.
Changes to V11:
* remov unnecessary check in patch 2/5
V11:
http://lists.xen.org/archives/html/xen-devel/2015-12/msg01626.html
V10:
http://lis
Add pvusb APIs, including:
- attach/detach (create/destroy) virtual usb controller.
- attach/detach usb device
- list usb controller and usb devices
- some other helper functions
Signed-off-by: Chunyan Liu
Signed-off-by: Simon Cao
Signed-off-by: George Dunlap
Reviewed-by: George Dunlap
---
flight 66773 qemu-upstream-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/66773/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 63071
test-am
flight 66783 linux-mingo-tip-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/66783/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-pvops 5 kernel-build fail REGR. vs. 60684
build-amd6
The flask utilities only have dependencies on libxc so there's no
downside to always building it. Distros and projects based on Xen can
put these utilities into a different package and not install them for
everyone. Prior to this change FLASK_ENABLE needs to be a top level
variable however after th
flight 66772 qemu-upstream-4.4-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/66772/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xend 5 xen-build fail REGR. vs. 62702
test-am
On Mon, 2015-12-21 at 08:07 -0700, Jan Beulich wrote:
> > > > On 21.12.15 at 08:21, wrote:
> > @@ -4600,6 +4600,14 @@ void hvm_cpuid(unsigned int input, unsigned
> > int *eax, unsigned int *ebx,
> > /* Don't expose INVPCID to non-hap hvm. */
> > if ( (count == 0) && !hap_enabled(
flight 66754 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/66754/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check
fail never pass
test-amd64-amd64-qemuu-nested
flight 66752 qemu-upstream-4.5-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/66752/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 62414
test-am
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Monday, December 21, 2015 10:35 PM
> To: xen-devel
> Cc: Wu, Feng ; Tian, Kevin
> Subject: [PATCH 3/4] VT-d: unhide messages needed for diagnosing firmware
> issues
>
> Undue use of dprintk() lead to many messa
flight 66750 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/66750/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-freebsd10-i386 6 xen-bootfail REGR. vs. 59254
test-amd64-i386-xl-qe
With commit 8c45adec18e0 ("libxc: create unmapped initrd in domain
builder if supported") location of ramdisk may not be available to
HVMlite guests by the time alloc_magic_pages_hvm() is invoked if the
guest supports unmapped initrd.
Since the only operation related to allocating magic pages in t
Seeing as "All OSes providing PV backends are susceptible," doesn't this
include MiniOS for QEMU stubdom as well? Are there patches available for
mini-os/blkfront.c, mini-os/netfront.c, and mini-os/pcifront.c? I didn't
see anything for this.
Best,
Eric
On Thu, Dec 17, 2015 at 1:36 PM, Xen.org s
I am testing Fedora rawhide in a xen pv guest and I get the error
[9.809550] genirq: Flags mismatch irq 8. (hvc_console) vs.
(rtc0)
[9.809714] hvc_open: request_irq failed with rc -16.
during the boot and the hvc console doesn't respond when the boot
finishes. I have not
flight 66735 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/66735/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i3865 xen-build fail REGR. vs. 66415
build-i386-xsm
flight 66868 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/66868/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-xl 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 13
flight 66729 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/66729/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail
REGR. vs. 65543
test-amd64-i386-
flight 66698 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/66698/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-rumpuserxen-i386 10 guest-start fail REGR. vs. 63732
Regressions which are
On 12/21/2015 12:16 PM, Andrew Cooper wrote:
c/s 506db90 "x86/HVM: merge HVM and PVH hypercall tables" introduced a path
whereby 'okay' was used uninitialised, with broke compilation on CentOS 7.
Splitting the error handling like this is fragile and unnecessary. Drop the
okay variable entirely
branch xen-unstable
xenbranch xen-unstable
job build-i386-xsm
testid xen-build
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
*** Found and reproduced problem changeset ***
Bug is in tree: xen gi
>>> On 21.12.15 at 18:01, wrote:
> flight 66718 xen-4.4-testing real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/66718/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> build-amd64-prev 5 xen-build
c/s 506db90 "x86/HVM: merge HVM and PVH hypercall tables" introduced a path
whereby 'okay' was used uninitialised, with broke compilation on CentOS 7.
Splitting the error handling like this is fragile and unnecessary. Drop the
okay variable entirely and just use rc directly, substituting rc = -EI
flight 66842 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/66842/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-xl 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 13
flight 66718 xen-4.4-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/66718/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-prev 5 xen-build fail REGR. vs. 66458
build-i386-prev
>>> On 21.12.15 at 17:06, wrote:
> flight 6 xen-4.5-testing real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/6/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-amd64-i386-xl-qemuu-ovmf-amd64 9 debian-
flight 6 xen-4.5-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/6/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 66426
test-amd64-amd64-
>>> On 21.12.15 at 16:20, wrote:
> On 12/21/15 8:51 AM, Jan Beulich wrote:
> On 21.12.15 at 15:35, wrote:
>>> On 12/21/15 6:11 AM, Jan Beulich wrote:
>>> On 18.12.15 at 22:35, wrote:
> Since we now support changing Xen options with Kconfig, we should save
> the configuration that
>>> On 21.12.15 at 08:21, wrote:
> --- a/xen/arch/x86/mm/guest_walk.c
> +++ b/xen/arch/x86/mm/guest_walk.c
> @@ -90,6 +90,55 @@ static uint32_t set_ad_bits(void *guest_p, void *walk_p,
> int set_dirty)
> return 0;
> }
>
> +#if GUEST_PAGING_LEVELS >= CONFIG_PAGING_LEVELS
GUEST_PAGING_LEVE
xen/tools/get-fields.sh used echo -n which is not POSIX compatible and
breaks building with dash (shell). Change it to use printf %s which is
usable everywhere.
Signed-off-by: Alex Xu
---
xen/tools/get-fields.sh | 30 +++---
1 file changed, 15 insertions(+), 15 deletions(
flight 66740 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/66740/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm5 xen-build fail REGR. vs. 66433
build-amd64-xsm
On 12/21/15 8:51 AM, Jan Beulich wrote:
On 21.12.15 at 15:35, wrote:
>> On 12/21/15 6:11 AM, Jan Beulich wrote:
>> On 18.12.15 at 22:35, wrote:
Since we now support changing Xen options with Kconfig, we should save
the configuration that was used to build up Xen. This will save
On Mon, 21 Dec 2015, Jan Beulich wrote:
> Signed-off-by: Jan Beulich
Acked-by: Stefano Stabellini
> --- a/xen/arch/arm/platforms/brcm.c
> +++ b/xen/arch/arm/platforms/brcm.c
> @@ -162,7 +162,7 @@ static int brcm_cpu_power_on(int cpu)
>
> if ( timeout == 0 )
> {
> -dprintk(X
>On 21.12.2015 at 10:53pm, wrote:
> >>> On 21.12.15 at 15:31, wrote:
> >> On 21.12.2015 at 10:16pm, wrote:
> >> >>> On 21.12.15 at 15:08, wrote:
> >> >> On 21.12.2015 at 9:23pm, wrote:
> >> >> >>> On 21.12.15 at 14:08, wrote:
> >> >> >> On 21.12.2015 at 8:50pm, wrote:
> >> >> >> >>> On 21
>>> On 21.12.15 at 08:21, wrote:
> This patch adds xstate support for pkeys.
>
> Signed-off-by: Huaitong Han
> Reviewed-by: Andrew Cooper
> ---
> xen/include/asm-x86/xstate.h | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/xen/include/asm-x86/xstate.h b/xen/include
>>> On 21.12.15 at 08:21, wrote:
> @@ -4600,6 +4600,14 @@ void hvm_cpuid(unsigned int input, unsigned int *eax,
> unsigned int *ebx,
> /* Don't expose INVPCID to non-hap hvm. */
> if ( (count == 0) && !hap_enabled(d) )
> *ebx &= ~cpufeat_mask(X86_FEATURE_INVPCID);
>
>>> On 21.12.15 at 08:21, wrote:
> This patch adds pkeys support when setting CR4.
Btw there's little point in a commit message simply repeating the
title.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Add the PV block backend, the Xen mapcache, and hw/i386/xen to the list
of Xen related files maintained by me.
Signed-off-by: Stefano Stabellini
diff --git a/MAINTAINERS b/MAINTAINERS
index 55a0fd8..781e695 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -273,9 +273,12 @@ F: */xen*
F: hw/char/xen
>>> On 21.12.15 at 15:31, wrote:
>> On 21.12.2015 at 10:16pm, wrote:
>> >>> On 21.12.15 at 15:08, wrote:
>> >> On 21.12.2015 at 9:23pm, wrote:
>> >> >>> On 21.12.15 at 14:08, wrote:
>> >> >> On 21.12.2015 at 8:50pm, wrote:
>> >> >> >>> On 21.12.15 at 13:28, wrote:
>> >> >> > On 21.12.2015
On Mon, 21 Dec 2015, David Vrabel wrote:
> On 20/12/15 09:25, Michael S. Tsirkin wrote:
> >
> > I noticed that drivers/xen/xenbus/xenbus_comms.c uses
> > full memory barriers to communicate with the other side.
> > For example:
> >
> > /* Must write data /after/ reading the consum
>>> On 21.12.15 at 15:35, wrote:
> On 12/21/15 6:11 AM, Jan Beulich wrote:
> On 18.12.15 at 22:35, wrote:
>>> Since we now support changing Xen options with Kconfig, we should save
>>> the configuration that was used to build up Xen. This will save it in
>>> /boot alongside the installed xen.
>>> On 21.12.15 at 15:41, wrote:
> On 21/12/15 14:34, Jan Beulich wrote:
>> --- a/xen/arch/x86/io_apic.c
>> +++ b/xen/arch/x86/io_apic.c
>> @@ -2310,13 +2310,14 @@ int ioapic_guest_read(unsigned long phys
>> return 0;
>> }
>>
>> -#define WARN_BOGUS_WRITE(f, a...)
>>> On 15.12.15 at 03:05, wrote:
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -935,6 +935,9 @@ static void hvm_ioreq_server_free_rangesets(struct
> hvm_ioreq_server *s,
> rangeset_destroy(s->range[i]);
> }
>
> +static const char *io_range_name[ NR_IO_RANGE_TYPES
On 21/12/15 14:34, Jan Beulich wrote:
> --- a/xen/arch/x86/io_apic.c
> +++ b/xen/arch/x86/io_apic.c
> @@ -2310,13 +2310,14 @@ int ioapic_guest_read(unsigned long phys
> return 0;
> }
>
> -#define WARN_BOGUS_WRITE(f, a...) \
> -dprintk(XENLOG_INFO, "
>>> On 15.12.15 at 03:05, wrote:
> This patch refactors struct rangeset to base it on the red-black
> tree structure, instead of on the current doubly linked list. By
> now, ioreq leverages rangeset to keep track of the IO/memory
> resources to be emulated. Yet when number of ranges inside one
> i
Undue use of dprintk() lead to many messages useful in diagnosing
issues in the field now being hidden in non-debug (i.e. production)
builds. Re-surface them.
Signed-off-by: Jan Beulich
--- a/xen/drivers/passthrough/io.c
+++ b/xen/drivers/passthrough/io.c
@@ -543,10 +543,10 @@ int pt_irq_create_
On 12/21/15 6:11 AM, Jan Beulich wrote:
On 18.12.15 at 22:35, wrote:
>> Since we now support changing Xen options with Kconfig, we should save
>> the configuration that was used to build up Xen. This will save it in
>> /boot alongside the installed xen.gz and call it
>> xen-$(FULLVERSION).con
Undue use of dprintk() lead to many messages useful in diagnosing
issues in the field now being hidden in non-debug (i.e. production)
builds. Re-surface them, namely when init-time only and/or already
guarded by iommu_{verbose,debug} conditionals. Switch from using
iommu_verbose to iommu_debug in a
- a missing newline
- missing log levels (in Dom0-only messages)
- one dprintk() -> printk() conversion
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/acpi/power.c
+++ b/xen/arch/x86/acpi/power.c
@@ -268,7 +268,7 @@ int acpi_enter_sleep(struct xenpf_enter_
else if ( sleep->val_b &&
Signed-off-by: Jan Beulich
--- a/xen/arch/arm/platforms/brcm.c
+++ b/xen/arch/arm/platforms/brcm.c
@@ -162,7 +162,7 @@ static int brcm_cpu_power_on(int cpu)
if ( timeout == 0 )
{
-dprintk(XENLOG_ERR, "CPU%d power enable failed", cpu);
+dprintk(XENLOG_ERR, "CPU%d power
> On 21.12.2015 at 10:16pm, wrote:
> >>> On 21.12.15 at 15:08, wrote:
> >> On 21.12.2015 at 9:23pm, wrote:
> >> >>> On 21.12.15 at 14:08, wrote:
> >> >> On 21.12.2015 at 8:50pm, wrote:
> >> >> >>> On 21.12.15 at 13:28, wrote:
> >> >> > On 21.12.2015 at 7:47pm, wrote:
> >> >> >> >>> On 20.1
flight 66824 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/66824/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-xl 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 13
While auditing code for further similar issues, a couple of oddities
were found:
1: arm: add missing newlines to printk()s
2: x86: misc printk() adjustments
3: VT-d: unhide messages needed for diagnosing firmware issues
4: IOMMU: unhide messages useful for diagnostics
Signed-off-by: Jan Beulich
>>> On 21.12.15 at 15:08, wrote:
>> On 21.12.2015 at 9:23pm, wrote:
>> >>> On 21.12.15 at 14:08, wrote:
>> >> On 21.12.2015 at 8:50pm, wrote:
>> >> >>> On 21.12.15 at 13:28, wrote:
>> >> > On 21.12.2015 at 7:47pm, wrote:
>> >> >> >>> On 20.12.15 at 14:57, wrote:
>
> 1.
>> >> > IMO, When
>>> On 28.11.15 at 22:45, wrote:
> @@ -133,7 +134,7 @@ static int hvmemul_do_io(
> p = vio->io_req;
>
> /* Verify the emulation request has been correctly re-issued */
> -if ( (p.type != is_mmio ? IOREQ_TYPE_COPY : IOREQ_TYPE_PIO) ||
> +if ( (p.type != (is_mmio
> On 21.12.2015 at 9:23pm, wrote:
> >>> On 21.12.15 at 14:08, wrote:
> >> On 21.12.2015 at 8:50pm, wrote:
> >> >>> On 21.12.15 at 13:28, wrote:
> >> > On 21.12.2015 at 7:47pm, wrote:
> >> >> >>> On 20.12.15 at 14:57, wrote:
1.
> >> > IMO, When VT-d is enabled, but is not working correct. T
flight 66673 linux-3.16 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/66673/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-rumpuserxen-i386 10 guest-start fail REGR. vs. 64969
Tests which are failin
flight 66725 qemu-upstream-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/66725/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i3865 xen-build fail REGR. vs. 62112
build-a
> On 21.12.2015 at 9:23pm, wrote:
> >>> On 21.12.15 at 14:08, wrote:
> >> On 21.12.2015 at 8:50pm, wrote:
> >> >>> On 21.12.15 at 13:28, wrote:
> >> > On 21.12.2015 at 7:47pm, wrote:
> >> >> >>> On 20.12.15 at 14:57, wrote:
> >> >> > 2. If VT-d is bug, does the hardware_domain continue to wo
>>> On 21.12.15 at 14:08, wrote:
>> On 21.12.2015 at 8:50pm, wrote:
>> >>> On 21.12.15 at 13:28, wrote:
>> > On 21.12.2015 at 7:47pm, wrote:
>> >> >>> On 20.12.15 at 14:57, wrote:
>> >> > 2. If VT-d is bug, does the hardware_domain continue to work with
>> >> > PCIe Devices / DRAM well with D
> On 21.12.2015 at 8:50pm, wrote:
> >>> On 21.12.15 at 13:28, wrote:
> > On 21.12.2015 at 7:47pm, wrote:
> >> >>> On 20.12.15 at 14:57, wrote:
> >> > 2. If VT-d is bug, does the hardware_domain continue to work with
> >> > PCIe Devices / DRAM well with DMA remapping error?
> >> >I think it
>>> On 21.12.15 at 08:21, wrote:
First of all - please trim your Cc lists. I don't see, for example, why all
the tools maintainers needed to be Cc-ed on this patch.
> --- a/xen/arch/x86/cpu/common.c
> +++ b/xen/arch/x86/cpu/common.c
> @@ -22,6 +22,10 @@ boolean_param("xsave", use_xsave);
> bool
>>> On 21.12.15 at 13:40, wrote:
> On 21/12/15 12:11, Jan Beulich wrote:
> On 18.12.15 at 22:35, wrote:
>>> Since we now support changing Xen options with Kconfig, we should save
>>> the configuration that was used to build up Xen. This will save it in
>>> /boot alongside the installed xen.gz
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-rumpuserxen-i386
testid guest-start
Tree: linux git://kernel.ubuntu.com/ubuntu/linux.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://x
>>> On 21.12.15 at 13:28, wrote:
> On 21.12.2015 at 7:47pm, wrote:
>> >>> On 20.12.15 at 14:57, wrote:
>> > 2. If VT-d is bug, does the hardware_domain continue to work with PCIe
>> > Devices / DRAM well with DMA remapping error?
>> >I think it is no. furthermore, i think VMM can NOT run a n
On 21.12.2015 at 7:47pm, wrote:
> >>> On 20.12.15 at 14:57, wrote:
> > 2. If VT-d is bug, does the hardware_domain continue to work with
> > PCIe Devices / DRAM well with DMA remapping error?
> >I think it is no. furthermore, i think VMM can NOT run a normal
> > HVM domain without device-pa
On 21/12/15 12:11, Jan Beulich wrote:
On 18.12.15 at 22:35, wrote:
>> Since we now support changing Xen options with Kconfig, we should save
>> the configuration that was used to build up Xen. This will save it in
>> /boot alongside the installed xen.gz and call it
>> xen-$(FULLVERSION).confi
On 21.12.2015 at 7:47pm, wrote:
> >>> On 20.12.15 at 14:57, wrote:
> > 2. If VT-d is bug, does the hardware_domain continue to work with PCIe
> > Devices / DRAM well with DMA remapping error?
> >I think it is no. furthermore, i think VMM can NOT run a normal HVM
> > domain without device-pass
flight 66720 qemu-upstream-4.2-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/66720/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i3865 xen-build fail REGR. vs. 62044
build-a
>>> On 18.12.15 at 22:35, wrote:
> Since we now support changing Xen options with Kconfig, we should save
> the configuration that was used to build up Xen. This will save it in
> /boot alongside the installed xen.gz and call it
> xen-$(FULLVERSION).config
>
> Suggested-by: Ian Campbell
> Signed
>>> On 21.12.15 at 02:50, wrote:
> Refer to SDM 13.4.3. The value return by ecx[1] with cpuid
I think we've clarified before that SDM references should be by
section title, not section number.
> --- a/tools/libxc/xc_cpuid_x86.c
> +++ b/tools/libxc/xc_cpuid_x86.c
> @@ -285,6 +285,7 @@ static void
flight 38546 distros-debian-sid real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38546/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-amd64-sid-netboot-pygrub 9 debian-di-install fail like 38509
test-amd64-amd64-i3
On Sat, Dec 19, 2015 at 8:51 PM, Doug Goldstein wrote:
> All,
>
> Now I'll start off by saying that "no" is a perfectly acceptable answer
> to this suggestion. Basically I remember at the Xen Developer Summit a
> few people mentioned it being nice if people provided a git tree where
> their branch
>>> On 21.12.15 at 04:05, wrote:
> flight 66638 xen-4.3-testing real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/66638/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> build-amd64 5 xen-build
>>> On 20.12.15 at 13:25, wrote:
> flight 66583 xen-4.4-testing real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/66583/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> build-amd64-prev 5 xen-build
On Mon, Dec 21, 2015 at 10:47:49AM +, David Vrabel wrote:
> On 20/12/15 09:25, Michael S. Tsirkin wrote:
> >
> > I noticed that drivers/xen/xenbus/xenbus_comms.c uses
> > full memory barriers to communicate with the other side.
> > For example:
> >
> > /* Must write data /afte
>>> On 20.12.15 at 14:57, wrote:
> 2. If VT-d is bug, does the hardware_domain continue to work with PCIe
> Devices / DRAM well with DMA remapping error?
>I think it is no. furthermore, i think VMM can NOT run a normal HVM
> domain without device-passthrough.
In addition to what Andrew said
>>> On 18.12.15 at 21:46, wrote:
> --- a/xen/arch/x86/traps.c
> +++ b/xen/arch/x86/traps.c
> @@ -2614,23 +2614,15 @@ static int emulate_privileged_op(struct cpu_user_regs
> *regs)
> goto fail;
> break;
> case MSR_IA32_PERF_CTL:
> -if ( boot_cpu_d
>>> On 18.12.15 at 22:31, wrote:
> On 18/12/2015 20:46, Konrad Rzeszutek Wilk wrote:
>> Those two allow the OS pinned dom0 to change the T-state
>> (throttling) behind the Xen cpufreq code.
>>
>> The patch that introduced this: f78e2193b6409577314167ed9e077de7ac3e652f
>>
>> x86: Enable THERM_C
>>> On 20.12.15 at 17:41, wrote:
> xen/tools/get-fields.sh used echo -n which is not POSIX compatible and
> breaks building with dash (shell). Change it to use printf '%s' which
> is usable everywhere.
>
> Signed-off-by: Alex Xu
My remarks on v1 regarding quotation still apply.
Jan
_
>>> On 18.12.15 at 23:09, wrote:
> On 18/12/2015 21:49, Doug Goldstein wrote:
>> On 12/18/15 3:35 PM, Andrew Cooper wrote:
>>> On 18/12/2015 20:06, Doug Goldstein wrote:
Use the Kconfig generated CONFIG_COMPAT defines in the code base.
CC: Keir Fraser
CC: Jan Beulich
CC:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Xen Security Advisory XSA-169
x86: unintentional logging upon guest changing callback method
ISSUE DESCRIPTION
=
HYPERVISOR_hvm_op sub-op HVMOP_set_param's HVM_PARAM_CALLBACK_IRQ
operation intends to log the n
>>> On 18.12.15 at 18:33, wrote:
> On 12/18/2015 12:16 PM, Andrew Cooper wrote:
>> On 18/12/15 17:10, Jan Beulich wrote:
>> On 18.12.15 at 17:59, wrote:
I think all that is needed is xsm_mmuext_op(XSM_TARGET, d, pg_owner)
>>> Which, as Boris has just pointed out, is already there.
>> So
On Fri, 2015-12-18 at 12:23 +, George Dunlap wrote:
> This makes xl more useful in scripts.
>
> The strange thing about this is that the internal cd_insert function
> *already* returned something appropriate, and cd-eject was using it,
> but cd-insert wasn't.
>
> Also:
>
> * Rework cd_insert
On Fri, 2015-12-18 at 12:23 +, George Dunlap wrote:
> Also move the rc -> shell code translation into set_memory_max() to
> make the two functions consistent with each other, and with other
> similar examples in xl_cmdimpl.c
>
> Change a 'long long' to "int64_t" while we're at it.
>
> Signed-
On Fri, 2015-12-18 at 12:23 +, George Dunlap wrote:
> Add return codes for pci-detach, pci-attach, pci-asssignable-add, and
> pci-assignable-remove.
>
> Returning error codes makes it easier for shell scripts to tell if a
> command has failed or succeeded.
>
> NB this violates the CODING_STYL
On 20/12/15 09:25, Michael S. Tsirkin wrote:
>
> I noticed that drivers/xen/xenbus/xenbus_comms.c uses
> full memory barriers to communicate with the other side.
> For example:
>
> /* Must write data /after/ reading the consumer index. * */
> mb();
>
>
> -Original Message-
> From: Dario Faggioli [mailto:dario.faggi...@citrix.com]
> Sent: Monday, December 21, 2015 5:04 PM
> To: Wu, Feng ; xen-devel@lists.xen.org
> Cc: Keir Fraser ; Jan Beulich ; Andrew
> Cooper ; Tian, Kevin ;
> George Dunlap
> Subject: Re: [PATCH v10 6/7] vmx: VT-d pos
On Mon, 2015-12-21 at 06:43 +, Wu, Feng wrote:
> Ping...
>
Yep, it's on my list of things to do before leaving for the winter
holidays (which will be on Wednesday). I'll send in my comments soon.
Regards,
Dario
--
<> (Raistlin Majere)
-
flight 66648 xen-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/66648/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 65639
test-amd64-i386-x
94 matches
Mail list logo
