branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-xl-pvh-amd
testid guest-start
Tree: linux
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditiona
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of
> Stefano Stabellini
> Sent: 11 October 2017 21:19
> To: Anthony Perard
> Cc: qemu-de...@nongnu.org; xen-de...@lists.xenproject.org; Stefano
> Stabellini ; Owen Smith ;
> kra...@redhat.com
> Subjec
flight 72230 distros-debian-wheezy real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/72230/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
build-arm64 2 hosts-allocate broken like 72201
build-arm64-pvops
FYI all patches except the xentrace one were committed yesterday.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
On Wed, Oct 11, 2017 at 06:52:38PM +0100, George Dunlap wrote:
> Move fuzz-emul.c function prototypes into a header. Also share the
> definition of the input size (rather than hard-coding it in
> fuzz-emul.c).
>
> Signed-off-by: George Dunlap
Reviewed-by: Wei Liu
_
On Wed, Oct 11, 2017 at 05:00:45PM +0100, Wei Liu wrote:
> On Tue, Oct 10, 2017 at 04:03:32PM +0100, James Dingwall wrote:
> > Hi,
> >
> > We are migrating from xen 4.4 to xen 4.8. At the moment we boot our system
> > with a xen command line that includes "dom0_mem=8192m,min:1728m,max:8192m".
> >
This patch adds the old value param and the onchangeonly option
to the VM_EVENT_REASON_MOV_TO_MSR event.
The param was added to the vm_event_mov_to_msr struct and to the
hvm_monitor_msr function. Finally I've changed the bool_t param
to a bool for the hvm_msr_write_intercept function.
Signed-off-
flight 114336 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/114336/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-libvirt broken
test-armhf-armhf-xl-xsm
Hi,
> It's probably OS specific though. I guess the behaviour changed
> because the OS favours absolute pointing devices over relative ones
> and how it has two absolute ones to choose from. How it reconciles
> those, who knows?
Typically hid emulation calls qemu_input_handler_activate() when t
flight 114404 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/114404/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt 12 guest-start fail REGR. vs. 114299
Tests which
On 9 October 2017 at 22:48, Andre Przywara wrote:
> Hi,
>
> can you please re-break the commit message to fit into 72 characters?
> git show looks rather ugly as it is now.
ok.
>
> On 27/09/17 07:13, Bhupinder Thakur wrote:
>> This patch fixes the issue observed when pl011 patches were tested on
>
The first two patches are bug fixes and hence candidates for 4.10.
The 3rd is mostly cleanup, and hence intended only for after 4.10.
1: request page table page-in for the correct domain
2: fix do_update_va_mapping_otherdomain() wrt translated domains
3: tighten MMU_*PT_UPDATE* check and combine e
> -Original Message-
> From: Gerd Hoffmann [mailto:kra...@redhat.com]
> Sent: 12 October 2017 10:26
> To: Paul Durrant ; 'Stefano Stabellini'
> ; Anthony Perard
> Cc: qemu-de...@nongnu.org; xen-de...@lists.xenproject.org; Owen Smith
>
> Subject: Re: [Xen-devel] [PATCH 3/3 v4] xenfb: Add [
>>> On 12.10.17 at 06:33, wrote:
> On 17-10-11 07:38:52, Jan Beulich wrote:
>> >>> On 08.10.17 at 09:23, wrote:
>> > --- a/xen/arch/x86/psr.c
>> > +++ b/xen/arch/x86/psr.c
>> > @@ -138,6 +138,12 @@ static const struct feat_props {
>> >
>> > /* write_msr is used to write out feature MSR reg
>>> On 11.10.17 at 18:52, wrote:
> On 10/11/2017 10:31 AM, Jan Beulich wrote:
> On 10.10.17 at 18:20, wrote:
>>> --- a/tools/fuzz/x86_instruction_emulator/fuzz-emul.c
>>> +++ b/tools/fuzz/x86_instruction_emulator/fuzz-emul.c
>>> @@ -40,6 +40,8 @@ struct fuzz_state
>>> uint64_t msr[MSR_IN
The domain passed to p2m_mem_paging_populate() should match the one
passed to the corresponding get_page_from_gfn().
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -3287,7 +3287,7 @@ long do_mmu_update(
if ( p2m_is_paged(p2mt) )
{
While I can't seem to find any users of this hypercall (being a likely
explanation of why the problem wasn't noticed so far), just like for
do_mmu_update() paged-out and shared page handling is needed here. Move
all this logic into mod_l1_entry(), which then also results in no
longer
- doing any of
Don't accept anything other than r/w RAM pages and move the paged-out
check into the (unlikely) error path following that check.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -3507,18 +3507,18 @@ long do_mmu_update(
gmfn = req.ptr >> PAGE_SHIFT;
On 12/10/17 11:00, Jan Beulich wrote:
> The domain passed to p2m_mem_paging_populate() should match the one
> passed to the corresponding get_page_from_gfn().
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
>
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -3287,7 +3287,7 @@
On Wed, Oct 11, 2017 at 01:19:25PM -0700, Stefano Stabellini wrote:
> On Wed, 11 Oct 2017, Anthony PERARD wrote:
> > The only observation I have is that on a Linux guest, when I have
> > usbdevice=tablet, with this series the pv mouse seems to become the
> > primary way of gueting mouse events (wit
flight 114351 xtf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/114351/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xtf 9a439d131fcb546d5254522e817694a2d46ffde8
baseline version:
xtf b10eb8666d5bf72ad38f99
Hello,
On 12/10/17 07:11, Manish Jaggi wrote:
On 10/6/2017 7:54 PM, Julien Grall wrote:
I am not asking to write the DomU support, but at least have a full
separation between the Parsing and Generation. So we could easily
adapt and re-use the code when we get the DomU support.
I got your poi
On 12/10/17 11:00, Jan Beulich wrote:
> While I can't seem to find any users of this hypercall (being a likely
> explanation of why the problem wasn't noticed so far), just like for
Judging by c/s a51ed685b which shifted
__HYPERVISOR_update_va_mapping_otherdomain's hypercall number to make
space f
Right now, this is broken because libxl__build_device_model_args_new
is used also for the qemu run for pv guests for qdisk devices, pvfb,
etc.
We can either make this option properly HVM-specific, or make it
generic.
In principle it is a reasonable request, to make the PV qemu
deprivileged (even
Signed-off-by: Ian Jackson
Reported-by: Roger Pau Monné
---
docs/man/xl.cfg.pod.5.in | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/docs/man/xl.cfg.pod.5.in b/docs/man/xl.cfg.pod.5.in
index 8125dfb..d0e3520 100644
--- a/docs/man/xl.cfg.pod.5.in
+++ b/docs/man/xl.cfg.po
Hi Julien,
Why do you omit parts of mail where I have asked a question , please
avoid skiping that removes the context.
I raised a valid point and it was totally ignored and you asked me to
explain the rationale on a later point.
So if you choose to ignore my first point, how can I put any po
On Thu, Oct 12, 2017 at 12:21:07PM +0100, Ian Jackson wrote:
> Signed-off-by: Ian Jackson
> Reported-by: Roger Pau Monné
Acked-by: Wei Liu
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
On Thu, Oct 12, 2017 at 12:21:06PM +0100, Ian Jackson wrote:
> Right now, this is broken because libxl__build_device_model_args_new
> is used also for the qemu run for pv guests for qdisk devices, pvfb,
> etc.
>
> We can either make this option properly HVM-specific, or make it
> generic.
>
> In
>>> On 12.10.17 at 13:18, wrote:
> On 12/10/17 11:00, Jan Beulich wrote:
>> While I can't seem to find any users of this hypercall (being a likely
>> explanation of why the problem wasn't noticed so far), just like for
>
> Judging by c/s a51ed685b which shifted
> __HYPERVISOR_update_va_mapping_ot
On 12/10/17 11:01, Jan Beulich wrote:
> Don't accept anything other than r/w RAM pages and move the paged-out
> check into the (unlikely) error path following that check.
>
> Signed-off-by: Jan Beulich
How does dom0 boot with this change in place? You appear to have
prohibited mapping MMIO frame
flight 114411 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/114411/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf broken
build-armhf 4 hos
On Thu, Oct 12, 2017 at 11:21:06AM +, Ian Jackson wrote:
> Right now, this is broken because libxl__build_device_model_args_new
> is used also for the qemu run for pv guests for qdisk devices, pvfb,
> etc.
>
> We can either make this option properly HVM-specific, or make it
> generic.
>
> In
On 12/10/17 12:22, Manish Jaggi wrote:
Hi Julien,
Why do you omit parts of mail where I have asked a question , please
avoid skiping that removes the context.
I believe I answered it just after because you asked twice the same
thing. So may I dropped the context but the answer was there..
On Thu, Oct 12, 2017 at 11:21:07AM +, Ian Jackson wrote:
> Signed-off-by: Ian Jackson
> Reported-by: Roger Pau Monné
Reviewed-by: Roger Pau Monné
Thanks, Roger.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Signed-off-by: Ian Jackson
Reported-by: Roger Pau Monné
Acked-by: Wei Liu
---
docs/man/xl.cfg.pod.5.in | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/docs/man/xl.cfg.pod.5.in b/docs/man/xl.cfg.pod.5.in
index 9b27233..b7b91d8 100644
--- a/docs/man/xl.cfg.pod.5.in
+++ b
Right now, this is broken because libxl__build_device_model_args_new
is used also for the qemu run for pv guests for qdisk devices, pvfb,
etc.
We can either make this option properly HVM-specific, or make it
generic.
In principle it is a reasonable request, to make the PV qemu
deprivileged (even
Hi Andre,
On Wed, Oct 11, 2017 at 03:33:03PM +0100, Andre Przywara wrote:
> Hi,
>
> (CC:ing some KVM/ARM folks involved in the VGIC)
Very nice writeup!
I added a bunch of comments, mostly for the writing and clarity, I hope
it helps.
>
> starting with the addition of the ITS support we were s
>>> On 12.10.17 at 13:31, wrote:
> On 12/10/17 11:01, Jan Beulich wrote:
>> Don't accept anything other than r/w RAM pages and move the paged-out
>> check into the (unlikely) error path following that check.
>>
>> Signed-off-by: Jan Beulich
>
> How does dom0 boot with this change in place? You
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory XSA-239
version 2
hypervisor stack leak in x86 I/O intercept code
UPDATES IN VERSION 2
Public release.
ISSUE DESCRIPTION
=
I
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory XSA-241
version 3
Stale TLB entry due to page type release race
UPDATES IN VERSION 3
Fix ARM build issue in patches.
Public release.
ISSUE
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory XSA-244
version 2
x86: Incorrect handling of IST settings during CPU hotplug
UPDATES IN VERSION 2
Public release.
ISSUE DESCRIPTION
===
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory XSA-242
version 2
page type reference leak on x86
UPDATES IN VERSION 2
Public release.
ISSUE DESCRIPTION
=
The page
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory XSA-243
version 3
x86: Incorrect handling of self-linear shadow mappings with translated guests
UPDATES IN VERSION 3
Public release.
ISSUE DESCRIPTION
=
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory XSA-237
version 2
multiple MSI mapping issues on x86
UPDATES IN VERSION 2
Public release.
ISSUE DESCRIPTION
=
Multiple
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory XSA-238
version 2
DMOP map/unmap missing argument checks
UPDATES IN VERSION 2
Public release.
ISSUE DESCRIPTION
=
DMOPs
Silently assuming DOMID_SELF is unlikely to be a good idea for page
table updates. For PGT_writable pages, though, it seems better to allow
the writes, so the same check isn't being applied there.
Also add blank lines between the individual case blocks.
Signed-off-by: Jan Beulich
--- a/xen/arch
flight 114338 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/114338/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt-xsm 7 xen-boot fail REGR. vs. 114175
test-amd64-i386-xl-q
Hi,
On 21/09/17 01:37, Sameer Goel wrote:
This will be used as a device property to match the DMA capable devices
with the associated SMMU. The header file is a port from linux. The code
was changed to remove the types that were not needed for Xen.
I think you probably want a bit more context
On 10/10/17 12:05 -0400, Konrad Rzeszutek Wilk wrote:
> On Tue, Sep 12, 2017 at 11:15:09AM +0800, Haozhong Zhang wrote:
> > On 09/11/17 11:52 -0700, Stefano Stabellini wrote:
> > > CC'ing xen-devel, and the Xen tools and x86 maintainers.
> > >
> > > On Mon, 11 Sep 2017, Igor Mammedov wrote:
> > >
Hi,
On 21/09/17 01:37, Sameer Goel wrote:
Introduce a common structure to hold the fw (ACPI or DT) defined
configuration for SMMU hw. The current use case is for arm SMMUs. So,
making this architecture specific.
Based on Linux kernel commit 57f98d2f61e1: iommu: Introduce iommu_fwspec
Signed-off
Hi,
Bringing back this discussion.
On 28/08/17 22:39, Goel, Sameer wrote:
On 6/9/2017 3:44 AM, Wei Liu wrote:
On Thu, Jun 08, 2017 at 08:49:01PM +0100, Julien Grall wrote:
CC the REST maintainers
On 08/06/2017 20:30, Sameer Goel wrote:
Introduce a memory realloc function.
Signed-off-by:
Hi,
On 12/10/17 14:05, Julien Grall wrote:
Hi,
On 21/09/17 01:37, Sameer Goel wrote:
Introduce a common structure to hold the fw (ACPI or DT) defined
configuration for SMMU hw. The current use case is for arm SMMUs. So,
making this architecture specific.
Based on Linux kernel commit 57f98d2f6
flight 114418 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/114418/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt 12 guest-start fail REGR. vs. 114299
Tests which
Having all of this logic together makes it easier to follow Xen's virtual
setup across the whole system.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Tim Deegan
CC: George Dunlap
CC: Wei Liu
CC: Julien Grall
---
xen/arch/x86/mm.c | 16 +---
The important change here is in patch 3, which is intended to remove the
correct-but-dangerous-looking construction of linear pagetables slots for
shadowed guests.
Andrew Cooper (3):
Revert "x86/mm: move PV l4 table setup code" and "x86/mm: factor out
pv_arch_init_memory"
x86/mm: Consolida
This reverts commit f3b95fd07fdb55b1db091fede1b9a7c71f1eaa1b and
1bd39738a5a34f529a610fb275cc83ee5ac7547a.
The following patches (post XSA-243 fixes) requires init_guest_l4_table()
being common code.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Julien Grall
These pagetabl
There are currently three functions which write L4 pagetables for Xen, but
they all behave subtly differently. sh_install_xen_entries_in_l4() in
particular is catering for two different usecases, which makes the safety of
the linear mappings hard to follow.
By consolidating the L4 pagetable writi
Hi Sameer,
On 21/09/17 01:37, Sameer Goel wrote:
Add support for parsing IORT table to initialize SMMU devices.
* The code for creating an SMMU device has been modified, so that the SMMU
device can be initialized.
* The NAMED NODE code has been commented out as this will need DOM0 kernel
support
Hi Sameer,
On 21/09/17 01:37, Sameer Goel wrote:
@@ -583,14 +631,13 @@ const struct iommu_ops *iort_iommu_configure(struct
device *dev)
u32 streamid = 0;
if (dev_is_pci(dev)) {
- struct pci_bus *bus = to_pci_dev(dev)->bus;
+ struct pci_dev *pci_device
osstest service owner writes ("[osstest test] 114342: regressions - trouble:
blocked/broken/fail/pass"):
> flight 114342 osstest real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/114342/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which co
On Thu, Oct 12, 2017 at 5:02 AM, Wei Liu wrote:
>
> FYI all patches except the xentrace one were committed yesterday.
Thank you very much, Wei!
Best,
Meng
--
Meng Xu
Ph.D. Candidate in Computer and Information Science
University of Pennsylvania
http://www.cis.upenn.edu/~mengxu/
On Thu, Oct 12, 2017 at 02:54:20PM +0100, Andrew Cooper wrote:
> This reverts commit f3b95fd07fdb55b1db091fede1b9a7c71f1eaa1b and
> 1bd39738a5a34f529a610fb275cc83ee5ac7547a.
>
> The following patches (post XSA-243 fixes) requires init_guest_l4_table()
> being common code.
>
> Signed-off-by: Andre
On Thu, Oct 12, 2017 at 02:33:04PM +0100, Julien Grall wrote:
> Hi,
>
> Bringing back this discussion.
>
> On 28/08/17 22:39, Goel, Sameer wrote:
> >
> >
> > On 6/9/2017 3:44 AM, Wei Liu wrote:
> > > On Thu, Jun 08, 2017 at 08:49:01PM +0100, Julien Grall wrote:
> > > > CC the REST maintainers
>
>>> On 12.10.17 at 15:54, wrote:
> This reverts commit f3b95fd07fdb55b1db091fede1b9a7c71f1eaa1b and
> 1bd39738a5a34f529a610fb275cc83ee5ac7547a.
>
> The following patches (post XSA-243 fixes) requires init_guest_l4_table()
> being common code.
>
> Signed-off-by: Andrew Cooper
Acked-by: Jan Beul
>>> On 12.10.17 at 15:54, wrote:
> Having all of this logic together makes it easier to follow Xen's virtual
> setup across the whole system.
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
___
Xen-devel mailin
On Thu, Oct 12, 2017 at 02:54:21PM +0100, Andrew Cooper wrote:
> Having all of this logic together makes it easier to follow Xen's virtual
> setup across the whole system.
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Wei Liu
_
>>> On 12.10.17 at 15:54, wrote:
> --- a/xen/arch/x86/mm/hap/hap.c
> +++ b/xen/arch/x86/mm/hap/hap.c
> @@ -391,41 +391,24 @@ int hap_set_allocation(struct domain *d, unsigned int
> pages, bool *preempted)
> return 0;
> }
>
> -static void hap_install_xen_entries_in_l4(struct vcpu *v, mfn_t
On Thu, Oct 12, 2017 at 02:54:22PM +0100, Andrew Cooper wrote:
> There are currently three functions which write L4 pagetables for Xen, but
> they all behave subtly differently. sh_install_xen_entries_in_l4() in
> particular is catering for two different usecases, which makes the safety of
> the l
On Thu, Oct 12, 2017 at 02:24:23PM +, Ian Jackson wrote:
> osstest service owner writes ("[osstest test] 114342: regressions - trouble:
> blocked/broken/fail/pass"):
> > flight 114342 osstest real [real]
> > http://logs.test-lab.xenproject.org/osstest/logs/114342/
> >
> > Regressions :-(
> >
>>> On 11.10.17 at 19:52, wrote:
> --- a/tools/fuzz/x86_instruction_emulator/fuzz-emul.c
> +++ b/tools/fuzz/x86_instruction_emulator/fuzz-emul.c
> @@ -22,34 +22,31 @@
>
> #define SEG_NUM x86_seg_none
>
> -/* Layout of data expected as fuzzing input. */
> -struct fuzz_corpus
> +/*
> + * State
>>> On 11.10.17 at 19:52, wrote:
> @@ -884,20 +891,146 @@ int LLVMFuzzerInitialize(int *argc, char ***argv)
> return 0;
> }
>
> -int LLVMFuzzerTestOneInput(const uint8_t *data_p, size_t size)
> +static void setup_fuzz_state(struct fuzz_state *state, const void *data_p,
> size_t size)
> {
On 12/10/17 16:08, Jan Beulich wrote:
On 12.10.17 at 15:54, wrote:
>> --- a/xen/arch/x86/mm/hap/hap.c
>> +++ b/xen/arch/x86/mm/hap/hap.c
>> @@ -391,41 +391,24 @@ int hap_set_allocation(struct domain *d, unsigned int
>> pages, bool *preempted)
>> return 0;
>> }
>>
>> -static void hap_
On Wed, Oct 11, 2017 at 2:34 PM, Tom Lendacky wrote:
> On 10/11/2017 3:30 PM, Thomas Garnier wrote:
>> Changes:
>> - patch v1:
>> - Simplify ftrace implementation.
>> - Use gcc mstack-protector-guard-reg=%gs with PIE when possible.
>> - rfc v3:
>> - Use --emit-relocs instead of -pi
flight 114421 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/114421/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf broken
build-armhf
>>> On 11.10.17 at 19:52, wrote:
> The Intel manual claims that, "If [certain CPUID bits] are set, the
> processor deprecates FCS and FDS, and the field is saved as h";
> but experimentally it would be more accurate to say, "the field is
> occasionally saved as h". This causes the --rerun
>>> On 12.10.17 at 17:24, wrote:
> On 12/10/17 16:08, Jan Beulich wrote:
> On 12.10.17 at 15:54, wrote:
>>> --- a/xen/arch/x86/mm/hap/hap.c
>>> +++ b/xen/arch/x86/mm/hap/hap.c
>>> @@ -391,41 +391,24 @@ int hap_set_allocation(struct domain *d, unsigned int
> pages, bool *preempted)
>>> r
>>> On 02.10.17 at 18:13, wrote:
> No functional change.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
On 12/10/2017 14:45, Haozhong Zhang wrote:
> Basically, QEMU builds two ROMs for guest, /rom@etc/acpi/tables and
> /rom@etc/table-loader. The former is unstructured to guest, and
> contains all data of guest ACPI. The latter is a BIOSLinkerLoader
> organized as a set of commands, which direct the g
On 2017.10.12 at 08:34 -0700, Thomas Garnier wrote:
> On Wed, Oct 11, 2017 at 2:34 PM, Tom Lendacky wrote:
> > On 10/11/2017 3:30 PM, Thomas Garnier wrote:
> >> Changes:
> >> - patch v1:
> >> - Simplify ftrace implementation.
> >> - Use gcc mstack-protector-guard-reg=%gs with PIE when po
>>> On 02.10.17 at 18:13, wrote:
> The triple-fault reboot method stays as is, to avoid the int3 possibly getting
> moved relative to the lidt.
Aren't asm volatile()s ordered wrt to one another?
> --- a/xen/include/asm-x86/desc.h
> +++ b/xen/include/asm-x86/desc.h
> @@ -197,6 +197,26 @@ DECLARE_
>>> On 02.10.17 at 18:13, wrote:
> @@ -518,26 +522,29 @@ static void invalidate_shadow_ldt(struct vcpu *v, int
> flush)
> if ( v->arch.pv_vcpu.shadow_ldt_mapcnt == 0 )
> goto out;
>
> -v->arch.pv_vcpu.shadow_ldt_mapcnt = 0;
> pl1e = pv_ldt_ptes(v);
>
> for ( i = 0;
On 12/10/17 16:53, Jan Beulich wrote:
On 02.10.17 at 18:13, wrote:
>> The triple-fault reboot method stays as is, to avoid the int3 possibly
>> getting
>> moved relative to the lidt.
> Aren't asm volatile()s ordered wrt to one another?
>From the docs
"Note that the compiler can move even v
This patch adjusts the ioreq server code to use type-safe gfn_t values
where possible. No functional change.
Signed-off-by: Paul Durrant
Reviewed-by: Roger Pau Monné
Reviewed-by: Wei Liu
Acked-by: Jan Beulich
---
Cc: Andrew Cooper
---
xen/arch/x86/hvm/ioreq.c | 44 +++
By using a static inline stub in private.h for OS where this functionality
is not implemented, the various duplicate stubs in the OS-specific source
modules can be avoided.
Signed-off-by: Paul Durrant
Reviewed-by: Roger Pau Monné
Acked-by: Wei Liu
---
Cc: Ian Jackson
v4:
- Removed extraneous
A subsequent patch will introduce a new scheme to allow an emulator to
map ioreq server pages directly from Xen rather than the guest P2M.
This patch lays the groundwork for that change by deferring mapping of
gfns until their values are requested by an emulator. To that end, the
pad field of the
This series introduces support for direct mapping of guest resources.
The resources are:
- IOREQ server pages
- Grant tables
v10:
- Responded to comments from Jan.
v9:
- Change to patch #1 only.
v8:
- Re-ordered series and dropped two patches that have already been
committed.
v7:
- Fi
...to allow the calling domain to prevent translation of specified l1e
value.
Despite what the comment in public/xen.h might imply, specifying a
command value of MMU_NORMAL_PT_UPDATE will not simply update an l1e with
the specified value. Instead, mod_l1_entry() tests whether foreign_dom
has PG_tr
This patch re-works much of the ioreq server initialization and teardown
code:
- The hvm_map/unmap_ioreq_gfn() functions are expanded to call through
to hvm_alloc/free_ioreq_gfn() rather than expecting them to be called
separately by outer functions.
- Several functions now test the validity o
... XENMEM_resource_ioreq_server
This patch adds support for a new resource type that can be mapped using
the XENMEM_acquire_resource memory op.
If an emulator makes use of this resource type then, instead of mapping
gfns, the IOREQ server will allocate pages from the heap. These pages
will never
A previous patch introduced a new HYPERVISOR_memory_op to acquire guest
resources for direct priv-mapping.
This patch adds new functionality into libxenforeignmemory to make use
of a new privcmd ioctl [1] that uses the new memory op to make such
resources available via mmap(2).
[1]
http://xenbit
Certain memory resources associated with a guest are not necessarily
present in the guest P2M.
This patch adds the boilerplate for new memory op to allow such a resource
to be priv-mapped directly, by either a PV or HVM tools domain.
NOTE: Whilst the new op is not intrinsicly specific to the x86
A subsequent patch will remove the current implicit limitation on creation
of ioreq servers which is due to the allocation of gfns for the ioreq
structures and buffered ioreq ring.
It will therefore be necessary to introduce an explicit limit and, since
this limit should be small, it simplifies th
This patch allows grant table frames to be mapped using the
XENMEM_acquire_resource memory op.
Signed-off-by: Paul Durrant
---
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Konrad Rzeszutek Wilk
Cc: Stefano Stabellini
Cc: Tim Deegan
Cc: Wei Liu
v10:
- Addressed
A previous patch added support for priv-mapping guest resources directly
(rather than having to foreign-map, which requires P2M modification for
HVM guests).
This patch makes use of the new API to seed the guest grant table unless
the underlying infrastructure (i.e. privcmd) doesn't support it, in
On 10/12/2017 10:34 AM, Thomas Garnier wrote:
On Wed, Oct 11, 2017 at 2:34 PM, Tom Lendacky wrote:
On 10/11/2017 3:30 PM, Thomas Garnier wrote:
Changes:
- patch v1:
- Simplify ftrace implementation.
- Use gcc mstack-protector-guard-reg=%gs with PIE when possible.
- rfc v3:
Hi Sameer,
Given this is all Arm specific. I am not sure why people like Andrew,
Jan have been added.
Please use scripts/get_maintainers to find the list of maintainers per
patches and avoid to CC all of them on each patches.
On 21/09/17 01:37, Sameer Goel wrote:
This driver follows an app
Hi
What is the status of creating a shim to abstract secure boot signing for Xen
(to leverage MSFT 3rd party, e.g)?
Thanks
-Bill
> -Original Message-
> From: Daniel Kiper [mailto:daniel.ki...@oracle.com]
> Sent: Tuesday, May 16, 2017 4:05 AM
> To: Bill Jacobs (billjac)
> Cc: george.dun..
Hi all,
for 4.9.1 the XSA status is
XSA 226 : Some patches not applied => check
There is an extra chunk in the tree: see xsa226.png
XSA 227 : All patches found (no need to check)
XSA 228 : All patches found (no need to check)
XSA 229 : No patch found => check
Linux only => no issue
XSA 230 : A
On Thu, 12 Oct 2017, Paul Durrant wrote:
> > -Original Message-
> > From: Gerd Hoffmann [mailto:kra...@redhat.com]
> > Sent: 12 October 2017 10:26
> > To: Paul Durrant ; 'Stefano Stabellini'
> > ; Anthony Perard
> > Cc: qemu-de...@nongnu.org; xen-de...@lists.xenproject.org; Owen Smith
> >
On Thu, Oct 12, 2017 at 3:10 AM, Alexandru Isaila
wrote:
> This patch adds the old value param and the onchangeonly option
> to the VM_EVENT_REASON_MOV_TO_MSR event.
>
> The param was added to the vm_event_mov_to_msr struct and to the
> hvm_monitor_msr function. Finally I've changed the bool_t par
1 - 100 of 137 matches
Mail list logo
