On Tue, Jun 02, 2015 at 07:57:55AM +0100, Jan Beulich wrote:
> >>> On 02.06.15 at 08:35, wrote:
> > On Fri, May 29, 2015 at 09:52:03AM +0100, Jan Beulich wrote:
> >> >>> On 29.05.15 at 10:28, wrote:
> >> > On Fri, May 29, 2015 at 09:01:53AM +0100, Jan Beulich wrote:
> >> >> >>> On 29.05.15 at 04:
All,
I am pretty new to xen . I am trying to boot DOMU with qemu qcow AARCH64
Ubuntu 15.04 disk on Xen but I am getting the errors which link to
"/usr/local/lib/xen/bin/qemu-system-i386".
Since I am working on aarch64 system the
/usr/local/lib/xen/bin/qemu-system-i386 bin might not be present or m
flight 57731 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/57731/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-debianhvm-amd64 6 xen-boot fail REGR. vs. 57516
test-armhf-armhf-xl-xs
On 02.06.2015 09:40, Sanjeev Pandita wrote:
> All,
>
> I am pretty new to xen . I am trying to boot DOMU with qemu qcow AARCH64
> Ubuntu 15.04 disk on Xen but I am getting the errors which link to
> "/usr/local/lib/xen/bin/qemu-system-i386".
> Since I am working on aarch64 system the
> /usr/local/
On Mon, 2015-06-01 at 15:57 -0700, Manish Jaggi wrote:
> > Anyway, the general shape of this plan seems plausible enough.
> Could you modify the http://xenbits.xen.org/people/ianc/vits/draftC.html(5
> vITS to pITS mapping) based on this approach
I'm updating things as I go and feed back will be
To do this, we create a new list that holds, for each
vcpu, the time least into the future that it may need to be
rescheduled. The scheduler chooses the lowest time off of this
list and waits until the specified time instead of running every
1 ms as it did before.
Signed-off-by: Dagaen Golomb
Sig
On Mon, 2015-06-01 at 14:20 -0700, Roy Franz wrote:
> On Mon, Jun 1, 2015 at 4:24 AM, Ian Campbell wrote:
> > On Mon, 2015-06-01 at 12:10 +0100, Jan Beulich wrote:
> >> >>> On 01.06.15 at 12:17, wrote:
> >> > If calling ExitBootServices() fails, the required memory map size may
> >> > have increa
On 02/06/15 03:27, osstest service user wrote:
> flight 57712 xen-unstable real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/57712/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-armhf-armhf-xl-cubietruck 15 guest
>>> On 02.06.15 at 19:41, wrote:
> @@ -1074,6 +1075,9 @@ void ept_sync_domain(struct p2m_domain *p2m)
> if ( !paging_mode_hap(d) || !d->vcpu || !d->vcpu[0] )
> return;
>
> +if ( nestedhvm_enabled(d) )
> +p2m_flush_nestedp2m(d);
> +
> ASSERT(local_irq_is_enabled());
If the host EPT entry is changed, the nested EPT should be updated.
The current code does not do this, and it's wrong.
Reported-by: Tim Deegan
Signed-off-by: Liang Li
Signed-off-by: Yang Zhang
---
xen/arch/x86/mm/p2m-ept.c | 4
1 file changed, 4 insertions(+)
diff --git a/xen/arch/x86/mm
From: Wen Congyang
For PVHVM, the hypercall return code is 0, and it can be resumed
in a new domain context.
we suspend PVHVM and resume it is like this:
1. suspend it via evtchn
2. modifty the return code to 1
3. the guest know that the suspend is cancelled, we will use fast path
to resume it
From: Wen Congyang
In colo mode, slave needs to send data to master, but the io_fd
only can be written in master, and only can be read in slave.
Save recv_fd in domain_suspend_state, and send_fd in
domain_create_state.
Signed-off-by: Wen Congyang
Signed-off-by: Yang Hongyang
---
tools/libxl/l
Secondary vm is running in colo mode, we need to send
secondary vm's dirty page information to master at checkpoint,
so we have to enable qemu logdirty on secondary.
libxl__domain_suspend_common_switch_qemu_logdirty() is to enable
qemu logdirty. But it uses domain_save_state, and calls
libxl__xc_d
Currently, libxl__domain_unpause() only supports
qemu-xen-traditional. Update it to support qemu-xen.
Signed-off-by: Wen Congyang
Signed-off-by: Yang Hongyang
---
tools/libxl/libxl.c | 42 +-
1 file changed, 33 insertions(+), 9 deletions(-)
diff --git a/
From: Wen Congyang
The guest is paused after libxl_domain_create_restore().
Secondary vm is running in colo mode. So we need to unpause
the guest. The current API libxl_domain_unpause() is
not an internal API. Introduce a new API to support it.
No functional change.
Signed-off-by: Wen Congyang
This patchset is Prerequisite for COLO feature. For what COLO is, refer
to http://wiki.xen.org/wiki/COLO_-_Coarse_Grain_Lock_Stepping
This patchset is based on:
[PATCH v1 0/5] Misc cleanups for libxl
http://lists.xenproject.org/archives/html/xen-devel/2015-05/msg02591.html
and is taken from prev
When we are under COLO, we will send dirty page bitmap info from
secondary to primary at every checkpoint. So we need to get/test
the dirty page bitmap. We just expose xc_bitops.h for libxl use.
NOTE:
Need to make clean and rerun configure to get it compiled.
Signed-off-by: Yang Hongyang
---
Checkpoint device is an abstract layer to do checkpoint.
COLO can also use it to do checkpoint. But there are
still some codes in checkpoint device which touch remus:
1. remus_ops: we use remus ops directly in checkpoint
device. Store it in checkpoint device state.
2. concrete layer's private me
Secondary vm is running in colo mode. So we will do
the following things again and again:
1. suspend both primay vm and secondary vm
2. sync the state
3. resume both primary vm and secondary vm
We will send qemu's state each time in step2, and
slave's qemu should read it each time before resuming
s
ioreq page contains evtchn which will be set when we resume the
secondary vm the first time. The hypervisor will check if the
evtchn is corrupted, so we cannot zero the ioreq page more
than one time.
The ioreq->state is always STATE_IOREQ_NONE after the vm is
suspended, so it is OK if we only zero
This is just tidying up after the previous automatic renaming.
Signed-off-by: Yang Hongyang
Signed-off-by: Wen Congyang
---
tools/libxl/libxl_checkpoint_device.c | 21 +++--
tools/libxl/libxl_internal.h | 19 +++
tools/libxl/libxl_remus.c |
From: Wen Congyang
Currently, all callbacks return an integer value or void. We cannot
return some data to xc via callback. Update libxl_save_msgs_gen.pl
to support this case.
Signed-off-by: Wen Congyang
---
tools/libxl/libxl_internal.h | 3 ++
tools/libxl/libxl_save_callout.c | 31
This patch is auto generated by the following commands:
1. git mv tools/libxl/libxl_remus_device.c
tools/libxl/libxl_checkpoint_device.c
2. perl -pi -e 's/libxl_remus_device/libxl_checkpoint_device/g'
tools/libxl/Makefile
3. perl -pi -e 's/\blibxl__remus_devices/libxl__checkpoint_devices/g'
t
On 06/02/2015 05:26 PM, Yang Hongyang wrote:
> Secondary vm is running in colo mode. So we will do
> the following things again and again:
> 1. suspend both primay vm and secondary vm
> 2. sync the state
> 3. resume both primary vm and secondary vm
> We will send qemu's state each time in step2, an
After the first call to ExitBootServices(), avoid calling any boot
services by setting setting efi_bs to NULL and halting in blexit().
Signed-off-by: Ross Lagerwall
---
* Separated halt into an arch hook.
* Applies on top of the first patch from v3.
* Tested on x86, not sure if the ARM version i
On 06/02/2015 05:38 PM, Wen Congyang wrote:
On 06/02/2015 05:26 PM, Yang Hongyang wrote:
[...]
+int libxl__qmp_restore(libxl__gc *gc, int domid, const char *state_file)
+{
+libxl__json_object *args = NULL;
+
+qmp_parameters_add_string(gc, &args, "filename", state_file);
+
+return
On Mon, 2015-06-01 at 16:29 +0100, Julien Grall wrote:
> On 01/06/15 14:12, Ian Campbell wrote:
> > On Fri, 2015-05-29 at 14:40 +0100, Julien Grall wrote:
> >> Hi Ian,
>
> Hi Ian,
>
> >> NIT: You used my Linaro email which I think is de-activated now :).
> >
> > I keep finding new address books
Hi Eric
Sorry for coming late to the discussion.
On Thu, Apr 16, 2015 at 05:42:16AM -0700, Eric Dumazet wrote:
> On Thu, 2015-04-16 at 11:01 +0100, George Dunlap wrote:
>
> > He suggested that after he'd been prodded by 4 more e-mails in which two
> > of us guessed what he was trying to get at.
On 01/06/15 18:55, Konrad Rzeszutek Wilk wrote:
> On Mon, Jun 01, 2015 at 05:03:14PM +0100, Malcolm Crossley wrote:
>> On 01/06/15 16:43, Ross Lagerwall wrote:
>>> On 06/01/2015 04:26 PM, Konrad Rzeszutek Wilk wrote:
On Fri, May 29, 2015 at 08:59:45AM +0100, Ross Lagerwall wrote:
> When do
On 02/06/15 10:26, Yang Hongyang wrote:
> When we are under COLO, we will send dirty page bitmap info from
> secondary to primary at every checkpoint. So we need to get/test
> the dirty page bitmap. We just expose xc_bitops.h for libxl use.
>
> NOTE:
> Need to make clean and rerun configure to ge
On 02/06/15 10:26, Yang Hongyang wrote:
> ioreq page contains evtchn which will be set when we resume the
> secondary vm the first time. The hypervisor will check if the
> evtchn is corrupted, so we cannot zero the ioreq page more
> than one time.
>
> The ioreq->state is always STATE_IOREQ_NONE aft
>>> On 29.05.15 at 18:32, wrote:
> On Wed, 2015-05-27 at 17:04 +0100, Ian Campbell wrote:
>> Looking at the netback side though it seems like netback_remove is
>> switching to state=Closed _before_ it calls kobject_uevent(...,
>> KOBJ_OFFLINE) and it is this which generates the call to netback_uev
On Tue, 2 Jun 2015, Stefan Bader wrote:
> On 02.06.2015 09:40, Sanjeev Pandita wrote:
> > All,
> >
> > I am pretty new to xen . I am trying to boot DOMU with qemu qcow AARCH64
> > Ubuntu 15.04 disk on Xen but I am getting the errors which link to
> > "/usr/local/lib/xen/bin/qemu-system-i386".
> >
On Tue, 2 Jun 2015, Stefano Stabellini wrote:
> On Tue, 2 Jun 2015, Stefan Bader wrote:
> > On 02.06.2015 09:40, Sanjeev Pandita wrote:
> > > All,
> > >
> > > I am pretty new to xen . I am trying to boot DOMU with qemu qcow AARCH64
> > > Ubuntu 15.04 disk on Xen but I am getting the errors which l
Hi Ian,
On 01/06/15 14:36, Ian Campbell wrote:
On Fri, 2015-05-29 at 15:06 +0100, Julien Grall wrote:
Hi Vijay,
On 27/05/15 17:44, Vijay Kilari wrote:
## Command Translation
Of the existing GICv3 ITS commands, `MAPC`, `MAPD`, `MAPVI`/`MAPI` are
potentially time consuming commands as these co
On 02.06.2015 12:35, Stefano Stabellini wrote:
> On Tue, 2 Jun 2015, Stefano Stabellini wrote:
>> On Tue, 2 Jun 2015, Stefan Bader wrote:
>>> On 02.06.2015 09:40, Sanjeev Pandita wrote:
All,
I am pretty new to xen . I am trying to boot DOMU with qemu qcow AARCH64
Ubuntu 15.04 di
On 06/02/2015 06:16 PM, Andrew Cooper wrote:
> On 02/06/15 10:26, Yang Hongyang wrote:
>> ioreq page contains evtchn which will be set when we resume the
>> secondary vm the first time. The hypervisor will check if the
>> evtchn is corrupted, so we cannot zero the ioreq page more
>> than one time.
On Tue, 2015-06-02 at 11:46 +0100, Julien Grall wrote:
> Hi Ian,
>
> On 01/06/15 14:36, Ian Campbell wrote:
> > On Fri, 2015-05-29 at 15:06 +0100, Julien Grall wrote:
> >> Hi Vijay,
> >>
> >> On 27/05/15 17:44, Vijay Kilari wrote:
> ## Command Translation
>
> Of the existing GICv3 I
On Tue, 2 Jun 2015, Stefan Bader wrote:
> On 02.06.2015 12:35, Stefano Stabellini wrote:
> > On Tue, 2 Jun 2015, Stefano Stabellini wrote:
> >> On Tue, 2 Jun 2015, Stefan Bader wrote:
> >>> On 02.06.2015 09:40, Sanjeev Pandita wrote:
> All,
>
> I am pretty new to xen . I am trying to
Hi,
-Original Message-
From: Stefan Bader [mailto:stefan.ba...@canonical.com]
Sent: Tuesday, June 02, 2015 1:52 PM
To: Sanjeev Pandita; xen-devel@lists.xen.org
Cc: ian.campb...@citrix.com; Pranavkumar Sawargaonkar;
stefano.stabell...@eu.citrix.com
Subject: Re: [Xen-devel] ARM64: XEN Domu n
On 02.06.2015 14:09, Sanjeev Pandita wrote:
> Hi,
>
> -Original Message-
> From: Stefan Bader [mailto:stefan.ba...@canonical.com]
> Sent: Tuesday, June 02, 2015 1:52 PM
> To: Sanjeev Pandita; xen-devel@lists.xen.org
> Cc: ian.campb...@citrix.com; Pranavkumar Sawargaonkar;
> stefano.stabell
An MTRR record is processed for each vCPU during hvm_load. Each MTRR
record sets several mtrrs, each of which flushes the cache on all pCPUs.
This can take some time and trip the watchdog for HVM guests with many
CPUs.
To fix this, introduce a flag which prevents flushing the cache on x86
while lo
On 05/26/2015 01:09 AM, Chong Li wrote:
> Add libxl_vcpu_sched_params_get/set and sched_rtds_vcpu_get/set functions to
> support
> per-VCPU settings for RTDS scheduler.
>
> Add a new data structure (libxl_vcpu_sched_params) to help per-VCPU settings.
>
> Signed-off-by: Chong Li
> Signed-off-by:
On 02/06/15 13:47, Ross Lagerwall wrote:
> An MTRR record is processed for each vCPU during hvm_load. Each MTRR
> record sets several mtrrs, each of which flushes the cache on all pCPUs.
> This can take some time and trip the watchdog for HVM guests with many
> CPUs.
>
> To fix this, introduce a fl
flight 57737 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/57737/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-multivcpu 17 leak-check/check fail REGR. vs. 56831
Regressions which a
>>> On 02.06.15 at 14:47, wrote:
> +void arch_hvm_load_post(struct domain *d)
> +{
> +/* Re-enable cache flushes and flush the cache. */
> +this_cpu(memory_type_changed_ignore) = 0;
> +memory_type_changed(d);
> +}
Does this really need to be done unconditionally? I.e. couldn't this be
On 29/05/15 09:31, Jan Beulich wrote:
On 28.05.15 at 18:09, wrote:
>> On 28/05/15 15:55, Jan Beulich wrote:
>> On 26.05.15 at 20:00, wrote:
@@ -254,23 +254,23 @@ double_gt_lock(struct grant_table *lgt, struct
grant_table *rgt)
{
if ( lgt < rgt )
{
>>>
binutils 2.22 changed ld default from --copy-dt-needed-entries
to -no-copy-dt-needed-entries. This revealed that some objects
are linked implicitly with libtinfo and newer ld fails to build
relevant executables.
Below is short explanation why we should not do that...
http://fedoraproject.org/wiki
>>> On 02.06.15 at 15:22, wrote:
> On 29/05/15 09:31, Jan Beulich wrote:
> On 28.05.15 at 18:09, wrote:
>>> On 28/05/15 15:55, Jan Beulich wrote:
>>> On 26.05.15 at 20:00, wrote:
> @@ -837,12 +838,22 @@ __gnttab_map_grant_ref(
>
> TRACE_1D(TRC_MEM_PAGE_GRANT_MAP, op->d
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Xen Security Advisory CVE-2015-4105 / XSA-130
version 2
Guest triggerable qemu MSI-X pass-through error messages
UPDATES IN VERSION 2
Public release.
CVE assigned.
ISSUE DESCR
While investigating a separate issue on Broadwell hardware, we encountered a
cascade crash, with 3 indepent issues. For anyone interested, the full
backtrace was:
(XEN) Xen SMAP violation
(XEN) [ Xen-4.5.0-xs101665-d x86_64 debug=y Not tainted ]
(XEN) CPU:15
(XEN) RIP:e008:[] m
'n % BYTES_PER_LONG' is at most 7, and doesn't need a 64bit register mov.
Signed-off-by: Andrew Cooper
CC: Jan Beulich
---
Admittedly very trivial, but no need to be wasteful
---
xen/arch/x86/string.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/arch/x86/string.c
__stop_this_cpu() may reset the LAPIC mode back from x2apic to xapic, but will
leave x2apic_enabled alone. This may cause disconnect_bsp_APIC() in
disable_IO_APIC() to suffer a #GP fault.
Disabling the LAPIC can safely be deferred to being the last action.
Signed-off-by: Andrew Cooper
CC: Jan B
Experimentally, this can result in memory allocation, and in particular a
failed assertion that interrupts are enabled when performing a TLB flush.
(XEN) Assertion 'local_irq_is_enabled()' failed at smp.c:223
(XEN) [] flush_area_mask+0x7/0x134
(XEN) [] alloc_domheap_pages+0xa9/0x12a
(XE
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Xen Security Advisory CVE-2015-4106 / XSA-131
version 3
Unmediated PCI register access in qemu
UPDATES IN VERSION 3
Public release.
CVE assigned.
ISSUE DESCRIPTION
Using gdbsx on Broadwell systems suffers a SMAP violation because
dbg_rw_guest_mem() uses memcpy() with a userspace pointer.
The functions dbg_rw_mem() and dbg_rw_guest_mem() have been updated to pass
'void * __user' pointers which indicates their nature clearly.
Signed-off-by: Andrew Cooper
CC:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Xen Security Advisory CVE-2015-4104 / XSA-129
version 2
PCI MSI mask bits inadvertently exposed to guests
UPDATES IN VERSION 2
Public release.
CVE assigned.
ISSUE DESCRIPTI
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Xen Security Advisory CVE-2015-4103 / XSA-128
version 2
Potential unintended writes to host MSI message data field via qemu
UPDATES IN VERSION 2
Public release.
CVE assigned.
ISSUE
Previous discussion at [0].
For the benefit of discussion, we refer to max_memkb inside hypervisor
as hv_max_memkb (name subject to improvement). That's the maximum number
of memory a domain can use.
Libxl doesn't know hv_max_memkb for a domain needs prior to QEMU start-up
because of optional ROM
I fat-fingered Andrew's email address. Really CC him this time.
On Tue, Jun 02, 2015 at 03:05:07PM +0100, Wei Liu wrote:
> Previous discussion at [0].
>
> For the benefit of discussion, we refer to max_memkb inside hypervisor
> as hv_max_memkb (name subject to improvement). That's the maximum num
On Tue, Jun 2, 2015 at 7:53 AM, George Dunlap
wrote:
> On 05/26/2015 01:09 AM, Chong Li wrote:
>> Add libxl_vcpu_sched_params_get/set and sched_rtds_vcpu_get/set functions to
>> support
>> per-VCPU settings for RTDS scheduler.
>>
>> Add a new data structure (libxl_vcpu_sched_params) to help per-V
On Tue, 2 Jun 2015, Sanjeev Pandita wrote:
> From: Stefan Bader [mailto:stefan.ba...@canonical.com]
> Sent: Tuesday, June 02, 2015 1:52 PM
> To: Sanjeev Pandita; xen-devel@lists.xen.org
> Cc: ian.campb...@citrix.com; Pranavkumar Sawargaonkar;
> stefano.stabell...@eu.citrix.com
> Subject: Re: [Xen-d
On Tue, Jun 02, 2015 at 11:06:26AM +0100, Malcolm Crossley wrote:
> On 01/06/15 18:55, Konrad Rzeszutek Wilk wrote:
> > On Mon, Jun 01, 2015 at 05:03:14PM +0100, Malcolm Crossley wrote:
> >> On 01/06/15 16:43, Ross Lagerwall wrote:
> >>> On 06/01/2015 04:26 PM, Konrad Rzeszutek Wilk wrote:
> O
On Wed, 2015-05-20 at 18:01 +0800, Yang Hongyang wrote:
> @@ -1762,16 +1762,18 @@ static void libxl__domain_suspend_callback(void *data)
> {
> libxl__save_helper_state *shs = data;
> libxl__egc *egc = shs->egc;
> -libxl__domain_suspend_state *dss = CONTAINER_OF(shs, *dss, shs);
> +
On Wed, 2015-05-20 at 18:01 +0800, Yang Hongyang wrote:
> move domain suspend codes into a separate file libxl_dom_suspend.c
Just "code".
> Signed-off-by: Yang Hongyang
Acked-by: Ian Campbell
___
Xen-devel mailing list
Xen-devel@lists.xen.org
htt
On Wed, 2015-05-20 at 18:01 +0800, Yang Hongyang wrote:
> diff --git a/tools/libxl/libxl_internal.h
> b/tools/libxl/libxl_internal.h
> index f86fc89..b2eeb89 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -3191,6 +3191,12 @@ _hidden void
> libxl__domain_save_d
On Wed, 2015-05-20 at 18:01 +0800, Yang Hongyang wrote:
> move remus codes into libxl_remus.c
"code"
Apart from dropping some "static" and adding some prototypes to the
header this is purely motion, correct? (I assume this about the last one
too).
> diff --git a/tools/libxl/libxl_internal.h b/too
On Wed, 2015-05-20 at 18:01 +0800, Yang Hongyang wrote:
> move toolstack code into libxl_toolstack.c
It's not clear to me what "toolstack code" is here, the whole of libxl
and xl is "toolstack code".
Is the code being moved stuff to do with adding toolstack state to the
save stream? Perhaps libxl
On Wed, 2015-05-20 at 18:01 +0800, Yang Hongyang wrote:
I've just been through this, sorry for the delay.
I also have written on my TODO list "Remus on Migration-v2 (v7)", but I
have no such patches in my folders and I think I already applied
everything to do with that, so I think that's just a s
On Fri, May 22, 2015 at 10:24:39AM +, Joao Martins wrote:
>
> On 19 May 2015, at 17:23, Wei Liu wrote:
> > On Tue, May 12, 2015 at 07:18:27PM +0200, Joao Martins wrote:
> >> Introduces persistent grants for TX path which follows similar code path
> >> as the grant mapping.
> >>
> >> It start
Hi,
We're hitting the kernel BUG below in one of our VMs running on Xen 4.4 and
Linux kernel 3.13.0. We use the xl toolstack and are using PCI pass-through
to pass network cards and a disk controller. It happens on a variety of our
hardware but not all servers and it seems to be related to the e
On Wed, 2015-05-27 at 17:25 +0200, Vitaly Kuznetsov wrote:
> Use letter 'S' to indicate a domain in such state.
>
> Signed-off-by: Vitaly Kuznetsov
Assuming the hypervisor side is found acceptable:
Acked-by: Ian Campbell
___
Xen-devel mailing list
On Wed, 2015-05-27 at 17:25 +0200, Vitaly Kuznetsov wrote:
> Introduce xc_domain_soft_reset() function supporting XEN_DOMCTL_soft_reset.
>
> Signed-off-by: Vitaly Kuznetsov
Assuming the hypervisor side is agreed this looks like a valid wrapping
of it:
Acked-by: Ian Campbell
On Thu, 2015-05-28 at 15:41 +0200, Vitaly Kuznetsov wrote:
> > I.e. what you currently implement is David's model without Konrad's
> > later alternative really having been explored? Iiuc David's main
> > reservation (which I share) was against a myriad of reset-this and
> > reset-that hypercalls, w
On Fri, May 22, 2015 at 10:25:10AM +, Joao Martins wrote:
>
> On 19 May 2015, at 17:32, Wei Liu wrote:
>
> > On Tue, May 12, 2015 at 07:18:28PM +0200, Joao Martins wrote:
> >> It starts by doing a lookup in the tree for a gref. If no persistent
> >> grant is found on the tree, it will do gra
The commit 376bbbabbda607d2039b8f839f15ff02721597d2 "sched_rt: print useful
affinity info when dumping" breaks build on ARM64:
sched_rt.c: In function ‘rt_init’:
sched_rt.c:442:26: error: assignment from incompatible pointer type [-Werror]
_cpumask_scratch = xmalloc_array(cpumask_var_t, n
Hi all,
the following is a collection of QEMU security fixes for PCI Passthrough
on Xen. Non-Xen usages of QEMU are unaffected.
Although the CVEs have already been made public, given the large amount
of changes, I decided not to send a pull request without giving a chance
to the QEMU community to
On Wed, 2015-05-27 at 17:25 +0200, Vitaly Kuznetsov wrote:
> Add new xc_soft_reset() function which performs so-called 'soft reset'
> for an HVM domain. It is being performed in the following way:
> - Save HVM context and all HVM params of the source domain;
> - Transfer all the source domain's mem
On Fri, May 22, 2015 at 10:26:48AM +, Joao Martins wrote:
[...]
> >>return IRQ_HANDLED;
> >> }
> >> @@ -168,8 +169,12 @@ static int xenvif_start_xmit(struct sk_buff *skb,
> >> struct net_device *dev)
> >>cb = XENVIF_RX_CB(skb);
> >>cb->expires = jiffies + vif->drain_timeout;
> >>
From: Jan Beulich
It's being used by the hypervisor. For now simply mimic a device not
capable of masking, and fully emulate any accesses a guest may issue
nevertheless as simple reads/writes without side effects.
This is XSA-129.
Signed-off-by: Jan Beulich
Reviewed-by: Stefano Stabellini
---
From: Jan Beulich
Without this the actual XSA-131 fix would cause the enable bit to not
get set anymore (due to the write back getting suppressed there based
on the OR of emu_mask, ro_mask, and res_mask).
Note that the fiddling with the enable bit shouldn't really be done by
qemu, but making thi
From: Jan Beulich
Since the next patch will turn all not explicitly described fields
read-only by default, those fields that have guest writable bits need
to be given explicit descriptors.
This is a preparatory patch for XSA-131.
Signed-off-by: Jan Beulich
---
hw/xen/xen_pt_config_init.c |
From: Jan Beulich
Limit error messages resulting from bad guest behavior to avoid allowing
the guest to cause the control domain's disk to fill.
The first message in pci_msix_write() can simply be deleted, as this
is indeed bad guest behavior, but such out of bounds writes don't
really need to b
From: Jan Beulich
This is just to avoid having to adjust that calculation later in
multiple places.
Note that including ->ro_mask in get_throughable_mask()'s calculation
is only an apparent (i.e. benign) behavioral change: For r/o fields it
doesn't matter > whether they get passed through - eith
From: Jan Beulich
The old logic didn't work as intended when an access spanned multiple
fields (for example a 32-bit access to the location of the MSI Message
Data field with the high 16 bits not being covered by any known field).
Remove it and derive which fields not to write to from the accesse
On Wed, 2015-05-27 at 17:25 +0200, Vitaly Kuznetsov wrote:
> As a preparation before adding new restart type (soft reset) put all
> restart types into an enum.
>
> Signed-off-by: Vitaly Kuznetsov
Acked-by: Ian Campbell
One typo:
> +DOMAIN_RESTART_NORMAL, /* Domain should be restarte
From: Jan Beulich
xen_pt_pmcsr_reg_write() needs an adjustment to deal with the RW1C
nature of the not passed through bit 15 (PCI_PM_CTRL_PME_STATUS).
This is a preparatory patch for XSA-131.
Signed-off-by: Jan Beulich
Reviewed-by: Stefano Stabellini
---
hw/xen/xen_pt_config_init.c |3 ++
From: Jan Beulich
There's no point in xen_pt_pmcsr_reg_{read,write}() each ORing
PCI_PM_CTRL_STATE_MASK and PCI_PM_CTRL_NO_SOFT_RESET into a local
emu_mask variable - we can have the same effect by setting the field
descriptor's emu_mask member suitably right away. Note that
xen_pt_pmcsr_reg_writ
Hello,
The document describing the PVH interface was committed 9 months ago
[1], and since then there hasn't been any change regarding the
interface. PVH is still missing features in order to have feature parity
with pure PV, mainly:
- DomU miration support.
- PCI passthrough support.
- 32bit
From: Jan Beulich
The adjustments are solely to make the subsequent patches work right
(and hence make the patch set consistent), namely if permissive mode
(introduced by the last patch) gets used (as both reserved registers
and reserved fields must be similarly protected from guest access in
def
From: Jan Beulich
xen_pt_emu_reg_pcie[]'s PCI_EXP_DEVCAP needs to cover all bits as read-
only to avoid unintended write-back (just a precaution, the field ought
to be read-only in hardware).
This is a preparatory patch for XSA-131.
Signed-off-by: Jan Beulich
Reviewed-by: Stefano Stabellini
-
On Wed, 2015-05-27 at 17:25 +0200, Vitaly Kuznetsov wrote:
> Use this in libxl_dm instead of hard-coding.
>
> Signed-off-by: Vitaly Kuznetsov
This is something of an artefact of the layering weirdness regarding the
DM save/restore (saved by libxl, restored by libxc), but I think there
is no harm
From: Jan Beulich
... by default. Add a per-device "permissive" mode similar to pciback's
to allow restoring previous behavior (and hence break security again,
i.e. should be used only for trusted guests).
This is part of XSA-131.
Signed-off-by: Jan Beulich
Acked-by: Stefano Stabellini
Review
El 01/06/15 a les 15.24, Wei Liu ha escrit:
> On Fri, May 22, 2015 at 11:18:55AM +0200, Roger Pau Monne wrote:
>> FreeBSD blkback uses the path xenstore node in order to fetch the path to
>> the underlying backing storage (either a block device or raw image). This
>> node is set by the hotplug scri
On Wed, 2015-05-27 at 17:25 +0200, Vitaly Kuznetsov wrote:
> Perform soft reset when a domain did SHUTDOWN_soft_reset. Migrate the
> content with xc_domain_soft_reset(), reload dm and toolstack.
>
> Signed-off-by: Vitaly Kuznetsov
> ---
> Changes in v7:
> - Save toolstack earlier.
> - Introduce L
On Tue, 2 Jun 2015, Stefano Stabellini wrote:
> Hi all,
>
> the following is a collection of QEMU security fixes for PCI Passthrough
> on Xen. Non-Xen usages of QEMU are unaffected.
>
> Although the CVEs have already been made public, given the large amount
> of changes, I decided not to send a p
On 02/06/15 16:11, Roger Pau Monné wrote:
> Hello,
>
> The document describing the PVH interface was committed 9 months ago
> [1], and since then there hasn't been any change regarding the
> interface. PVH is still missing features in order to have feature parity
> with pure PV, mainly:
>
> - DomU
The following changes since commit 3fc827d591679f3e262b9d1f8b34528eabfca8c0:
target-arm: Correct check for non-EL3 (2015-06-02 13:22:29 +0100)
are available in the git repository at:
git://xenbits.xen.org/people/sstabellini/qemu-dm.git xen-15-06-02
for you to fetch changes up to c25bbf1545a
On Fri, 2015-05-29 at 16:45 +0300, Razvan Cojocaru wrote:
> As suggested by Andrew Cooper, this patch attempts to remove
> some redundancy and allow for an easier time when adding vm_events
> for new control registers in the future, by having a single
> VM_EVENT_REASON_WRITE_CTRLREG vm_event type,
From: Jan Beulich
xen_pt_emu_reg_pcie[]'s PCI_EXP_DEVCAP needs to cover all bits as read-
only to avoid unintended write-back (just a precaution, the field ought
to be read-only in hardware).
This is a preparatory patch for XSA-131.
Signed-off-by: Jan Beulich
Reviewed-by: Stefano Stabellini
-
1 - 100 of 194 matches
Mail list logo
