flight 144791 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144791/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail blocked in 144671
test-amd64-amd64-xl-qemuu-win7-amd6
flight 144776 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144776/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail like 144712
test-amd64-amd64-xl-qemuu-win7-amd64
Ian,
please tag 4.13-rc5 on current stable-4.13 (commit
ddccd9f87ef8accdff518dc2ebb64c05f55cd278).
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
flight 144780 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144780/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 144637
build-i386-xsm
On 13/12/2019 20:15, Tamas K Lengyel wrote:
>> There is also value when it comes to easier SRTM/DRTM measurements of
>> the system in question, including cases where Xen sits on a boot ROM
>> rather than on disk.
> We've explored that in the past - building things into Xen and Linux
> statically -
Hi Paul,
On 13/12/2019 15:55, Durrant, Paul wrote:
-Original Message-
From: Xen-devel On Behalf Of
Julien Grall
Sent: 13 December 2019 15:37
To: Ian Jackson
Cc: Jürgen Groß ; xen-devel@lists.xenproject.org; Stefano
Stabellini ; osstest service owner ; Anthony Perard
Subject: Re: [Xen-
flight 144774 xen-4.13-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144774/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds 15 guest-stop fail REGR. vs. 144673
Tests which did not suc
flight 144778 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144778/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 144517
build-i386-libvirt
Now that vtsc_last is the only entity protected by vtsc_lock we can
simply update it using a single atomic operation and drop the spinlock
entirely. This is extremely important for the case of running nested
(e.g. shim instance with lots of vCPUs assigned) since if preemption
happens somewhere insi
In our PV shim testing we've noticed constant lockups of guests with high
number of vCPUs assigned that usually happening when there is another guest
running on the same host. Reproing the problem manually and dumping shim
state immediately showed that most of the vCPUs are locked on vtsc_lock.
As
They either need to be transformed to atomics to work correctly
(currently they left unprotected for HVM domains) or dropped entirely
as taking a per-domain spinlock is too expensive for high-vCPU count
domains even for debug build given this lock is taken too often.
Choose the latter as they are
flight 144797 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144797/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
flight 144772 xen-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144772/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-debianhvm-i386-xsm 15 guest-saverestore.2 fail REGR.
vs. 144324
Tes
> There is also value when it comes to easier SRTM/DRTM measurements of
> the system in question, including cases where Xen sits on a boot ROM
> rather than on disk.
We've explored that in the past - building things into Xen and Linux
statically - and ultimately it only works if the command line p
flight 144790 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144790/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On 08/11/2019 15:22, Jan Beulich wrote:
> 1: include the PPIN in MCE records when available
> 2: explicitly disallow guest access to PPIN
> 3: provide Dom0 access to PPIN via XENPF_resource_op
>
> I have yet to get around to post the Linux side consumer
> patch of the interface addition in patch 1.
On 08/11/2019 15:24, Jan Beulich wrote:
> It was requested that we provide a way independent of the MCE reporting
> interface that Dom0 software could use to get hold of the values for
> particular CPUs.
>
> Signed-off-by: Jan Beulich
This hypercall is a total gross bodge, but I suppose it is the
On 08/11/2019 15:24, Jan Beulich wrote:
> To fulfill the "protected" in its name, don't let the real hardware
> values "shine through". Report a control register value expressing this.
Why not call it as it is? They leak through due to bugs in MSR handling.
> Signed-off-by: Jan Beulich
> ---
>
On 08/11/2019 15:23, Jan Beulich wrote:
> Quoting the respective Linux commit:
>
> Intel Xeons from Ivy Bridge onwards support a processor identification
> number set in the factory. To the user this is a handy unique number to
> identify a particular CPU. Intel can decode this to the f
On 13/12/2019 16:59, Jan Beulich wrote:
> On 13.12.2019 16:49, Anthony PERARD wrote:
>> On Fri, Dec 13, 2019 at 12:05:11PM +0100, Jan Beulich wrote:
>>> On 12.12.2019 19:27, Anthony PERARD wrote:
--- /dev/null
+++ b/xen/.gitignore
@@ -0,0 +1,2 @@
+*.lex.c
+*.tab.[ch]
>>> Wh
Construct the system linkage MSRs using percpu_traps_init(), brining the S3
path in line with the BSP/AP path. Restore xcr0 from the per-cpu shadow copy.
The FS/GS base values are unused in Xen context, and will be loaded
appropriately by the next vcpu context switch.
Trim the include list subst
The trampoline has already set up the idle pagetables (which are the correct
ones to use), and sanitised the flags state.
For %ss, __HYPERVISOR_DS64 is the correct descriptor to restore.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
---
xen/arch/x86/acpi/wa
do_suspend_lowlevel() behaves as a function call, even when the trampoline
jumps back into the middle of it. Discuss this property, while renaming the
far-too-generic __ret_point to s3_resume.
Optimise the calling logic for acpi_enter_sleep_state(). $3 doesn't require a
64bit write, and the func
Andrew Cooper (6):
x86/suspend: Clarify and improve the behaviour of do_suspend_lowlevel()
x86/suspend: Don't bother saving %cr3, %ss or flags
x86/suspend: Don't save unnecessary GPRs
x86/suspend: Restore cr4 later during resume
x86/suspend: Expand macros in wakeup_prot.S
x86/suspend: D
Just like the BSP/AP paths, %cr4 is loaded with only PAE. Defer restoring all
of %cr4 (MCE in particular) until all the system structures (IDT/TSS in
particular) have been loaded.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
---
xen/arch/x86/acpi/suspend.c
Most users have been dropped, and they do nothing but obfuscate the assembly.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
---
xen/arch/x86/acpi/wakeup_prot.S | 28 +---
1 file changed, 9 insertions(+), 19 deletions(-)
diff --git a/
Only the callee-preserved registers need saving/restoring. Spill them to the
stack like regular functions do. %rsp is now the only GPR which gets stashed
in .data
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
---
xen/arch/x86/acpi/wakeup_prot.S | 59 ++
In many places, a PTE being modified is accompanied by the pagetable
mfn which contains the PTE (primarily in order to be able to maintain
linear mapping counts). In many cases, this mfn is stored in the
non-descript variable (or argement) "pfn".
Replace these names with lNmfn, to indicate that 1
The functions alloc_page_type(), alloc_lN_table(), free_page_type()
and free_lN_table() are confusingly named: nothing is being allocated
or freed. Rather, the page being passed in is being either validated
or devalidated for use as the specific type; in the specific case of
pagetables, these may
Replace `unsigned long` with `mfn_t` as appropriate throughout
alloc/free_lN_table, get/put_page_from_lNe, and
get_lN_linear_pagetable. This obviates the need for a load of
`mfn_x()` and `_mfn()` casts.
Signed-off-by: George Dunlap
---
New in v2.
CC: Andrew Cooper
CC: Jan Beulich
---
xen/arc
This series implements a number of cleanups to make the code simpler
and easier to follow. No functional changes intended.
George Dunlap (3):
x86/mm: Use a more descriptive name for pagetable mfns
x86/mm: Use mfn_t in type get / put call tree
x86/mm: More discriptive names for page de/valid
flight 144769 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144769/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemuu-rhel6hvm-intel 12 guest-start/redhat.repeat fail REGR.
vs. 144671
Tests w
cr-daily-branch ought to be called via cr-for-branches so that we take
the lock. Otherwise strange things can occur if cron runs
cr-daily-branch in the same directory - in particular, it will be
likely to update the osstest revision, breaking everything.
Signed-off-by: Ian Jackson
---
docs/proc
On 13.12.2019 16:35, Jürgen Groß wrote:
> On 13.12.19 15:45, Jan Beulich wrote:
>> On 13.12.2019 15:24, Jürgen Groß wrote:
>>> On 13.12.19 15:11, Jan Beulich wrote:
On 13.12.2019 14:46, Jürgen Groß wrote:
> On 13.12.19 14:38, Jan Beulich wrote:
>> On 13.12.2019 14:31, Jürgen Groß wrote
On 13.12.2019 16:49, Anthony PERARD wrote:
> On Fri, Dec 13, 2019 at 12:05:11PM +0100, Jan Beulich wrote:
>> On 12.12.2019 19:27, Anthony PERARD wrote:
>>> --- /dev/null
>>> +++ b/xen/.gitignore
>>> @@ -0,0 +1,2 @@
>>> +*.lex.c
>>> +*.tab.[ch]
>>
>> Why do these get moved here from ...
>>
>>> --- a
On 12/13/19 5:17 PM, Philippe Mathieu-Daudé wrote:
Historically, QEMU started with only one X86 machine: the PC.
The 'hw/i386/pc.h' header was used to store all X86 and PC
declarations. Since we have now multiple machines based on the
X86 architecture, move the PC-specific declarations in a new
h
This patch adds a specification for a 'carrier' node in xenstore to allow
a backend to notify a frontend of it's virtual carrier/link state. E.g.
a backend that is unable to forward packets from the guest because it is
not attached to a bridge may wish to advertise 'no carrier'.
While in the area
Historically, QEMU started with only one X86 machine: the PC.
The 'hw/i386/pc.h' header was used to store all X86 and PC
declarations. Since we have now multiple machines based on the
X86 architecture, move the PC-specific declarations in a new
header.
We use 'internal' in the name to explicit this
Using magic numbers is dangerous because the structures PCIIDEState
might be modified and this source file consuming the "ide/pci.h"
header would be out of sync, eventually accessing out of bound
array members.
Use the ARRAY_SIZE() to keep the source file sync.
Signed-off-by: Philippe Mathieu-Daud
All the X86 machines use an interrupt controller.
Rename the function to something more generic.
Signed-off-by: Philippe Mathieu-Daudé
---
include/hw/i386/pc.h | 2 +-
hw/i386/microvm.c| 2 +-
hw/i386/pc.c | 4 ++--
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/inclu
Keep 'pc.c' for PC-machine specific code, and use 'x86.c' for code
used by all the X86-based machines.
Signed-off-by: Philippe Mathieu-Daudé
---
include/hw/i386/pc.h | 1 -
include/hw/i386/x86.h | 2 ++
hw/i386/pc.c | 27 ---
hw/i386/x86.c | 30 +++
Since commit 0c8465440 the ioapic_print_redtbl() function is not
used outside of ioapic_common.c, make it static, and remove its
prototype declaration in "ioapic_internal.h".
Signed-off-by: Philippe Mathieu-Daudé
---
include/hw/i386/ioapic_internal.h | 1 -
hw/intc/ioapic_common.c | 2
Commit 02a9594b4f0 already converted 'dev' to DeviceState.
Since the cast is superfluous, remove it.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/ide/piix.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/hw/ide/piix.c b/hw/ide/piix.c
index db313dd3b1..ffeff4e095 100644
---
While the ICH9 chipset is a 'South Bridge', it is not a PCI bridge.
Nothing in "hw/i386/ich9.h" requires definitions from "pci_bridge.h"
so move its inclusion where it is required.
Signed-off-by: Philippe Mathieu-Daudé
---
include/hw/i386/ich9.h| 1 -
hw/i386/acpi-build.c | 1 +
hw/pci-
The "pcie_host.h" header is used by devices providing a PCI-e bus,
usually North Bridges. The ICH9 is a South Bridge.
Since we don't need this header, do not include it.
Signed-off-by: Philippe Mathieu-Daudé
---
include/hw/i386/ich9.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/include/hw
In commit 1454509726 we removed the pc_pci_device_init()
deprecated function and its calls, but we forgot to remove
its prototype. Do that now.
Signed-off-by: Philippe Mathieu-Daudé
---
include/hw/i386/pc.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/include/hw/i386/pc.h b/include/hw/i386
In commit f809c6051 we replaced the use of cpu_set_smm_t callbacks
by using a Notifier to modify the MemoryRegion. This prototype is
now not used anymore, we can safely remove it.
Signed-off-by: Philippe Mathieu-Daudé
---
include/hw/i386/pc.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/
Move the KVM-related call to "sysemu/kvm.h".
Signed-off-by: Philippe Mathieu-Daudé
---
include/hw/i386/pc.h | 1 -
include/sysemu/kvm.h | 1 +
2 files changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
index 1f86eba3f9..9866dfbd60 100644
--- a/includ
Hi Paolo,
Since you posted your "x86: allow building without PC machine
types" series [1], I looked at my past work on this topic
(restrict "hw/i386/pc.h" to the X86 architecture).
I'm glad to see in [2] you remove most (all) of the last uses.
Since I haven't looked at this for some time, my WiP b
Convert the deprecated DPRINTF() macro to trace events.
Signed-off-by: Philippe Mathieu-Daudé
---
v2: rename pc_pic -> x86_pic
---
hw/i386/pc.c | 19 +--
hw/i386/trace-events | 6 ++
2 files changed, 11 insertions(+), 14 deletions(-)
diff --git a/hw/i386/pc.c b/hw/i
On Thu, Dec 12, 2019 at 06:56:00PM +, Andrew Cooper wrote:
> On 12/12/2019 18:27, Anthony PERARD wrote:
> > diff --git a/xen/Makefile b/xen/Makefile
> > index efbe9605e52b..0cf4ded9d9d4 100644
> > --- a/xen/Makefile
> > +++ b/xen/Makefile
> > @@ -267,6 +267,7 @@ $(foreach base,arch/x86/mm/guest
On Fri, 2019-12-13 at 14:58 +, Andrew Cooper wrote:
> On 13/12/2019 14:36, Jan Beulich wrote:
> > On 13.12.2019 15:19, Andrew Cooper wrote:
> > > On 12/12/2019 12:46, Hongyan Xia wrote:
> > > > diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
> > > > index 7d4dd80a85..8def4fb8d8 100644
> > >
On 13.12.19 16:51, Paul Durrant wrote:
This patch adds a specification for a 'carrier' node in xenstore to allow
a backend to notify a frontend of it's virtual carrier/link state. E.g.
a backend that is unable to forward packets from the guest because it is
not attached to a bridge may wish to ad
Hi,
On Fri, 2019-12-13 at 14:19 +, Andrew Cooper wrote:
> On 12/12/2019 12:46, Hongyan Xia wrote:
> > diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
> > index 7d4dd80a85..8def4fb8d8 100644
> > --- a/xen/arch/x86/mm.c
> > +++ b/xen/arch/x86/mm.c
> > @@ -5151,6 +5151,52 @@ l1_pgentry_t *virt
> -Original Message-
> From: Xen-devel On Behalf Of
> Julien Grall
> Sent: 13 December 2019 15:37
> To: Ian Jackson
> Cc: Jürgen Groß ; xen-devel@lists.xenproject.org; Stefano
> Stabellini ; osstest service owner ad...@xenproject.org>; Anthony Perard
> Subject: Re: [Xen-devel] [xen-4.13
This patch adds a specification for a 'carrier' node in xenstore to allow
a backend to notify a frontend of it's virtual carrier/link state. E.g.
a backend that is unable to forward packets from the guest because it is
not attached to a bridge may wish to advertise 'no carrier'.
While in the area
On Fri, Dec 13, 2019 at 12:05:11PM +0100, Jan Beulich wrote:
> Just two minor remarks:
>
> On 12.12.2019 19:27, Anthony PERARD wrote:
> > --- /dev/null
> > +++ b/docs/misc/kconfig-macro-language.rst
[...]
> > +Then, Kconfig moves onto the evaluation stage to resolve inter-symbol
> > +dependency as
+Anthony
On 13/12/2019 11:40, Ian Jackson wrote:
Julien Grall writes ("Re: [Xen-devel] [xen-4.13-testing test] 144736: regressions -
FAIL"):
AMD Seattle boards (laxton*) are known to fail booting time to time
because of PCI training issue. We have workaround for it (involving
longer power cycl
Granting pages consumes backend system memory. In systems configured
with insufficient spare memory for those pages, it can cause a memory
pressure situation. However, finding the optimal amount of the spare
memory is challenging for large systems having dynamic resource
utilization patterns. Al
The number of empty lines between functions in the xenbus.c is
inconsistent. This trivial style cleanup commit fixes the file to
consistently place only one empty line.
Signed-off-by: SeongJae Park
---
drivers/block/xen-blkback/xenbus.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(
A few of static variables in blkback have 'xen_blkif_' prefix, though it
is unnecessary for static variables. This commit removes such prefixes.
Reviewed-by: Roger Pau Monné
Signed-off-by: SeongJae Park
---
drivers/block/xen-blkback/blkback.c | 37 +
1 file changed,
On 13.12.19 15:45, Jan Beulich wrote:
On 13.12.2019 15:24, Jürgen Groß wrote:
On 13.12.19 15:11, Jan Beulich wrote:
On 13.12.2019 14:46, Jürgen Groß wrote:
On 13.12.19 14:38, Jan Beulich wrote:
On 13.12.2019 14:31, Jürgen Groß wrote:
Maybe I have misunderstood the current state, but I though
Each `blkif` has a free pages pool for the grant mapping. The size of
the pool starts from zero and is increased on demand while processing
the I/O requests. If current I/O requests handling is finished or 100
milliseconds has passed since last I/O requests handling, it checks and
shrinks the poo
Granting pages consumes backend system memory. In systems configured
with insufficient spare memory for those pages, it can cause a memory
pressure situation. However, finding the optimal amount of the spare
memory is challenging for large systems having dynamic resource
utilization patterns. Al
> -Original Message-
> From: Jürgen Groß
> Sent: 13 December 2019 14:17
> To: Durrant, Paul ; xen-devel@lists.xenproject.org
> Cc: Konrad Rzeszutek Wilk
> Subject: Re: [PATCH] public/io/netif.h: document a mechanism to advertise
> carrier state
>
> On 13.12.19 14:03, Paul Durrant wrote:
On Thu, Dec 12, 2019 at 06:45:02PM +, Andrew Cooper wrote:
> On 12/12/2019 18:27, Anthony PERARD wrote:
> > Dependency change:
> > - Now depends on flex/bison, maybe we could _shipped those files like
> > before. Linux doesn't do that anymore.
>
> Content like that should not be checked in t
On Thu, Dec 12, 2019 at 06:32:27PM +, Andrew Cooper wrote:
> On 12/12/2019 18:27, Anthony PERARD wrote:
> > This comment isn't about CONFIG_TESTS, but about SEABIOS_DIR that has
> > been removed.
> >
> > Originally, the comment was added by 5f82d0858de1 ("tools: support
> > SeaBIOS. Use by defa
On 13/12/2019 13:58, George Dunlap wrote:
>
>> On Dec 12, 2019, at 7:57 PM, Andrew Cooper wrote:
>>
>> On 12/12/2019 17:32, George Dunlap wrote:
>>> Both put_page_from_l2e and put_page_from_l3e handle having superpage
>>> entries by looping over each page and "put"-ing each one individually.
>>> A
On Fri, 13 Dec 2019 15:34:35 +0100 "Roger Pau Monné"
wrote:
> > Each `blkif` has a free pages pool for the grant mapping. The size of
> > the pool starts from zero and is increased on demand while processing
> > the I/O requests. If current I/O requests handling is finished or 100
> > millisec
On 13/12/2019 14:36, Jan Beulich wrote:
> On 13.12.2019 15:19, Andrew Cooper wrote:
>> On 12/12/2019 12:46, Hongyan Xia wrote:
>>> diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
>>> index 7d4dd80a85..8def4fb8d8 100644
>>> --- a/xen/arch/x86/mm.c
>>> +++ b/xen/arch/x86/mm.c
>>> @@ -5151,6 +5151,
On Thu, Dec 12, 2019 at 06:30:43PM +, Andrew Cooper wrote:
> On 12/12/2019 18:27, Anthony PERARD wrote:
> > diff --git a/docs/misc/distro_mapping.txt b/docs/misc/distro_mapping.txt
> > index 2e46592728e3..599b6fd1e912 100644
> > --- a/docs/misc/distro_mapping.txt
> > +++ b/docs/misc/distro_mapp
On 13.12.2019 15:24, Jürgen Groß wrote:
> On 13.12.19 15:11, Jan Beulich wrote:
>> On 13.12.2019 14:46, Jürgen Groß wrote:
>>> On 13.12.19 14:38, Jan Beulich wrote:
On 13.12.2019 14:31, Jürgen Groß wrote:
> Maybe I have misunderstood the current state, but I thought that it
> would jus
On 13.12.2019 15:29, Jürgen Groß wrote:
> On 13.12.19 15:23, Jan Beulich wrote:
>> On 13.12.2019 14:53, Durrant, Paul wrote:
>>> Since *not* having the 'sink' page allows a guest pull off a host DoS
>>> in the presence of such h/w, security is surely increased by having it?
>>
>> host devic
On Thu, Dec 12, 2019 at 07:00:35PM +, Andrew Cooper wrote:
> On 12/12/2019 18:27, Anthony PERARD wrote:
> > Kconfig can check if $(CC) is clang or not, if it is
> > CONFIG_CC_IS_CLANG will be set.
> >
> > With that patch, the hypervisor can be built using clang by running
> > `make CC=clang CXX
On 12/12/2019 13:16, Jan Beulich wrote:
> On 12.12.2019 13:46, Hongyan Xia wrote:
>> map_pages_to_xen and modify_xen_mappings use almost exactly the same
>> page shattering logic, and the code is mingled with other PTE
>> manipulations so it is less obvious that the intention is page
>> shattering.
On 13.12.2019 15:19, Andrew Cooper wrote:
> On 12/12/2019 12:46, Hongyan Xia wrote:
>> diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
>> index 7d4dd80a85..8def4fb8d8 100644
>> --- a/xen/arch/x86/mm.c
>> +++ b/xen/arch/x86/mm.c
>> @@ -5151,6 +5151,52 @@ l1_pgentry_t *virt_to_xen_l1e(unsigned lon
On Fri, Dec 13, 2019 at 01:02:10PM +, SeongJae Park wrote:
> Each `blkif` has a free pages pool for the grant mapping. The size of
> the pool starts from zero and is increased on demand while processing
> the I/O requests. If current I/O requests handling is finished or 100
> milliseconds has
On 13.12.19 15:23, Jan Beulich wrote:
On 13.12.2019 14:53, Durrant, Paul wrote:
Since *not* having the 'sink' page allows a guest pull off a host DoS
in the presence of such h/w, security is surely increased by having it?
hostdevice result w/o sink result w/ sink
g
On 13.12.19 15:11, Jan Beulich wrote:
On 13.12.2019 14:46, Jürgen Groß wrote:
On 13.12.19 14:38, Jan Beulich wrote:
On 13.12.2019 14:31, Jürgen Groß wrote:
Maybe I have misunderstood the current state, but I thought that it
would just silently hide quirky devices without imposing a security
ri
On 13.12.2019 14:53, Durrant, Paul wrote:
> Since *not* having the 'sink' page allows a guest pull off a host DoS
> in the presence of such h/w, security is surely increased by having it?
hostdevice result w/o sink result w/ sink
goodgoodgood
On 12/12/2019 12:46, Hongyan Xia wrote:
> diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
> index 7d4dd80a85..8def4fb8d8 100644
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -5151,6 +5151,52 @@ l1_pgentry_t *virt_to_xen_l1e(unsigned long v)
> flush_area_local
On 13.12.19 14:03, Paul Durrant wrote:
This patch adds a specification for a 'carrier' node in xenstore to allow
a backend to notify a frontend of it's virtual carrier/link state. E.g.
a backend that is unable to forward packets from the guest because it is
not attached to a bridge may wish to ad
On 13.12.2019 14:46, Jürgen Groß wrote:
> On 13.12.19 14:38, Jan Beulich wrote:
>> On 13.12.2019 14:31, Jürgen Groß wrote:
>>> Maybe I have misunderstood the current state, but I thought that it
>>> would just silently hide quirky devices without imposing a security
>>> risk. We would not learn whi
On Fri, Dec 13, 2019 at 01:53:29PM +0100, Jan Beulich wrote:
> Containing still in flight DMA was introduced to work around certain
> devices / systems hanging hard upon hitting an IOMMU fault. Passing
> through (such) devices (on such systems) is inherently insecure (as
> guests could easily arran
> On Dec 12, 2019, at 7:57 PM, Andrew Cooper wrote:
>
> On 12/12/2019 17:32, George Dunlap wrote:
>> Both put_page_from_l2e and put_page_from_l3e handle having superpage
>> entries by looping over each page and "put"-ing each one individually.
>> As with putting page table entries, this code is
On 12/12/2019 22:13, Eslam Elnikety wrote:
>>> Second, there is often need to couple a Xen build with a minimum
>>> microcode patch level. Having the microcode built within the Xen image
>>> itself is a streamlined, natural way of achieving that.
>>
>> Okay, I can accept this as a reason, to some d
> -Original Message-
> From: Xen-devel On Behalf Of
> Jürgen Groß
> Sent: 13 December 2019 13:47
> To: Jan Beulich
> Cc: Kevin Tian ; Stefano Stabellini
> ; Julien Grall ; Wei Liu
> ; Konrad Wilk ; George Dunlap
> ; Andrew Cooper ;
> Paul Durrant ; Ian Jackson ; xen-
> de...@lists.xenproj
On 13.12.19 14:38, Jan Beulich wrote:
On 13.12.2019 14:31, Jürgen Groß wrote:
On 13.12.19 14:21, Jan Beulich wrote:
On 13.12.2019 14:11, Jürgen Groß wrote:
On 13.12.19 13:53, Jan Beulich wrote:
Containing still in flight DMA was introduced to work around certain
devices / systems hanging hard
On 09/12/2019 21:49, Eslam Elnikety wrote:
>>> +
>>> +extern const char __builtin_intel_ucode_start[],
>>> __builtin_intel_ucode_end[];
>>> +extern const char __builtin_amd_ucode_start[],
>>> __builtin_amd_ucode_end[];
>>> +#endif
>>> +
>>> /* By default, ucode loading is done in NMI handler */
>
On 13.12.2019 14:31, Jürgen Groß wrote:
> On 13.12.19 14:21, Jan Beulich wrote:
>> On 13.12.2019 14:11, Jürgen Groß wrote:
>>> On 13.12.19 13:53, Jan Beulich wrote:
Containing still in flight DMA was introduced to work around certain
devices / systems hanging hard upon hitting an IOMMU fa
On 13.12.2019 14:29, Durrant, Paul wrote:
>> From: Jan Beulich
>> Sent: 13 December 2019 13:26
>>
>> On 13.12.2019 14:12, Durrant, Paul wrote:
From: Xen-devel On Behalf Of Jan
Beulich
Sent: 13 December 2019 12:53
+#define IOMMU_quarantine_none 0
+#define IOMMU_quara
On 13.12.19 14:21, Jan Beulich wrote:
On 13.12.2019 14:11, Jürgen Groß wrote:
On 13.12.19 13:53, Jan Beulich wrote:
Containing still in flight DMA was introduced to work around certain
devices / systems hanging hard upon hitting an IOMMU fault. Passing
through (such) devices (on such systems) i
> -Original Message-
> From: Jan Beulich
> Sent: 13 December 2019 13:26
> To: Durrant, Paul
> Cc: xen-devel@lists.xenproject.org; Juergen Gross ; Kevin
> Tian ; Stefano Stabellini ;
> Julien Grall ; Wei Liu ; Konrad Wilk
> ; George Dunlap ;
> Andrew Cooper ; Paul Durrant ;
> Ian Jackson ;
On 13.12.2019 14:12, Durrant, Paul wrote:
>> -Original Message-
>> From: Xen-devel On Behalf Of Jan
>> Beulich
>> Sent: 13 December 2019 12:53
>> To: xen-devel@lists.xenproject.org
>> Cc: Juergen Gross ; Kevin Tian ;
>> Stefano Stabellini ; Julien Grall
>> ; Wei Liu ; Konrad Wilk
>> ; Geor
In function xenvif_disconnect_queue(), the value of queue->rx_irq is
zeroed *before* queue->task is stopped. Unfortunately that task may call
notify_remote_via_irq(queue->rx_irq) and calling that function with a
zero value results in a NULL pointer dereference in evtchn_from_irq().
This patch simp
On 13.12.2019 14:11, Jürgen Groß wrote:
> On 13.12.19 13:53, Jan Beulich wrote:
>> Containing still in flight DMA was introduced to work around certain
>> devices / systems hanging hard upon hitting an IOMMU fault. Passing
>> through (such) devices (on such systems) is inherently insecure (as
>> gu
On 13.12.19 13:53, Jan Beulich wrote:
Containing still in flight DMA was introduced to work around certain
devices / systems hanging hard upon hitting an IOMMU fault. Passing
through (such) devices (on such systems) is inherently insecure (as
guests could easily arrange for IOMMU faults to occur)
> -Original Message-
> From: Xen-devel On Behalf Of Jan
> Beulich
> Sent: 13 December 2019 12:53
> To: xen-devel@lists.xenproject.org
> Cc: Juergen Gross ; Kevin Tian ;
> Stefano Stabellini ; Julien Grall
> ; Wei Liu ; Konrad Wilk
> ; George Dunlap ;
> Andrew Cooper ; Paul Durrant ;
> Ian
On 13.12.2019 14:01, Andrew Cooper wrote:
> On 13/12/2019 12:54, Jan Beulich wrote:
>> AMD and friends explicitly specify that 64-bit operands aren't possible
>> for these insns. Nevertheless REX.W isn't fully ignored: It still
>> cancels a possible operand size override (0x66). Intel otoh explicit
This patch adds a specification for a 'carrier' node in xenstore to allow
a backend to notify a frontend of it's virtual carrier/link state. E.g.
a backend that is unable to forward packets from the guest because it is
not attached to a bridge may wish to advertise 'no carrier'.
NOTE: This is pure
1 - 100 of 140 matches
Mail list logo
