| /xen/xen/arch/x86/oprofile/ |
| A D | nmi_int.c | 44 if ( model == NULL ) in passive_domain_msr_op_checks()
83 model->free_msr(v); in passive_domain_destroy()
171 model->setup_ctrs(msrs); in nmi_cpu_setup()
255 model->start(msrs); in nmi_cpu_start()
271 model->stop(msrs); in nmi_cpu_stop()
311 model = &op_p4_spec; in p4_init()
316 model = &op_p4_ht2_spec; in p4_init()
361 model = &op_ppro_spec; in ppro_init()
398 model = &op_athlon_spec; in nmi_init()
402 model = &op_athlon_spec; in nmi_init()
[all …]
|
| A D | op_model_athlon.c | 201 unsigned int const nr_ctrs = model->num_counters; in athlon_setup_ctrs()
202 unsigned int const nr_ctrls = model->num_controls; in athlon_setup_ctrs()
321 unsigned int const nr_ctrs = model->num_counters; in athlon_check_ctrs()
393 unsigned int const nr_ctrs = model->num_counters; in athlon_start()
422 unsigned int const nr_ctrs = model->num_counters; in athlon_stop()
|
| A D | op_x86_model.h | 56 extern struct op_x86_model_spec const *model;
|
| /xen/docs/misc/ |
| A D | stubdom.txt | 23 information on device model stub domains
55 3. stubdomain signal readiness by writing "running" to /local/domain/<stubdom-id>/device-model/<tar…
60 1. Write parameter to /local/domain/<stubdom-id>/device-model/<target-id>/parameter.
61 2. Write command to /local/domain/<stubdom-id>/device-model/<target-id>/command.
62 3. Wait for command result in /local/domain/<stubdom-id>/device-model/<target-id>/state (command sp…
63 4. Write "running" back to /local/domain/<stubdom-id>/device-model/<target-id>/state.
118 4. stubdomain starts vchan server on /local/domain/<stubdom-id>/device-model/<target-id>/qmp-vchan,…
119 5. qemu signal readiness by writing "running" to /local/domain/<stubdom-id>/device-model/<target-id…
120 6. now device model is considered running
122 QEMU can be controlled using QMP over vchan at /local/domain/<stubdom-id>/device-model/<target-id>/…
|
| A D | xsm-flask.txt | 6 a security model using this framework (at the time of writing, it is the only
134 The example policy defines dm_dom_t for the device model of a domU_t domain;
135 there are no device model types defined for the other domU types.
154 itself. The same applies for a device model domain's access to its designated
155 target, allowing the IS_PRIV_FOR checks used in Xen's DAC model to be
167 A similar type transition is done when a device model domain is associated with
169 target domain as the source and the device model domain as the target: this
|
| A D | qemu-backends.txt | 9 $QEMU = /local/domain/$BACKEND_DOM/device-model/$DOMID
|
| A D | xenstore-paths.pandoc | 146 #### ~/image/device-model-pid = INTEGER [INTERNAL]
148 The process ID of the device model associated with this domain, if it
151 #### ~/image/device-model-domid = INTEGER [INTERNAL]
153 The domain ID of the device model stubdomain associated with this domain,
410 #### ~/device-model/$DOMID/* [INTERNAL]
413 the target domain of the device model.
558 #### ~/device-model/$DOMID/state [w]
562 #### ~/device-model/$DOMID/backends/* [w]
564 Backend types the device model is supporting. Each entry below backends
628 The device model version for a domain.
|
| /xen/xen/arch/arm/ |
| A D | cpuerrata.c | 371 #define MIDR_RANGE(model, min, max) \ argument
373 .midr_model = model, \
377 #define MIDR_ALL_VERSIONS(model) \ argument
379 .midr_model = model, \
|
| /xen/xen/include/asm-x86/ |
| A D | processor.h | 109 uint16_t model; member
609 static inline uint8_t get_cpu_family(uint32_t raw, uint8_t *model, in get_cpu_family() argument
617 if ( model ) in get_cpu_family()
624 *model = mod; in get_cpu_family()
|
| /xen/docs/designs/ |
| A D | dmop.pandoc | 7 The aim of DMOP is to prevent a compromised device model from compromising
11 The problem occurs when you a device model issues an hypercall that
54 dm_op, describing the specific device model operation and its parameters.
|
| A D | non-cooperative-migration.md | 5 The normal model of migration in Xen is driven by the guest because it was
7 running under Xen and is hence expected to co-operate. This model dates from
11 true in a cloud environment. The aim of this design is to provide a model
27 The PV driver model consists of a *frontend* and a *backend*. The frontend
101 Thus if we are to change the model and support migration of a guest with PV
|
| /xen/tools/flask/policy/modules/ |
| A D | domU.te | 16 # Device model for domU_t. You can define distinct types for device models for
|
| A D | xen.if | 142 # Define how a device model domain interacts with its target
160 # Allow creation of a device model and HVM domain pair
|
| /xen/tools/libxl/ |
| A D | libxl_nic.c | 63 if (!nic->model) { in libxl__device_nic_setdefault()
64 nic->model = strdup("rtl8139"); in libxl__device_nic_setdefault()
65 if (!nic->model) return ERROR_NOMEM; in libxl__device_nic_setdefault()
375 nic->model = NULL; /* XXX Only for TYPE_IOEMU */ in libxl__nic_from_xenstore()
|
| /xen/docs/features/ |
| A D | qemu-deprivilege.pandoc | 19 By default, the QEMU device model is run in domain 0. If an attacker
88 same uid. Multiple VMs with the same device model uid will cause
117 device model may be able to do the following:
|
| /xen/tools/libacpi/ |
| A D | ssdt_tpm.asl | 17 /* SSDT for TPM TIS Interface for Xen with Qemu device model. */
|
| /xen/docs/man/ |
| A D | xl.cfg.5.pod.in | 483 chosen device model.
1222 device-model and upstream qemu-xen device-model.
1392 Restrict the device model after startup,
2381 device-model, the default and minimum is 8 MB.
2751 Use the device-model merged into the upstream QEMU project.
2752 This device-model is the default for Linux dom0.
2757 This device-model is still the default for NetBSD dom0.
2764 model which they were installed with.
2806 device-model.
2812 option to the device-model.
[all …]
|
| A D | xl-network-configuration.5.pod | 21 'mac=00:16:3E:74:3d:76,model=rtl8139,bridge=xenbr0'
129 =head2 model section
150 in principle any device supported by your device model
|
| /xen/ |
| A D | CHANGELOG.md | 20 - libxl support for running qemu-xen device model in a linux stubdomain.
|
| A D | SUPPORT.md | 170 ### Linux device model stubdomains
172 Support for running qemu-xen device model in a linux stubdomain.
565 Vulnerabilities of a device model stub domain
573 This means adding extra restrictions to a device model in order to
574 prevent a compromised device model from attacking the rest of the
770 which enable use as a device model stub domain. The old version is
776 Status, as host process device model: No security support, not recommended
|
| /xen/xen/include/acpi/ |
| A D | actbl.h | 209 u8 model; /* System Interrupt Model (ACPI 1.0) - not used in ACPI 2.0+ */ member
|
| A D | actbl2.h | 662 u32 model; member
689 u32 model; /* O: generic SMMUv3 */ member
|
| /xen/xen/include/asm-arm/ |
| A D | processor.h | 42 #define MIDR_IS_CPU_MODEL_RANGE(midr, model, rv_min, rv_max) \ argument
47 _model == (model) && _rv >= (rv_min) && _rv <= (rv_max); \
|
| /xen/docs/admin-guide/ |
| A D | microcode-loading.rst | 49 model : 60
50 model name : Intel(R) Xeon(R) CPU E3-1240 v3 @ 3.40GHz
|
| /xen/xen/arch/x86/cpu/ |
| A D | common.c | 901 for (m = table; m->vendor | m->family | m->model | m->feature; m++) { in x86_match_cpu()
906 if (c->x86_model != m->model) in x86_match_cpu()
|